Проблемы параллелизма

Обозначим некоторые принципиальные проблемы обеспечения параллельной работы программных приложений.

Самый простой для восприятия пример — утраченные изменения (lost updates). Предположим, что некий Мартин открывает для редактирования файл с исходным кодом программы, намереваясь за пару минут подправить текст метода checkConcurrency.

В то же самое время ни о чем не подозревающий Дейвид обращается к тому же файлу, чтобы модифицировать метод updatelmportantParameter. Дейвид справляется со своим заданием очень быстро — настолько быстро, что, приступив к работе позже Мартина, успевает завершить ее раньше... к несчастью. В момент открытия Мартином файл еще не содержал изменений, внесенных Дейвидом, поэтому, сохраняя результат, Мартин запишет поверх содержимого файла свою копию данных, и редакция Дейвида будет безвозвратно потеряна.

А эффект несогласованного чтения (inconsistent read) возникает в ситуациях, когда считываются две корректные сами по себе порции данных, которые, однако, не могут существовать в один и тот же момент времени. Допустим, тому же вездесущему Мартину захотелось узнать, сколько классов содержит пакет поддержки параллельной работы, который состоит из двух вложенных пакетов, реализующих протоколы блокирования и протоколирования действий транзакций. Мартин заглядывает в пакет блокирования и видит в нем семь классов. В этот момент звонит телефон. Пока Мартин разбирается с ним, неутомимый Дейвид, наконец, устраняет досадную ошибку в коде метода четырехфазного блокирования и вводит два новых класса в пакет блокирования и три, в добавление к имеющимся пяти,— в пакет протоколирования. Чувство долга берет верх над жаждой, и Мартин, положив трубку и возвратившись к начатому делу, обнаруживает в пакете протоколирования восемь классов и приходит к глубокомысленному выводу о том, что общее количество классов равно пятнадцати.

Конечно, 15 — это неверный ответ. Правильным был бы такой: 12 до внесения изменений Дейвидом и 17 — после. Любой из них корректен, хотя в какой-то момент времени, возможно, неактуален, но число 15, полученное на основе несогласованных выводов, не отвечает действительности ни при каких обстоятельствах.

Обе проблемы выражаются в потере достоверности (correctness) информации и в некорректном поведении системы, чего можно было бы избежать, если бы два человека не обращались к одним и тем же данным одновременно. Впрочем, если бы речь шла только о недостоверности, проблемы не были бы столь серьезными. Собственно говоря, можно упорядочить действия таким образом, чтобы только один субъект имел право обращаться к порции данных в определенный момент времени. Это поможет сберечь достоверность информации, но снизит возможности параллельного выполнения операций по ее обработке.

Основополагающая проблема любой модели программирования параллельных операций заключается не только в сохранении корректности данных, но и в обеспечении максимальной степени параллелизма (живучести (liveness) системы). Зачастую приходится поступаться корректностью в угоду параллельности; величина такой жертвы определяется, с одной стороны, серьезностью нештатных ситуаций, возникающих из-за возможной недостоверности или неактуальности данных, а с другой — действительным уровнем потребностей в выполнении операций в параллельном режиме.

Это далеко не все проблемы, которые могут подстерегать разработчиков систем параллельной обработки данных, но, как можно полагать, главные. Для их разрешения используются различные управляющие механизмы. Нередко процесс преодоления одних проблем способствует появлению других — хотя и менее серьезных, но неизбежных. Отсюда следует один важный вывод: если проблемы, связанные с параллельной обработкой данных, «терпимы», постарайтесь отказаться от идеи использования управляющего механизма.