Эквивалентность семафоров, мониторов и сообщений.

Это означает, что любые два из предложенных механизмов могут быть реализованы на базе третьего, оставшегося механизма.

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

Рассмотрим сначала, как реализовать мониторы с помощью семафоров. Для этого нам нужно уметь реализовывать взаимоисключения при входе в монитор и условные переменные. Возьмем семафор mutex с начальным значением 1 для реализации взаимоисключения при входе в монитор и по одному семафору c_i для каждой условной переменной. Когда процесс входит в монитор, компилятор будет генерировать вызов функции monitor_enter, которая выполняет операцию P над семафоромmutex для данного монитора. При нормальном выходе из монитора (то есть при выходе без вызова операции signalдля условной переменной) компилятор будет генерировать вызов функции monitor_exit, которая выполняет операцию V над этим семафором.

Для выполнения операции wait над условной переменной компилятор будет генерировать вызов функции wait, которая выполняет операцию V для семафора mutex, разрешая другим процессам входить в монитор, и выполняет операцию P над соответствующим семафором ci, блокируя вызвавший процесс. Для выполнения операции signal над условной переменной компилятор будет генерировать вызов функции signal_exit, которая выполняет операцию V над ассоциированным семафором ci, и выход из монитора, минуя функцию monitor_exit.

Semaphore mutex = 1;

void monitor_enter(){

P(mutex);

}

void monitor_exit(){

V(mutex);

}

void wait(){

V(mutex);
P(c_i );

}

void signal_exit(){

V(c_i );

}

Заметим, что при выполнении функции signal_exit, процесс покидает монитор без увеличения значения семафора mutex, не разрешая тем самым всем процессам, кроме разбуженного, войти в монитор. Это увеличение совершит разбуженный процесс, когда покинет монитор нормальным способом, либо когда выполнит новую операцию wait над какой-либо условной переменной.

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

Процесс-получатель с номером i, прежде всего, выполняет операцию P(mutex), получая в монопольное владение разделяемую память.После чего он изучает наличие сообщений в буфере. Если сообщений нет, то он заносит себя в список процессов, ожидающих сообщения, выполняет V(mutex) и P(c_i ). Если сообщение в буфере есть, то он читает сообщение, изменяет счетчики буфера и проверяет, есть ли процессы в списке процессов, жаждущих записи. Если такой процесс есть (с номером j), то он удаляется из этого списка, выполняется Vдля его семафора cj, и мы выходим из критического района. Проснувшийся процесс начинает выполняться в критическом районе, так какmutex у нас имеет значение 0, и никто более не может попасть в критический район. При выходе из критического района именно разбуженный процесс произведет вызов V(mutex).

Как строится работа процесса-отправителя с номером i? Процесс, посылающий сообщение, тоже ждет, пока он не сможет иметь монополию на использование разделяемой памяти, выполнив операцию P(mutex). Далее он проверяет наличие места в буфере и, если оно есть, помещает сообщение в буфер, изменяет счетчики и смотрит, есть ли процессы, ожидающие сообщения. Если нет, выполняет V(mutex) и выходит из критической области, если есть (с номером j), будит один из них, вызывая V(cj ), с одновременным удалением этого процесса из списка процессов, ожидающих сообщений, и выходит из критического региона без вызова V(mutex), предоставляя тем самым возможность разбуженному процессу прочитать сообщение. Если места в буфере нет, то процесс-отправитель заносит себя в очередь процессов, ждущих возможности записи, и вызывает V(mutex)и P(c_i ).

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

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

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

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

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

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

Тупики.

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

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

Концепция ресурса

Уже говорилось, что одна из основных функций ОС осуществлять распределение ресурсов между процессами, то есть быть менеджером ресурсов.

Как устройства, так и данные могут являться ресурсами.

Некоторые виды ресурсов допускают разделение между процессами, то есть являются разделяемыми устройствами. Например, память, процессор, диски коллективно используются процессами. Другие - нет, то есть являются выделенными, например, лентопротяжное устройство.Чаще всего тупики связаны с выделенными ресурсами, то есть тупики возникают, когда процессу дается эксклюзивный доступ к устройствам, файлам и другим ресурсам.

Последовательность событий, требуемых для использования ресурса такова:

1. запросить (request) ресурс,

2. использовать (use) ресурс,

3. освободить (release) ресурс.

Если ресурса нет в наличии, когда он требуется, то процесс вынужден ждать. В некоторых ОС процесс автоматически блокируется, когда получает отказ на запрос к ресурсу и просыпается, когда ресурс оказывается в наличии. В других системах отказ сопровождается возвратом ошибки и уже задача вызывающего процесса решить: подождать немного и попытаться осуществить запрос вновь.

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

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

 Условия возникновения тупиков

1. Условие взаимоисключения (Mutual exclusion). Каждый ресурс выделен в точности одному процессу или доступен. Процессы требуют предоставления им монопольного управления ресурсами, которые им выделяются.

2. Условие ожидания ресурсов (Hold and wait). Процессы удерживают за собой ресурсы, уже выделенные им, ожидая в то же время выделения дополнительных ресурсов (которые при этом обычно удерживаются другими процессами).

3. Условие неперераспределяемости (No preemtion). Ресурс, данный ранее, не может быть принудительно забран у процесса. Освобождены они могут быть только процессом, который их удерживает.

4. Условие кругового ожидания (Circular wait). Существует кольцевая цепь процессов, в которой каждый процесс удерживает за собой один или более ресурсов, требующихся другим процессам цепи.

Для тупика необходимо выполнение всех четырехусловий.