В связи с этой задачей возникло несколько проблем разных уровней. Сначала
программа довольно часто блокировалась несмотря на усилия по предотвращению
таких исходов. К счастью, удалось определить, на каком операторе "застревает"
каждый процесс и потребовалось только несколько часов для обнаружения и
устранения наших ошибок.
Эти проблемы были вызваны некорректной записью критической секции для
обработки списка интервалов, требующих дополнительной работы. В этом случае
никакой процесс не мог обратиться к списку. Как только эта проблема была решена,
программа стала выполняться до конца и давать некоторые результаты.
Однако в связи со спецификой реализации данной задачи интегрирования мы не
смогли проверить всю программу, так как один из двух алгоритмов сильно зависел
от условий параллельной обработки и, таким образом, был проверен только
последовательный алгоритм. При параллельном выполнении вновь на каждом прогоне
программы получались разные результаты. На этот раз они обычно были близки к
правильному результату, но все же оставались явно ошибочными. Первое
предположение состояло в том, что эти два алгоритма как-то по-разному принимают
решения о разделении работы, когда в этом наступает необходимость. Так как
различные выполнения могут позволять различным процессам выполняться с
различными скоростями, такие вычисления могут завершаться разными ответами.
Сначала была сделана попытка с помощью операторов печати трассировать
проверки условий принятия решений о разделении работы и определить, какая версия
алгоритма принимала каждое решение. Полученный объем данных оказался слишком
большим для анализа. Следующим предложением было подобрать небольшую задачу
интегрирования, которая демонстрировала бы те же характеристики выполнения. Но
при этом можно было справиться с анализом выходных данных.
Очень маленькие задачи давали корректные результаты. К счастью, мы
случайно натолкнулись на одну задачу, которая была достаточно большой, чтобы
вызвать эти проблемы, и достаточно маленькой для нас, чтобы можно было охватить
промежуточные данные результатов трассировки. Действительно, такая проблема
встретилась в двух наших программах деления.
Оказалось, что программа деления в последовательной версии (считалось, что
она проверена) имела ошибку. Программа работала прекрасно при одном прогоне, но
в случае разбиения области на подынтервалы всегда оказывалась ошибочной. К
сожалению, устранение этой ошибки не изменило поведение программы; она все еще
давала неповторяемые результаты.
Эти ответы были близки, но все же ошибочны. В конце концов, мы "открыли
способ" - выбрали небольшую задачу и использовали каждый из двух алгоритмов в
отдельности (они были достаточно малы, чтобы при их размерах как раз не
возникали блокировки). Прогоны с использованием каждого из алгоритмов не давали
корректного результата!
Ошибка в этой программе была связана с мало используемой частью программы,
которая обеспечивала переключение этих двух версий алгоритмов. При решении любой
вычислительной задачи имела место следующая последовательность событий:
1. Очередь интервалов по этому списку становилась полной, так что
использовалась последовательная версия алгоритма интегрирования.
2. По крайней мере в двух текущих интервалах, работа завершалась без
дальнейшего дробления, так что некоторое пространство в очереди должно было
освобождаться.
3. По крайней мере один из интервалов, обрабатываемых в последовательной
версии алгоритма интегрирования, обнаруживал свободное пространство и делалась
попытка выполнять дополнительную работу. После такой последовательности событий
новые интервалы, не имеющие точно того же конечного значения, которое было
вычислено первоначально, включались в список. Вероятность осуществления
последовательности этих событий оказалась значительно меньше, чем можно было
предположить. Более того, было почти невозможно вызвать эту последовательность
событий и приходилось систематически предварительно проверять эту программу