Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

1.3. Концепции аппаратных решений 41

используется

распределенных системах,

здесь мы вновь сталкиваемся

про-

блемами несогласованной памяти. Мы вернемся

проблемам кэширования

со-

гласованности

главе

Мультипроцессоры шинной архитектуры хорошо опи-

саны

книге

[265].

Проблема мультипроцессорных систем шинной архитектуры состоит

их ог-

раниченной масштабируемости, даже

случае использования кэша.

Для по-

строения мультипроцессорной системы с более чем 256 процессорами для соеди-

нения процессоров

памятью необходимы другие методы. Один

из

вариантов

—

разделить обидую память на модули

связать их с процессорами через коммути-

рующую решетку

{crossbar

switch),

как

показано

на

рис.

1.6, а. Как

видно

из ри-

сунка,

ее помощ.ью каждый процессор может быть связан с любым модулем па-

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

коммутатор (crosspoint

switch),

который может открываться

закрываться аппа-

ратно. Когда процессор желает получить доступ

конкретному модулю памяти,

соединяющие

их

узловые коммутаторы мгновенно открываются, организуя

за-

прошенный доступ. Достоинство узловых коммутаторов

том, что

памяти мо-

гут одновременно обращаться несколько процессоров, хотя если два процессора

одновременно хотят получить доступ

одному

тому же участку памяти,

то

од-

ному

из

них придется подождать.

Процессоры

Области памяти

Ф Ф-

-Ф-

ф—ф^—ф

Узловой коммутатор

Процессоры

Области памяти

Коммутатор

2x2

Рис.

1.6.

Коммутирующая решетка (а). Коммутирующая омега-сеть

(б)

Недостатком коммутирующей решетки является то,

что при

наличии

про-

цессоров

и п

модулей памяти

нам

потребуется

тг^

узловых коммутаторов.

Для

больших значений

это число может превысить наши возможности. Обнаружив

это,

человечество стало искать

нашло альтернативные коммутирующие сети,

требующие меньшего количества коммутаторов. Один

из

примеров таких

се-

тей

— омега-сеть

(omega network), представленная

на

ppic.

1.6,

б. Эта сеть содер-

жит четыре коммутатора 2x2,

то

есть каждый

из них

имеет

по два

входа

и два

выхода. Каждый коммутатор может соединять любой вход

любым выходом.

Если внимательно изучить возможные положения коммутаторов, становится яс-

42 Глава 1. Введение

но,

что любой процессор может получить доступ к любому блоку памяти. Недос-

таток коммутирующих сетей состоит в том, что сигнал, идущий от процессора

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

Поэтому, чтобы снизить задержки между процессором и памятью, коммутаторы

должны иметь очень высокое быстродействие, а дешево это не дается.

Люди пытаются уменьшить затраты на коммутацию путем перехода к иерар-

хическим системам. В этом случае с каждым процессором ассоциируется некото-

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

области памяти. Доступ к другой области памяти происходит значительно мед-

леннее. Эта идея была реализована в машине с

пеупифицироваппым

доступом

памяти

{NonUnifoim Memoiy

Access,

NUMA). Хотя машины NUMA имеют луч-

шее среднее время доступа к памяти, чем машины на базе омега-сетей, у них есть

свои проблемы, связанные с тем, что размещение программ и дан11ых необходи-

мо производить так, чтобы большая часть обращений шла к локально!! памяти.

1.3.2.

Гомогенные мультикомпьютерные

системы

в отличие от мультипроцессоров построить мультикомпьютерную систему отно-

сительно несложно. Каждый процессор напрямую связан со своей локальной па-

мятью. Единственная оставшаяся проблема

—

это общение процессоров между

собой. Понятно, что и тут необходима какая-то схема соединения, но поскольку

нас интересует только связь между процессорами, объем трафика будет на не-

сколько порядков нР1же, чем при использовании сети для поддержания трафика

между процессорами и памятью.

Сначала мы рассмотрим гомогенные мультикомпьютерные сргстемы. В этих

системах, известных под названием системиых сетей {System Area Networks,

SAN),

узлы монтируются в большой стойке и соединяются единой, обычно высо-

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

системами на основе шинной архитектуры и системами на основе коммутации.

В мультикомпьютерных системах с шинной архитектурой процессоры соеди-

няются при помощи разделяемой сети множественного доступа, например Fast

Ethernet. Скорость передачи данных в сети обычно равна 100 Мбит/с. Как и в

случае мультипроцессоров с шинной архитектурой, мультикомпьютерные систе-

мы с шинной архитектурой имеют ограниченную масштабируемость. В зависи-

мости от того, сколько узлов в действительности нуждаются в обмене данными,

обычно не следует ожидать высокой производительности при превышении сис-

темой предела в 25-100 узлов.

В коммутируемых мультикомпьютерных системах сообщения, передаваемые

от процессора к процессору,

маршрутизируются

в соединительной сети в отли-

чие от принятых в шинной архитектуре широковещательных рассылок. Было

предложено и построено множество различных топологий. Две популярные то-

пологии

—

квадратные решетки и гиперкубы

—

представлены на рис. 1.7. Решет-

1.3. Концепции аппаратных решений 43

ки просты для понимания и удобны для разработки на их основе печатных плат.

Они прекрасно подходят для решения двухмерных задач, например задач теории

графов или компьютерного зрения (глаза робота, анализ фотографий).

Рис. 1.7. Решетка (а). Гиперкуб (б)

Гиперкуб (hypercube) представляет собой куб размерности п. Гиперкуб, по-

казанный на рис. 1.7, б, четырехмерен. Его можно представить в виде двух

обычных кубов, с 8 вершинами и 12 ребрами каждый. Каждая вершина

—

это

процессор. Каждое ребро

—

это связь между двумя процессорами. Соответствую-

щие вершины обоих кубов соединены между собой. Для расширения гиперкуба

в пятое измерение мы должны добавить к этой фигуре еще один комплект из

двух связанных кубов, соединив соответствующие вершины двух половинок фи-

гуры. Таким же образом можно создать шестимерный куб, семимерный и т. д.

Коммутируемые мультикомпьютерные системы могут быть очень разнооб-

разны. На одном конце спектра лежат

процессоры

массовым

параллелизмом

{Massively Parallel

Processors,

МРР), гигантские суперкомпьютеры стоимостью во

много миллионов долларов, содержащие тысячи процессоров. Нередко они со-

бираются из тех же процессоров, которые используются в рабочих станциях или

персональных компьютерах. От других мультикомпьютерных систем их отлича-

ет наличие патентованных высокоскоростных соединительных сетей. Эти сети

проектируются в расчете на малое время задержки и высокую пропускную спо-

собность. Кроме того, предпринимаются специальные меры для защиты системы

от сбоев. При наличии тысяч процессоров каждую неделю как минимум не-

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

них приводила к выводу из строя всей машины.

На другом конце спектра мы обнаруживаем популярный тип коммутируемых

микрокомпьютеров, известных как

кластеры

рабочих

станций {Clusters

Work-

stations, COW), основу которых составляют стандартные персональные компью-

теры или рабочие станции, соединенные посредством коммерческих коммуника-

ционных компонентов, таких как карты Myrinet [70]. Соединительные сети

—

вот то, что отличает COW от МРР. Кроме того, обычно не предпринимается ни-

каких особых мер для повышения скорости ввода-вывода или защиты от сбоев

в системе. Подобный подход делает COW проще и дешевле.

44 Глава 1. Введение

1.3.3.

Гетерогенные мультикомпьютерные

системы

Наибольшее число существующих в настоящее время распределенных систем по-

строено по схеме гетерогенных мультикомпьютерных. Это означает, что компью-

теры, являющиеся частями этой системы, могут быть крайне разнообразны,

например, по типу процессора, размеру памяти и производительности каналов

ввода-вывода. На практике роль некоторых из этих компьютеров могут испол-

нять высокопроизводительные параллельные системы, например мультипроцес-

сорные или гомогенные мультикомпьютерные.

Соединяющая их сеть также может быть сильно неоднородной. Так, напри-

мер,

авторы этой книги помогали! разрабатывать самодельную распределенную

компьютерную систему, названную DAS, состоящую из четырех кластеров муль-

тикомпьютерных систем, соединенных высокопроизводительными АТМ-комму-

тируемыми каналами. Фотографии этой системы и ссылки на исследования,

проводимые на ней, можно найти по адресу http://Www.cs.vu.nll-balldas.html. Кла-

стеры также были связаны между собой через стандартные Интернет-соедине-

ния. Каждый кластер содержал одинаковые процессоры (Pentium III) и соеди-

няющую их сеть (Myrinet), но различался по числу процессоров (64-128).

Другим примером гетерогенности является создание крупных мультикомпь-

ютерных систем с использованием существующих сетей и каналов. Так, напри-

мер,

не является чем-то необычным существование кампусных университетских

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

соединенных между собой высокоскоростными каналами. В глобальных систе-

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

тями, например сетевыми службами, предлагаемыми коммерческими оператора-

ми связи, например SMDS или Frame relay.

В отличие от систем, обсуждавшихся в предыдущих пунктах, многие крупно-

масштабные гетерогенные мультикомпьютерные системы нуждаются в глобаль-

ном подходе. Это означает, что приложение не может предполагать, что ему по-

стоянно будет доступна определенная производительность или определенные

службы. Так, в проекте I-way [147] несколько высокопроизводительных компь-

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

мы предполагалось, что прршожения будут резервировать и использовать ресур-

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

центрами оказалось невозможно.

Переходя к вопросам масштабирования, присущим гетерогенным системам,

и учитывая необходимость глобального подхода, присущую большинству из них,

заметим, что создание приложений для гетерогенных мультикомпьютерных сис-

тем требует специализированного программного обеспечения. С этой проблемой

распределенные системы справляются. Чтобы у разработчиков приложений не

возникало необходимости волноваться об используемом аппаратном обеспече-

нии, распределенные системы предоставляют программную оболочку, которая

защищает приложения от того, что происходит на аппаратном уровне (то есть

они обеспечивают прозрачность).

1.4. Концепции программных решений 45

1.4. Концепции программных решений

Аппаратура валена для распределенных систем, однако от программного обеспе-

чения значительно сильнее зависит, как такая система будет выглядеть на самом

деле.

Распределенные системы очень похожи на традиционные операционные

системы. Прежде всего, они работают

KCIK

менеджеры ресурсов (resource managers)

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

вателей и приложений совместно использовать такие ресурсы, как процессоры,

память, периферийные устройства, сеть и данные всех видов. Во-вторых, что, ве-

роятно, более важно, распределенная система скрывает сложность и гетероген-

ную природу аппаратного обеспечения, на базе которого она построена, предо-

ставляя виртуальную машину для выполнения приложений.

Чтобы понять природу распределенной системы, рассмотрим сначала опера-

ционные системы с точки зрения распределенности. Операционные системы для

распределенных компьютеров можно вчерне разделить на две категории

—

сильно

связанные и слабо связанные системы. В сильно связанных системах операцион-

ная система в основном старается работать с одним, глобальным представлением

ресурсов, которыми она управляет. Слабо связанные системы могут представ-

ляться несведущему человеку набором операционных систем, каждая из кото-

рых работает на собственном компьютере. Однако эти операционные системы

функционируют совместно, делая собственные службы доступными другим.

Это деление на сильно и слабо связанные системы связано с классификацией

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

ные операционные системы обычно называются

распределенными

операционны-

ми

системами

(Distributed

Operating

System,

DOS) и используются для управле-

ния мультипроцессорными и гомогенными мультикомпьютерными системами.

Как и у традиционных однопроцессорных операционных систем, основная цель

распределенной операционной системы состоит в сокрытии тонкостей управле-

ния аппаратным обеспечением, которое одновременно используется множеством

процессов.

Слабо связанные

сетевые операционные системы

(Network

Operating

Systems,

NOS) используются для управления гетерогенными мультикомпьютерными сис-

темами. Хотя управление аппаратным обеспечением и является основной зада-

чей сетевых операционных систем, они отличаются от традиционных. Это отли-

чие вытекает из того факта, что локальные службы должны быть доступными

для удаленных клиентов. В следующих пунктах мы рассмотрим в первом при-

ближении те и другие.

Чтобы действительно составить распределенную сргстему, служб сетевой опе-

рационной системы недостаточно. Необходимо добавить к ним дополнительные

компоненты, чтобы организовать лучшую поддержку прозрачности распределе-

ния. Этими дополнительными компонентами будут средства, известные как

систе-

мы промежуточного

уровня

(middleware),

которые и лежат в основе современных

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

в этой главе. В табл. 1.3 представлены основные данные по распределенным и се-

тевым операционным системам, а также средствам промежуточного уровня.

46 Глава 1. Введение

Таблица 1.3. Краткое описание распределенных и сетевых операционных систем,

а также средств промежуточного уровня

Система Описание Основное назначение

Распределенные

операционные

системы

Сетевые

операционные

системы

Средства

промежуточного

уровня

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

для мультипроцессоров

и гомогенных мультикомпьютерных систем

Слабо связанные операционные системы

для гетерогенных мультикомпьютерных

систем (локальных или глобальных сетей)

Дополнительный уровень поверх сетевых

операционных систем, реализующий

службы общего назначения

Сокрытие

управление

аппаратным

обеспечением

Предоставление

локальных служб

удаленным клиентам

Обеспечение

прозрачности

распределения

1.4.1.

Распределенные операционные системы

Существует два типа распределенных операционных систем.

Мультипроцессор-

пая операциоппая

система {multiprocessor operating

system) управляет ресурсами

мультипроцессора.

Мулътикомпыотерная

операциоппая система {multicomputer

operating system) разрабатывается

для

гомогенных мультикомпыотеров. Функ-

циональность распределенных операционных систем

основном

не

отличается

от функциональности традиционных операционных систем, предназначенных для

компьютеров

одним процессором

за

исключением того,

что она

поддерживает

функционирование нескольких процессоров. Поэтому давайте кратко обсудим

операционные системы, предназначенные для обыкновенных компьютеров

с од-

ним процессором. Введение

операционные системы

для

одного

нескольких

процессоров можно отыскать

[447].

Операционные системы для однопроцессорных

компьютеров

Операционные системы традиционно строились для управления компьютерами

с одним процессором. Основной задачей этих систем была организация легкого

доступа пользователей

приложений

разделяемым устройствам, таким

как

процессор, память, диски

периферийные устройства. Говоря

разделении

ре-

сурсов, мы имеем

виду возможность использования одного

того же аппарат-

ного обеспечения различными приложениями изолированно друг

от

друга.

Для

приложения это выглядит так, словно эти ресурсы находятся в его полном распо-

ряжении, при этом в одной системе может выполняться одновременно несколько

приложений, каждое со своим собственным набором ресурсов. В этом смысле го-

ворят,

что

операционная система реализует

виртуальпую

машипу {virtual

machi-

ne),

предоставляя приложениям средства мультизадачности.

Важным аспектом совместного использоварнш ресурсов

такой виртуальной

машине является то,

что

приложения отделены друг

от

друга. Так, невозможна

ситуация, когда

при

одновременном исполнении двух приложений,

Л и В,

при-

ложение Л может изменить данные приложения В, просто работая

той частью

общей памяти,

где эти

данные хранятся. Также требуется гарантировать,

что

1.4. Концепции программных решений 47

приложения смогут использовать предоставленные им средства только так, как

предписано операционной системой. Например, приложениям обычно запре-

щено копировать сообщения прямо в сетевой интерфейс. Взамен операционная

система предоставляет первичные операции связи, которые можно использовать

для пересылки сообщений между приложениями на различных машинах.

Следовательно, операционная система должна полностью контролировать ис-

пользование и распределение аппаратных ресурсов. Поэтому большинство про-

цессоров поддерживают как минимум два режима работы.

В реэюиме

ядра

{kernel

mode) выполняются все разрешенные инструкции, а в ходе выполнения доступна

вся имеющаяся память и любые регистры. Напротив, в

пользовательском режиме

{user

mode) доступ к регистрам и памяти ограничен. Так, приложению не будет

позволено работать с памятью за пределами набора адресов, установленного для

него операционной системой, или обращаться напрямую к регистрам устройств.

На время выполнения кода операционной системы процессор переключается

в режим ядра. Однако единственный способ перейти из пользовательского режима

в режим ядра

—

это сделать системный вызов, реализуемый через операционную

систему. Поскольку системные вызовы

—

это лишь базовые службы, предостав-

ляемые операционной системой, и поскольку ограничение доступа к памяти

и регистрам нередко реализуется аппаратно, операционная система в состоянии

полностью их контролировать.

Существование двух режимов работы привело к такой организации операци-

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

Результатом часто становятся гигантские монолитные программы, работающие

в едином адресном пространстве. Оборотная сторона такого подхода состоит в

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

нить или адаптировать компоненты операционной системы без полной переза-

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

С точки зрения открытости, проектирования программ, надежности или легко-

сти обслуживания монолитные операционные системы

—

это не самая лучшая

из идей.

Более удобен вариант с организацией операционной системы в виде двух час-

тей.

Одна часть содержит набор модулей для управления аппаратным обеспече-

нием, которые прекрасно могут выполняться в пользовательском режиме. На-

пример, управление памятью состоит в основном из отслеживания, какие блоки

памяти выделены под процессы, а какие свободны. Единственный момент, когда

мы нуждаемся в работе в режиме ядра,

—

это установка регистров блока управ-

ления памятью.

Вторая часть операционной системы содержит небольшое микроядро {mic-

rokernel),

содержащее исключительно код, который выполняется в режиме ядра.

На практике мР1кроядро должно содержать только код для установки регистров

устройств, пере1сяючения процессора с процесса на процесс, работы с блоком управ-

ления памятью и перехвата аппаратных прерываний. Кроме того, в нем обычно

содержится код, преобразующий вызовы соответствующих модулей пользова-

тельского уровня операционной системы в системные вызовы и возвращающий

результаты. Такой подход приводит к организации, показанной на рис. 1.8.

48 Глава 1. Введение

Между модулями отсутствует непосредственный обмен данными

Интерфейс _

операционной

системы

Системный

вызов

Приложение

Модуль

памяти

^ А

Модуль

процесса

^ А ь-

Файловый

модуль

_г—А—h-

Аппаратура

I Пользовательский

режим

Режим ядра

Рис. 1.8. Разделение приложений в операционной системе посредством микроядра

Р1спользование микроядра дает нам разнообразные преимущества. Наиболее

важное из них состоит в гибкости: поскольку большая часть операционной сис-

темы исполняется в пользовательском режиме, относительно несложно заменить

один из модулей без повторной компиляции или повторной установки всей сис-

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

уровня могут в принципе размещаться на разных машинах. Так, мы можем уста-

новить модуль управления файлами не на той машине, на которой он управляет

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

лично подходит для переноса однопроцессорных операционных систем на рас-

пределенные компьютеры.

У микроядер имеется два существенных недостатка. Во-первых, они работа-

ют иначе, чем существующие операционные системы, а попытки поменять сло-

жившееся «статус-кво» всегда встречают активное сопротивление («если эта

операционная система подходила для моего деда

—

она подойдет и для меня»).

Во-вторых, микроядро требует дополнительного обмена, что слегка снижает

производительность. Однако, зная как быстры современные процессоры, сниже-

ние производительности в 20 % вряд ли можно считать фатальным.

Мультипроцессорные операционные системы

Важным, но часто не слишком очевидным расширением однопроцессорных опе-

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

имеющих доступ к совместно используемой памяти. Концептуально это расши-

рение несложно. Все структуры данных, необходимые операционной системе для

поддержки аппаратуры, включая поддержку нескольких процессоров, размеща-

ются в памяти. Основная разница заключается в том, что теперь эти данные дос-

тупны нескольким процессорам и должны быть защищены от параллельного дос-

тупа для обеспечения их целостности.

Однако многие операционные системы, особенно предназначенные для пер-

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

несколько процессоров. Основная причина такого поведения состоит в том, что

они были разработаны как монолитные программы, которые могут выполняться

только в одном потоке управления. Адаптация таких операционных систем под

1.4. Концепции программных решений 49

мультипроцессорные означает повторное проектирование и новую реализацию

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

с учетом возможности работы в мультипроцессорных системах.

Многопроцессорные операционные системы нацелены на поддержание высо-

кой производительности конфигураций с несколькими процессорами. Основная

их задача

—

обеспечить прозрачность числа процессоров для приложения. Сде-

лать это достаточно легко, поскольку сообщение между различными приложе-

ниями или их частями требует тех же примитршов, что и в многозадачных одно-

процессорных операционных системах. Идея состоит в том, что все сообщение

происходит путем работы с данными в специальной совместно используемой об-

ласти данных, и все что нам нужно

—

это защитить данные от одновременного

доступа к ним. Защита осуществляется посредством примитивов синхрониза-

ции. Два наиболее важных (и эквивалентных) примитива

—

это семафоры и мо-

ниторы.

Семафор {semaphore) может быть представлен в виде целого числа, поддер-

живающего две операции: up (увеличить) и down (уменьшить). При уменьшении

сначала проверяется, превышает ли значение семафора 0. Если это так, его зна-

чение уменьшается и выполнение процесса продолжается. Если же значение се-

мафора нулевое, вызывающий процесс блокируется. Оператор увеличения со-

вершает противоположное действие. Сначала он проверяет все заблокированные

в настоящее время процессы, которые были неспособны завершиться в ходе пре-

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

один из них и продолжает работу. В противном случае он просто увеличивает

счетчик семафора. Разблокированный процесс выполняется до вызова операции

уменьшения. Важным свойством операций с семафорами является то, что они

атомарны

{atomic),

то есть в случае запуска операции уменьшения или увеличе-

ния до момента ее завершения (или до момента блокировки процесса) никакой

другой процесс не может получить доступ к семафору.

Известно, что программирование с использованием семафоров для синхрони-

зации процесса вызывает множество ошибок, кроме, разве что, случаев простой

защиты разделяемых данных. Основная проблема состоит в том, что наличие

семафоров приводит к неструктурированному коду. Похожая ситуация возника-

ет при частом использовании печально известной инструкции goto. В качестве

альтернативы семафорам многие современные системы, поддерживающие па-

раллельное программирование, предоставляют библиотеки для реализации мо-

ниторов.

Формально монитор {monitor) представляет собой конструкцию языка про-

граммирования, такую же, как объект в объектно-ориентированном программи-

ровании

[200].

Монитор может рассматриваться как модуль, содержащий пере-

менные и процедуры. Доступ к переменным можно получить только путем

вызова одной из процедур монитора. В этом смысле монитор очень похож на

объект. Объект также имеет свои защищенные данные, доступ к которым можно

получить только через методы, реализованные в этом объекте. Разница между

мониторами и объектами состоит в том, что монитор разрешает выполнение про-

цедуры только одному процессу в каждый момент времени. Другими словами,

50 Глава 1. Введение

если процедура, содержащаяся в мониторе, выполняется процессом А (мы гово-

рим, что А вошел в монитор) и процесс В также вызывает одну из процедур мо-

нитора, В будет блокирован до завершения выполнения А (то есть до тех пор, по-

ка А не покинет монитор).

В качестве примера рассмотрим простой монитор для защиты целой пере-

менной (листинг 1.1). Монитор содержит одну закрытую (private) переменную

count, доступ к которой можно получить только через три открытых (public)

процедуры

—

чтения текущего значения, увеличения на единицу и уменьше-

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

одну из этих процедур, получит атомарный доступ к внутренним данным мони-

тора.

Листинг 1.1. Монитор, предохраняющий целое число от параллельного доступа

monitor Counter {

private:

int count = 0:

public:

int valueO { return count; }

void incrO { count = count + 1;}

void decrO { count = count - 1;}

}

Итак, мониторы пригодны для простой защиты совместно используемых дан-

ных. Однако для условной блокировки процесса необходимо большее. Напри-

мер,

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

уменьшения, если обнаруживается, что значение count равно нулю. Для этой це-

ли в мониторах используются

условные переменные {condition

variables).

Это спе-

циальные переменные с двумя доступными операциями: wait (ждать) и signal

(сигнализировать). Когда процесс А находится в мониторе и вызывает для ус-

ловной переменной, хранящейся в мониторе, операцию wait, процесс А будет

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

ветственно, процесс В, ожидавший получения исключительного доступа к мони-

тору, сможет продолжить свою работу. В определенный момент времени В

может разблокировать процесс А вызовом операции signal для условной пере-

менной, которого ожидает А. Чтобы предотвратить наличие двух активных про-

цессов внутри монитора, мы доработаем схему так, чтобы процесс, подавший

сигнал, покидал монитор. Теперь мы можем переделать наш предыдущий при-

мер.

Монитор из листинга 1.2

—

это новая реализация обсуждавшегося ранее се-

мафора.

Листинг 1.2. Монитор, предохраняющий целое число от параллельного доступа

и блокирующий процесс

monitor Counter {

private:

int count = 0;

int blockecl_procs = 0;

condition unblocked:

public:

int valueO

{

return count:}