Русский менеджмент и программирование

Непейвода Николай Николаевич Доктор физико-математических наук, профессор Удмуртского государственного университета. Логик, математик, информатик, философ. Автор более 150 научных работ, в том числе книги "Логика и компьютер", "Прикладная логика", "Основания программирования", "Стили и методы программирования". >>>

Рассмотрим систему недоотлаженных процессов в плохо взаимодействующей распределенной среде или, что с математической точки зрения то же самое, русский бизнес-процесс. (Начало выступления аспиранта А. Н. Куприянова на семинаре по теоретическим основам информатики)

Недетерминированное исполнение

Пусть шефу внезапно понадобилось послать на переговоры одного из четырех компетентных сотрудников: Иванова, Петрова, Васильева или Сидорова. Тогда естественно возникает условный оператор:

if

Встретил(Иванов)    —>  Послать(Иванов), 
Встретил(Петров)    —>  Послать(Петров), 
Встретил (Васильев) —> Послать(Васильев),
Встретил(Сидоров)   —> Послать(Сидоров), 

fi

Это типичный дейкстровский условный оператор. Проверяются условия. Если хотя бы одно из них истинно, то исполняется так называемая охраняемая команда, соответствующая этому условию. Если истинно сразу несколько из них, то выполняется любой из вариантов, но только один. Так что, зайдя в курилку и увидев там Иванова, Петрова, Васильева и Сидорова, болтающих с отключенными мобильниками («Обеденный перерыв, сэр!»), начальник пошлет одного из них, того, кого захочет его левая нога, и будет прав.

Такая ситуация называется недетерминированным исполнением. Недетерминированность программ, естественно решающих многие задачи, была четко выявлена еще в работах Дейкстры, соответствующая метиодика программирования описана в классической интереснейшей (ни капли не устаревшей, как отмечают мои студенты) книге Д. Гриса «Наука программирования». Но для удобства хакеров современные языки и системы программирования заставляют нас искусственно превращать программу в детерминированную. Соответствующие преобразования никак не отмечаются в тексте программы и тем самым становятся хорошо спрятанными подпорками, через которые приходится спотыкаться при видоизменении программы.

Параллельное исполнение

Пусть шефу понадобилось послать провинившихся четырех компетентных сотрудников: Иванова, Петрова, Васильева или Сидорова (в данном случае используется другой русский смысл того же слова). Тогда естественно возникает оператор:

parallel {

Встретил(Иванов)    —>   Послать(Иванов),
Встретил(Петров)    —>   Послать(Петров),
Встретил (Васильев) —>   Послать(Васильев),
Встретил(Сидоров)   —>   Послать(Сидоров)

Здесь нужно выполнить все четыре действия, но использование запятой вместо точки с запятой показывает, что выполнять их можно в любом порядке. Так что начальник, встретив одного из провинившихся, пошлет его и будет параллельно с другими делами поджидать встречи с другими. А если он зайдет в курилку и увидит всех четырех в том же состоянии, что и в предыдущем параграфе, он единым махом пошлет их всех параллельно и разделается с задачей. Это и есть параллельное исполнение в том смысле, в каком оно диктуется сутью решения задачи: четыре действия абсолютно независимы и могут быть выполнены в одно и то же время. Конечно же, параллельность в разумно организованной системе не означает требования обязательно дождаться, когда эти четыре товарища сойдутся вместе и лишь затем выполнить действие.

Совместное исполнение

Пусть имеется та же ситуация, что в предыдущем случае, но из соображений менеджмента начальнику не хочется «опускать» каждого из этих ценных специалистов перед другими. Тогда возникает внешне почти такой же оператор:

{

Встретил(Иванов)    —>   Послать(Иванов),
Встретил(Петров)    —>   Послать(Петров),
Встретил (Васильев) —>   Послать(Васильев),
Встретил(Сидоров)   —>   Послать(Сидоров)

Но в данном случае мы имеем чистое совместное исполнение. Порядок исполнения операторов безразличен, но выполняться они могут лишь по одному в один момент времени. Встретив всех четырех знаменитостей в курилке, шеф скажет примерно следующее: — Петров, зайдите ко мне. После него жду Иванова, затем Сидорова, затем Васильева. И уж наедине он выполнит для каждого из них требуемый оператор.

Распределенное исполнение

Пусть теперь начальник, не найдя подчиненных сразу, выдает соответствующее поручение своим менеджерам. Здесь возникает распределенное исполнение, когда несколько плохо взаимодействующих агентов пытаются выполнить предписанное им действие. В результате переговоры может начать Васильев, через час появится взмыленный Иванов с несколько другими инструкциями (отражающими в том числе интересы того менеджера, который выполнил оператор «Послать» для него), еще через двадцать минут Сидоров, и в итоге репутация фирмы летит в яму. В случае же совместного оператора может случиться так, что Иванов десяток раз натолкнется на различных функционеров, каждый из которых пошлет его и в итоге доведет до белого каления, а остальные провинившиеся благополучно избежат взбучки. Может быть и так, что два менеджера, увидев Иванова, оба подумают, что другой позаботится о нем, и разойдутся, так и не послав его. И это только малая часть тех неприятностей, которые могут возникнуть в распределенных системах.

Шеф и компьютер

Те, кто хоть чуть-чуть сталкивались на практике с параллельностью или рас-пределенностью, замечают, насколько же на самом деле умный наш шеф по сравнению с программными системами: увидев подчиненных вместе, он немедленно пошлет их параллельно, а увидев их по отдельности, будет посылать их последовательно. Программа, скорее всего, либо будет долго ждать, пока четыре аргумента не будут готовы. чтобы за счет часа подготовки сэкономить несколько миллисекунд исполнения, либо же (что обычно менее вредно) будет игнорировать появившиеся возможности параллелизма, исполняя операторы один за другим. Современный компьютер намного тупее самого тупого шефа. Здесь мы не оговорились, поскольку параллелизм обычно зависит в значительной степени от «железа». Если же, как привыкли рассматривать это программисты, не отделять компьютер от программной системы, то обычно он будет столь же тупым, но иногда шибко умным и оказывать такие медвежьи услуги, что за голову схватишься. Программные системы заставляют жестко предписывать, что будет делаться параллельно, что в распределенном режиме, а что — последовательно. Лишь для очень простых либо исключительно хорошо изученных систем такие предписания оказываются разумными. Поэтому так редко удается получить выигрыш за счет параллелизма или, тем более, распределенности, и так часто за счет этого получаются лишь сплошные неприятности.

Комментарии читателей