Разделяемые
ресурсы
В современном
операционном окружении программист не может быть уверен и не должен полагаться
на то, что коды его программы будут выполняться в тон же последовательности,
в какой они написаны. Выполнение одной из функций программы может быть остановлено
системой и возобновлено позднее, причем это может произойти даже при выполнении
тела какого-либо цикла. При проектировании многопотоковых приложений следует
иметь в виду, что ресурсы, разделяемые потоками (блоки памяти или файлы), можно
неосознанно повредить. Чтобы показать, как это происходит, рассмотрим пример,
который приведен в книге Jesse Liberty «Beginning Object-Oriented Analysis and
Design with C++» (Дж. Либерти «Начало объектно-ориентированного анализа и проектирования
с помощью C++»), доступной в MSDN.
Представьте
себе пассажирский авиалайнер в полете, а в нем такой разделяемый всеми ресурс,
как туалетная комната. Создатели самолета предполагали, что только одна персона
может занимать эту комнату. Первый, кто ее занял, закрывает (lock) доступ к
пей для всех остальных. Следующий пассажир, желающий воспользоваться этим ресурсом,
может либо терпеливо ожидать освобождения, либо по истечении какого-то времени
(time out) вернуться на свое сиденье и продолжать заниматься тем, чем он был
занят до этого события. Решение о том, что выбрать и как долго ждать, принимает
пассажир. Блокирование ресурса порождает неэффективное проведение времени второго
пассажира как ожидающего очереди, так и избравшего другую тактику.
Возвращаясь
к многопотоковым процессам, отметим, что если не блокировать ресурс,
то становится возможным повреждение данных. Представьте, что один поток процесса
проходит по записям базы данных, повышая зарплату каждому сотруднику на 10%,
а другой поток в это же время изменяет почтовые индексы в связи с введением
нового стандарта. Согласитесь с тем, что разумно совместить эти две работы в
одном процессе с целью повышения производительности. Что может произойти, если
не блокировать доступ к записи при ее модификации? Первый поток прочел запись
(все ее поля), и занят вычислением повышения (предположим, с $80 000 до $85
000). В это время второй поток читает эту же запись с целью изменения почтового
индекса. В этой ситуации может произойти следующее: первый поток сохраняет измененную
запись с новым значением зарплаты, а второй, возвращая запись с измененным индексом,
реставрирует значение зарплаты и данный сотрудник останется без повышения. Это
происходит по причине того, что оба потока не могут обратиться к части записи
и поэтому работают со всей записью, хотя модифицируют только отдельные ее поля.
|
