9.5. Средства группового ожидания

Множественные ожидания событий или освобождения общих ресурсов возникают, когда по существу решаемой задачи может оказаться необходимым ожидать не одного, а более чем одного события или ресурса. Например, продолжить выполнение можно только после освобождения ресурса R1 или ресурса R2. Если в программе вначале поставить функцию ожидания ресурса R1, а затем функцию ожидания ресурса R2, то при освобождении ресурса R2, когда можно было бы по условию задачи продолжать работу, нить процесса по-прежнему будет заблокирована на функции ожидания ресурса R1, который все еще занят. Поставив вызовы функций в обратном порядке – вначале ожидания ресурса R2, затем ресурса R1, попадаем в аналогичную ситуацию невыполнения условий задачи, когда ранее освободится ресурс R1, а ресурс R2 все еще будет занят. Без помощи операционной системы подобную задачу решить оказывается невозможным. Поэтому в состав стандартных системных функций введены функции множественного ожидания.

В Windows и OS/2 входят специальные функции множественного ожидания. В OS/2 эти функции базируются на понятии и типе данных семафоров множественного ожидания – muxwait semaphore, сокращенно обозначаемых в наименовании системных функций как MuxWaitSem.

В Windows для множественного ожидания предназначена универсальная функция WaitForMultipleObjects с прототипом

DWORD WaitForMultipleObjects(DWORD cObjects,

CONST HANDLE *phObjects,// address of object-handle array

BOOL fWaitAll, // wait flag

DWORD Timeout), // time-out interval in milliseconds,

где параметр cObjects для данного применения задает число семафоров в наборе, параметр phObjects – адрес массива хэндлов отдельных семафоров в наборе, параметр Timeout – время ожидания в миллисекундах или записывается символической константой INFINITE – для бесконечного ожидания. С помощью параметра fWaitAll определяется вариант ожидания – ожидать срабатывания всех семафоров в наборе (значение параметра для этого должно быть TRUE) или ожидание завершается при срабатывании хотя бы одного семафора в наборе (при значении FALSE этого параметра). Возвращаемые значения этой функции, равные сумме константы WAIT_OBJECT_0 и числового значения k, информируют программу, что ожидание было прекращено по причине срабатывания k-го семафора в наборе.

В операционной системе Unix не предусмотрено стандартных средств для множественного ожидания срабатывания набора mutex-семафоров или семафоров ожидания (условных переменных). Вместо этого присутствуют мощные программные средства, позволяющие строить произвольные наборы считающих семафоров, которые будут рассматриваться далее в п. 9.7.

9.6. Программные критические секции

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

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

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

VOID InitializeCriticalSection(CRITICAL_SECTION *pCriticalSection),

где параметр функции задает адрес структуры данных типа CRITICAL_SECTION. Поля этой структуры, как правило, явно не используются и не изменяются.

Вход в критическую секцию задается в программе функцией EnterCriticalSection, которая имеет прототип

VOID EnterCriticalSection(CRITICAL_SECTION *pCriticalSection),

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

VOID LeaveCriticalSection(CRITICAL_SECTION *pCriticalSection).

После использования объект критической секции должен быть удален из системы явным вызовом функции

VOID DeleteCriticalSection(CRITICAL_SECTION *pCriticalSection).

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