3. Синхронизация процессов Цели и средства синхронизации процессов

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

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

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

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

Существует два подхода синхронизации процесса:

1) средствами пользователями;

2) средствами операционной системы.

Первый способ предназначен осуществлять синхронизацию в пространстве пользователя. Второй в пространстве ядра ОС.

Первый способ выполняется быстрее, и может применяться к небольшими критическим секциям.

Понятие системные вызовы. Критические секции

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

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

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

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

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

При осуществлении системного вызова приложение выполняет программные прерывания. Эти программные прерывания имеют номер вектора. INT 80h. В этом случае, приложение передает ОС номер системного вызова. Этот номер является индексом в таблице адресов процедур, которые реализуют системные вызовы.

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

Например, массивы передаются через массивы памяти, а адресные массивы через РОН или STEK.

При реализации процессорного вызова, процессор переходит режим ядра.

Существует:

- централизованные

- децентрализованные.

Централизованные:

В данном случае номер с/в = 21 по вектору прерывания до вызова диспетчера системных вызовов, он читает из заранее указанного места номера, находит адрес этого системного места в таб. Sisent, по этому адресу вызывает процедуру обработки с/в 21h.

После завершения работ с/в, управление вновь возвращается к диспетчеру вместе с кодом завершения с/в.

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

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

Существует два режима с/в:

- синхронный

- асинхронный

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

Асинхронный, процесс выполняется после задания начальных условий для с/в.

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

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

Пример:

Пусть имеется файл БД, с которой работают два процесса.

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

Пусть процесс А заносит информацию о заказах поступивших от клиентов. Процесс В вносит изменения в поле «Оплата».

Пусть процесс А прочитал запись о клиенте в свой буфер, внес изменения в поле «заказ» и прервался, например, по истечению кванта времени.

Пусть процесс В выполняется в тоже самое время. Он читает запись в буфер, вносит изменения в поле «Оплата» и также прерывается. Процесс А получив управление заносит измененные записи в файл.

Когда вновь управление будет передано процессу В, он внесет изменения в запись, но со старым полем «заказ», и с новым «оплата». Информация о клиенте искажена.

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