Реализация семафоров и передачи сообщений с помощью мониторов

Нам достаточно показать, что с помощью мониторовможно реализоватьсемафоры, так как получать изсемафоровсообщения мы уже умеем.

Самый простой способ такой реализации выглядит следующим образом. Заведем внутри мониторапеременную-счетчик, связанный с эмулируемымсемафоромсписок блокируемых процессов и по однойусловной переменнойна каждый процесс. При выполнении операцииPнадсемафоромвызывающий процесс проверяет значение счетчика. Если оно больше нуля, уменьшает его на1и выходит измонитора. Если оно равно0, процесс добавляет себя в очередь процессов, ожидающих события, и выполняет операциюwaitнад своейусловной переменной. При выполнении операцииVнадсемафоромпроцесс увеличивает значение счетчика, проверяет, есть ли процессы, ожидающие этого события, и если есть, удаляет один из них из списка и выполняет операциюsignalдляусловной переменной, соответствующей процессу.

Реализация семафоров и мониторов с помощью очередей сообщений

Покажем, наконец, как реализовать семафорыс помощьюочередей сообщений. Для этого воспользуемся более хитрой конструкцией, введя новый синхронизирующий процесс. Этот процесс имеет счетчик и очередь для процессов, ожидающих включениясемафора. Для того чтобы выполнить операцииPиV, процессы посылают синхронизирующему процессу сообщения, в которых указывают свои потребности, после чего ожидают получения подтверждения от синхронизирующего процесса.

После получения сообщения синхронизирующий процесс проверяет значение счетчика, чтобы выяснить, можно ли совершить требуемую операцию. Операция Vвсегда может быть выполнена, в то время как операцияPможет потребовать блокирования процесса. Если операция может быть совершена, то она выполняется, и синхронизирующий процесс посылает подтверждающее сообщение. Если процесс должен быть блокирован, то его идентификатор заносится в очередь блокированных процессов, и подтверждение не посылается. Позднее, когда какой-либо из других процессов выполнит операциюV, один из блокированных процессов удаляется из очереди ожидания и получает соответствующее подтверждение.

Поскольку мы показали ранее, как из семафоровпостроитьмониторы, мы доказали эквивалентностьмониторов,семафорови сообщений.

Заключение

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

7. Лекция: Тупики Введение

В предыдущих лекциях мы рассматривали способы синхронизации процессов, которые позволяют процессам успешно кооперироваться. Однако в некоторых случаях могут возникнуть непредвиденные затруднения. Предположим, что несколько процессов конкурируют за обладание конечным числом ресурсов. Если запрашиваемый процессомресурснедоступен, ОС переводит данный процесс в состояние ожидания. В случае когда требуемыйресурсудерживается другим ожидающим процессом, первый процесс не сможет сменить свое состояние. Такая ситуация называетсятупиком (deadlock). Говорят, что в мультипрограммной системе процесс находится в состояниитупика, если он ожидает события, которое никогда не произойдет. Системнаятупиковая ситуация, или "зависание системы", является следствием того, что один или более процессов находятся в состояниитупика. Иногда подобные ситуации называютвзаимоблокировками. В общем случае проблематупиковэффективного решения не имеет.

Рассмотрим пример. Предположим, что два процесса осуществляют вывод с ленты на принтер. Один из них успел монополизировать ленту и претендует на принтер, а другой наоборот. После этого оба процесса оказываются заблокированными в ожидании второго ресурса(см.рис. 7.1).

Рис. 7.1.Пример тупиковой ситуации

Определение. Множество процессов находится втупиковой ситуации, если каждый процесс из множества ожидает события, которое может вызвать только другой процесс данного множества. Так как все процессы чего-то ожидают, то ни один из них не сможет инициировать событие, которое разбудило бы другого члена множества и, следовательно, все процессы будут спать вместе.

Выше приведен пример взаимоблокировки, возникающей при работе с так называемыми выделенными устройствами.Тупики, однако, могут иметь место и в других ситуациях. Hапример, в системах управления базами данных записи могут быть локализованы процессами, чтобы избежать состояния гонок (см. лекцию 5 "Алгоритмы синхронизации"). В этом случае может получиться так, что один из процессов заблокировал записи, необходимые другому процессу, и наоборот. Таким образом,тупикимогут иметь место как на аппаратных, так и на программныхресурсах.

Тупикитакже могут быть вызваны ошибками программирования. Например, процесс может напрасно ждать открытия семафора, потому что в некорректно написанном приложении эту операцию забыли предусмотреть. Другой причиной бесконечного ожидания может быть дискриминационная политика по отношению к некоторым процессам. Однако чаще всего событие, которого ждет процесс втупиковой ситуации, – освобождениересурса, поэтому в дальнейшем будут рассмотрены методы борьбы ступикамиресурсного типа.

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

Традиционная последовательность событий при работе с ресурсомсостоит из запроса, использования и освобожденияресурса. Тип запроса зависит от природыресурсаи от ОС. Запрос может быть явным, например специальный вызов request, или неявным – open для открытия файла. Обычно, еслиресурсзанят и запрос отклонен, запрашивающий процесс переходит в состояние ожидания.

Далее в данной лекции будут рассматриваться вопросы обнаружения, предотвращения, обхода тупикови восстановления послетупиков. Как правило, борьба ступиками– очень дорогостоящее мероприятие. Тем не менее для ряда систем, например для систем реального времени, иного выхода нет.