Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
операционные системы.docx
Скачиваний:
0
Добавлен:
01.03.2025
Размер:
150.22 Кб
Скачать

10 Критические области

Основным решением проблем, связанных с совместным использованием памяти файлов и т.д., является запрет одновременной записи и чтения разделенных (общих) данных более, чем одним процессом. Иными словами, необходимо взаимное исключение. Это означает, что в момент, когда один процесс использует разделяемые данные, другому процессу это делать запрещено. В рассмотренном примере (см.дальше) эта ситуация возникла из-за того, что процесс В начал работу с одной из совместно используемых переменных до того, как процесс А ее закончил. Часть программы, в которой есть обращение к совместно используемым данным, называется критической областью. Если удастся избежать одновременного нахождения процессов в критической области, можно избежать состязаний. Несмотря на то, что это требование исключает состязания, оно не достаточно для правильной совместной работы квазипараллельных процессов и эффективного использования данных. Для этого необходимо выполнение 4-х условий.

1) Два процесса не должны одновременно находиться в критических областях (в программе, но в одно и тоже время).

2) В программе не должно быть предложений о скорости или количестве процессов.

3) Процесс, находящийся в критической области не может, или не должен блокировать другой процесс.

4) Недопустима ситуация, в которой процесс неопределенно долго ждет попадания в критическую область.

11 Запрещения прерываний и переменные блокировки Попытка аппаратного решения проблемы

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

Рассмотрим программные решения

Пусть имеется одна совместно используемая переменная блокировки, изначально = 0. Если процесс хочет попасть в критическую область, он предварительно считывает значение переменной блокировки; если переменная = 0, то процесс изменяет ее на 1 и входит в критическую область; если переменная = 1, то процесс ждет, пока ее значение не изменится на 0. Т.о. 0 означает, что ни одного процесса в критической области нет, а 1 – наоборот, что есть процессы в критической области. У этого метода те же проблемы, что и в примере с каталогом спулера, а именно: 1 процесс считывает переменную блокировки, обнаруживает, что она = 0, но прежде, чем успевает изменить ее на 1, управление получает другой процесс, изменяющий ее на 1. Когда первый процесс снова получает управление, он тоже заменяет переменную блокировки на 1, и два процесса одновременно оказываются в критической области. Проблема не решается повторной проверкой значения переменной. Второй процесс может получить управление как раз после того, как первый процесс закончил вторую проверку, но еще не заменил значение переменной блокировки.