Полученный в этом эксперименте урок труден для объяснения. Стратегия "разделяй и властвуй" - очень мощное средство для организации параллельной обработки и обеспечения высокой загрузки процессоров. В наших экспериментах все доступные вычислительные средства были активны более чем 95% времени. Но с точки зрения пользователя предотвращение блокировок также существенно. Нельзя представить себе такое объяснение, что программа пользователя "пригнана" к машине, но иногда возникает так много "параллельной" работы, что машина "захлебывается". (Возможно, пользователь предложит такой выход: "Хорошо, можно использовать меньше "параллелизма".) По нашему мнению, эта проблема неотделима от природы языка и свойств примитивов, используемых для описания параллелизма и критических секций.

Элементарный алгоритм "разделяй и властвуй" имеет очевидное определение, но применяемые для его описания средства позволяют рутинно выражать неопределенные вычисления. Любые ошибки при программировании, в критической секции или вне ее, ведут к неповторяемости результатов. В таком случае при переходе от версии к версии одного и того же алгоритма есть риск рассогласования в обработке - как бы незначительное изменение точных границ интервала. Представляется естественным позволить программисту определять те части программы, которые могут выполняться одновременно. Однако если только программист отвечает за корректность этой информации, то должна быть уверенность в том, что он не ошибается. Фортран как базовый язык, на котором должен проводиться такой анализ, препятствует автоматическому обнаружению параллелизма компилятором.

Неизвестно, какие средства могли быть добавлены к языку Фортран, чтобы гарантировать параллелизм и детерминированность поведения всех программ. Заслуживает внимания еще одно замечание к этой задаче. Недавно эта программа транслировалась для выполнения на четырехпроцессорной вычислительной системе VAX (после прогона более 50 тестов на ЭВМ HEP). После того, как программа выполнилась корректно, были проведены некоторые простые измерения временных характеристик. Во время этого тестирования примерно в каждом из десяти прогонов результат оказывался с незначительными ошибками. Причина - еще одна ошибка в той же самой секции программы. Эта ошибка находилась в "последней" версии программы для ЭВМ HEP, но оставалась необнаруженной. Мораль этой истории такова - пока программисты отвечают за организацию в программе всей синхронизации, будет крайне трудно (если вообще возможно) гарантировать, что все возможные ошибки синхронизации будут устранены.