Занятие 13. Концепция монитора и взаимодействие потоков в Linux и Windows

План занятия:

• Концепция монитора
• Механизмы синхронизации ядра Linux
• Вытесняемость ядра
• Синхронизация в ядре Windows
• Синхронизация в исполнительной системе
• Объекты синхронизации в режиме пользователя
• Ожидания в диспетчерских объектах
• Структуры данных синхронизации

Концепция монитора

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

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

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

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

Идея монитора была впервые предложена в 1974 году известным ученым в области компьютерных наук Ч. А. Хоаром. Монитор часто понимают как высокоуровневую конструкцию языка программирования (как пример такого языка обычно приводят Java), а именно как набор функций или методов класса, внутри которых автоматически сохраняется неявный общий мьютекс вместе с операциями ожидания и сигнализации. На самом деле, как мы видим, концепция монитора может основываться на базовых примитивах - мьютекс и условных переменных - и не должна быть ограничена какой-либо одной языке.

Мониторы Хоара отличаются от тех, что были рассмотрены здесь (эти мониторы называют MESA-мониторами по названию языка, в котором они впервые появились). Главное отличие заключается в реализации сигнализации:

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

Механизмы синхронизации ядра Linux

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

Аналогом потоков в ядре выступают пути передачи управления ядра (kernel control paths). Таким путем является последовательность инструкций, выполняемых ядром для реализации реакции на системный вызов или обработку прерывания. Такая последовательность обычно сводится к выполнению нескольких функций ядра.

Вытесняемость ядра

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

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

Синхронизация в ядре Windows

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

Синхронизация в исполнительной системе

Код исполнительной системы тоже может пользоваться спин-блокировками, но они связаны с активным ожиданием и их применение ограничивается только организацией взаимного исключения в течение короткого времени. Сложные задачи синхронизации решают с помощью диспетчерских объектов (dispatcher objects) и ресурсов исполнительной системы (executive resources).

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

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

Объекты синхронизации в режиме пользователя

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

Ожидания в диспетчерских объектах

Поток может синхронизироваться с диспетчерским объектом через выполнение ожидания в его дескрипторе. Для этого менеджер объектов предоставляет специальные сервисы ожидания для ожидания одного объекта или ожидания нескольких объектов.

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

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

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

Структуры данных синхронизации

Для отслеживания того, какой поток ожидает объект, используют две структуры данных: диспетчерский заголовок объекта и блок ожидания потока.

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

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

Итак, исполнительная система и ядро ​ ​ в любой момент могут получить информацию о всех потоках, которые ожидают в диспетчерском объекте, а также информацию обо всех диспетчерских объектах, которых ожидает поток.