Понятие критической секции при синхронизации процессов.

Состояния процессов в системах с абсолютными и относительными приоритетами.

Чтобы обработать процессы в разумном порядке им присваиваются приоритеты. Программы управляя специальными регистрами маски, позволяют реализовать различные дисциплины обслуживания:

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

2) с абсолютным приоритетом. Всегда обслуживаются задачи с наивысшим приоритетом. Для реализации этой дисциплины при запросе на обработку процесса маскируются все процессы с низшим приоритетом. При этом возможно многоуровневое прерывание, т. е. прерывание программы обработки прерывания. Число уровней прерывания в этом режиме изменяется и зависит от приоритета запроса по принципу стека: LCFS – last come first served, т. е. запрос с более высоким приоритетом может прервать запрос с более низким приоритетом. При появлении запроса на прерывание система прерываний идентифицирует сигнал и если прерывания разрешены, то управление передается на соотв. программу обработки прерываний.

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

53. Вытесняющие и невытесняющие алгоритмы планирования процессов.

Существует два основных типа процедур планирования процессов - вытесняющие (preemptive) и невытесняющие (non-preemptive).

Non-preemptive multitasking - невытесняющая многозадачность - это способ планирования процессов, при котором активный процесс выполняется до тех пор, пока он сам, по собственной инициативе, не отдаст управление планировщику операционной системы для того, чтобы тот выбрал из очереди другой, готовый к выполнению процесс.

Preemptive multitasking - вытесняющая многозадачность - это такой способ, при котором решение о переключении процессора с выполнения одного процесса на выполнение другого процесса принимается планировщиком операционной системы, а не самой активной задачей. Основным различием между preemptive и non-preemptive вариантами многозадачности является степень централизации механизма планирования задач. При вытесняющей многозадачности механизм планирования задач целиком сосредоточен в операционной системе, и программист пишет свое приложение, не заботясь о том, что оно будет выполняться параллельно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения активной задачи, запоминает ее контекст, выбирает из очереди готовых задач следующую и запускает ее на выполнение, загружая ее контекст.

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

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

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

Понятие критической секции при синхронизации процессов.

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

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

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

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

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

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