Мониторы Хоара

Анализ рассмотренных задач показывает, что, несмотря на очевидные достоинст­ва (простота, независимость от количества процессов, отсутствие «активного ожидания»), семафорные механизмы имеют и ряд недостатков. Семафорные ме­ханизмы являются слишком примитивными, так как семафор не указывает не­посредственно на синхронизирующее условие, с которым он связан, или на критический ресурс. Поэтому при построении сложных схем синхронизации ал­горитмы решения задач порой получаются весьма непростыми, ненаглядными и затруднительными для доказательства их правильности.

Необходимо иметь понятные, очевидные решения, которые позволят приклад­ным программистам без лишних усилий, связанных с доказательством правиль­ности алгоритмов и отслеживанием большого числа взаимосвязанных объектов, создавать параллельные взаимодействующие программы. К таким решениям мож­но отнести так называемые мониторы, предложенные Хоаром ].

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

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

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

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

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

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

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

В листинге 6.16 в качестве примера приведен простейший монитор для выделе­ния одного ресурса.

 

Листинг 6.16. Пример монитора Хоара

monitor Resourse;

condition free; { условие - свободный }

var busy : Boolean; { busy - занят }

 

procedure REQUEST; { запрос }

begin

if busy then WAIT ( free );

busy:=true;

TakeOff; { ВЫДАТЬ РЕСУРС }

end;

 

procedure RELEASE;

begin

TakeOn; { ВЗЯТЬ РЕСУРС }

busy:=false;

SIGNAL ( free )

end;

 

begin

busy:=false;

end

 

Единственный ресурс динамически запрашивается и освобождается процессами, которые обращаются к процедурам REQUEST (запрос) и RELEASE (освободить). Если процесс обращается к процедуре REQUEST в тот момент, когда ресурс использует­ся, значение переменной busy (занято) будет равно true, и процедура REQUEST выполнит операцию монитора WAIT(free). Эта операция блокирует не процедуру REQUEST, а обратившийся к ней процесс. Процесс помещается в конец очереди процессов, ожидающих, пока не будет выполнено условие free (свободный).

Когда процесс, использующий ресурс, обращается к процедуре RELEASE, операция монитора SIGNAL деблокирует процесс, находящийся в начале очереди, не позво­ляя исполняться никакой другой процедуре внутри того же монитора. Этот деблокированный процесс готов возобновить исполнение процедуры REQUEST сра­зу же после операции WAIT(free), которая его и блокировала. Если операция SIGNAL(free) выполняется в то время, когда нет процесса, ожидающего условия free, то никакие действия не выполняются.

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

Монитор является пассивным объектом в том смысле, что это не процесс; его процедуры выполняются только по требованию процесса.

Хотя по сравнению с семафорами мониторы не представляют собой существен­но более мощного инструмента для организации параллельных взаимодействую­щих вычислительных процессов, у них есть некоторые преимущества перед более примитивными синхронизирующими средствами. Во-первых, мониторы очень гибки. В форме мониторов можно реализовать не только семафоры, но и многие другие синхронизирующие операции. Например, разобранный во втором разделе данной главы механизм решения задачи «поставщик — потребитель» легко запрограммировать в виде монитора. Во-вторых, локализация всех раз­деляемых переменных внутри тела монитора позволяет избавиться от малопо­нятных конструкций в синхронизируемых процессах. Сложные взаимодействия процессов можно синхронизировать наглядным образом. В-третьих, мониторы дают процессам возможность совместно использовать программные модули, представляющие собой критические секции. Если несколько процессов совмест­но используют ресурс и работают с ним совершенно одинаково, то в мониторе нужна только одна процедура, тогда как решение с семафорами требует, чтобы в каждом процессе имелся собственный экземпляр критической секции. Таким образом, мониторы обеспечивают по сравнению с семафорами значительное уп­рощение организации взаимодействующих вычислительных процессов и боль­шую наглядность при лишь незначительной потере в эффективности.