том – Координатором Банкомата. Когда этой задаче приходит но-

вый Запрос Управлению Банкоматом, его принимает Координатор Банкомата, который извлекает из запроса событие и вызывает опе-

рацию УправлениеБанкоматом. ОбработатьСобытие (in событие, out действие). Объект Управление Банкоматом просматривает таб-

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

та Интерфейс Устройства Выдачи Наличных, которой в качестве входного параметра передается сумма, а в качестве выходного – ре- зультатВыдачи. Если же действие состоит в печати чека, то вызыва-

ется операция печататьЧек объекта Интерфейс Устройства Печа-

ти Чеков, которой в качестве входного параметра передается инфор-

мацияЧека, а в качестве выходного – результатПечати.

10.2. Синхронизация доступа к классам

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

10.2.1. Пример синхронизации доступа к классу. В качестве примера рассмотрим класс абстрагирования данных Хранилище По- казаний Аналоговых Датчиков. При проектировании этого класса нужно принять решение о том, будет ли информация храниться в массиве или в связанном списке. Другое решение касается синхрони- зации: может ли к объекту такого класса осуществляться параллель- ный доступ и, если да, следует использовать алгоритм взаимного ис- ключения или алгоритм читателей и писателей. Оба решения отно- сятся только к проектированию класса, не затрагивая его пользовате- лей.

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

www.pdffactory.com

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

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

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

10.2.2. Операции класса абстрагирования данных. Сохранив внешний интерфейс класса Хранилище Показаний Аналоговых Дат- чиков, рассмотрим два разных метода синхронизации доступа к хра- нилищу:взаимное исключение и алгоритм читателей и писателей.

Наш класс предоставляет две операции (рис.10.3):

читатьАналоговыйДатчик (in идДатчика,

out значениеДатчика, out верхнийПредел, out нижнийПредел, out условиеТревоги)

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

обновитьАналоговыйДатчик (in идДатчика, in значениеДатчика)

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

www.pdffactory.com

Рис.10.3. Пример параллельного доступа к объекту абстрагирования данных

10.2.3. Синхронизация методом взаимного исключения. Сначала рассмотрим решение, основанное на взаимном исключении. В таком случае используется предоставляемый операционной системой дво- ичный семафор, у которого есть операции acquire (запросить) и release (освободить). Чтобы гарантировать взаимное исключение, каж- дая задача должна вызвать операцию acquire семафора readWriteSemaphore (изначально он установлен в единицу) перед тем, как пы- таться получить доступ к хранилищу. Закончив работу с хранилищем, задача обращается к операции release. Вот псевдокод операций чте- ния и обновления:

class ХранилищеПоказанийАналоговыхДатчиков private readWriteSemaphore : Semaphore := 1 public читатьАналоговыйДатчик (in идДатчика;, out значениеДатчика, out верхнийПредел,

out нижнийПредел, out условиеТревоги) -- Критическая секция операции чтения. acquire (readWriteSemaphore) ;

значениеДатчика := хранилищеПоказаний (идДатчика, значение);

www.pdffactory.com

верхнийПредел := хранилищеПоказаний (идДатчика, верх); нижнийПредел := хранилищеПоказаний (идДатчика, низ);

условиеТревоги := хранилищеПоказаний (идДатчика; тревога); release(readWriteSemaphore);

end читатьАналоговыйДатчик;

При выполнении операции обновить надо не только записать в хранилище новое значение датчика, но и проверить условие тревоги:

public обновитьАналоговыйДатчик (in идДатчика, in значениеДатчика)

-- Критическая секция операции записи. acquire (readWriteSemaphore);

хранилищеПоказаний (идДатчика, значение) := значениеДатчика;

if значениеДатчика >= хранилищеПоказаний АналоговыхДатчиков(идДатчика, верх)

then хранилищеПоказаний (идДатчика, тревога) := верх;

elseif значениеДатчика<= хранилищеПоказаний(идДатчика, низ)

then хранилищеПоказаний (идДатчика, тревога) := низ;

else хранилищеПоказаний (идДатчика, тревога) := норма;

end if; release(readWriteSemaphore);

end обновитьАналоговыйДатчик;

10.2.4. Синхронизация нескольких читателей и писателей. При-

менение указанного метода позволяет нескольким читателям одно- временно обращаться к хранилищу, но любой писатель получает мо- нопольный доступ. Для этого применяются два двоичных семафора: readerSemaphore и readWriteSemaphore, инициализированных значе-

нием 1. Кроме того, хранится текущее число Читателей, первона-

www.pdffactory.com

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

class ХранилищеПоказанийАналоговыхДатчиков private числоЧитателей : Integer : = 0;

readerSemaphore :. Semaphore := 1; readWriteSemaphore : Semaphore := 1;

public читатьАналоговыйДатчик (in идДатчика, out значениеДатчика, out верхнийПредел, out нижнийПредел, out условиеТревоги)

--Операция чтения вызывается задачами-

--читателями. Доступ к хранилищу разрешен

--одновременно нескольким читателям

--при условии, что нет ни одного писателя. acquire (readerSemaphore) ;

Увеличить числоЧитателей; if числоЧитателей = 1

then acquire (readWriteSemaphpre) ; release (readerSemaphore) ;

значениеДатчика := хранилищеПоказаний (идДатчика, значение); верхнийПредел := хранилищеПоказаний (идДатчика, верх); нижнийПредел := хранилищеПоказаний (идДатчика, низ);

условиеТревоги := хранилищеПоказаний (идДатчика, тревога);

acquire (readerSemaphore) ;

Уменьшить числоЧитателей; if числоЧитателей = 0

then release (readWriteSemaphore); release(readerSemaphore);

end читатьАналоговыйДатчик;

www.pdffactory.com

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

public обновитьАналоговыйДатчик (in идДатчика, in значениеДатчика)

-- Критическая секция операции записи. acquire (readWriteSemaphore) ;

хранилищеПоказаний (идДатчика, значение) := значениеДатчика;

if значениеДатчика >= хранилищеПоказаний (идДатчика, верх)

then хранилищеПоказаний (идДатчика, тревога) := верх;

elseif значениеДатчика <= хранилищеПоказаний (идДатчика,. низ) then хранилищеПоказаний (идДатчика, тревога) := низ;

else хранилищеПоказаний (идДатчика, тревога) := норма;

end if; release(readWriteSemaphore) ;

end обновитьАналоговыйДатчик;

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

10.2.5. Синхронизация нескольких читателей и писателей с по-

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

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

www.pdffactory.com

должна одновременно выполняться несколькими читателями. Поэто- му мы поступим иначе: инкапсулируем аспекты алгоритма читателей

иписателей, касающиеся синхронизации, в монитор и перепроекти-

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

Объявим монитор ReadWrite, который использует два семафора

ипредоставляет четыре взаимно исключающие операции. Семафоры назовем reader Semaphore и readWriteSemaphore. Четыре вышеупомя- нутые операции – это startRead, endRead, startWrite и endWrite. Зада-

ча-читатель вызывает операцию startRead перед началом чтения и операцию endRead после его окончания. Задача-писатель вызывает операцию startWrite перед началом чтения и операцию endWrite после его окончания. Устройство монитора на базе семафоров описано в разделе 3.8.2. Такой монитор предоставляет для захвата ресурса опе- рацию acquire, которая может приостановить задачу, если ресурс за- нят, а также операцию release для освобождения ресурса.

Операция startRead сначала должна захватить семафор readerSemaphore, увеличить число читателей и освободить семафор. Если счетчик читателей был равен нулю, то startRead должна захватить семафор readWriteSemaphore, который занимает первый читатель, а освобождает последний. Хотя операции монитора выполняются вза- имно исключающим образом, семафор readerSemaphore все же ну- жен. Дело в том, что читатель может быть приостановлен в ожидании семафора readWriteSemaphore, в подобном случае он разблокирует монитор ReadWrite. Если другой читатель в этот момент захватит мо- нитор, вызвав startRead или endRead, он будет ожидать семафора readerSemaphore. Ниже представлен проект монитора ReadWrite:

monitor ReadWrite

--Предназначен для предоставления доступа к

--ресурсам нескольким читателям и одному

--писателю.

--Объявляет целочисленный счетчик числа

--читателей.

--Объявляет семафор для доступа к счетчику

--читателей.

www.pdffactory.com

-- Объявляет семафор для взаимно -- исключающего доступа к буферу. private числоЧитателей : Integer = 0;

readerSemaphore : Semaphore; readWriteSemaphore : Semaphore;

public startRead ()

--Читатель вызывает эту операцию перед

--началом чтения. readerSemaphore.acquire; if числоЧитателей = 0

then readWriteSemaphore.acquire;

Увеличить числоЧитателей; readerSemaphore.release;

end startRead; public endRead ()

--Читатель вызывает эту операцию после

--окончания чтения. readerSemaphore.acquire ;

Уменьшить числоЧитателей; if числоЧитателей = 0

then readWriteSemaphore.release; readerSemaphore.release;

end endRead;

public startWrite ()

--Писатель вызывает эту операцию перед -- началом записи. readWriteSemaphore.acquire;

end startWrite; public endWrite ()

--Писатель вызывает эту операцию после

--окончания записи. readWriteSemaphore.release;

end endWrite; end ReadWrite;

Теперь перепроектируем класс Хранилище Показаний Аналого- вых Датчиков так, чтобы он мог воспользоваться монитором ReadWrite. Для этого объявим в нем закрытый экземпляр монитора. Опе- рация читатьАналоговыйДатчик теперь вызывает операцию мони-

www.pdffactory.com

тора startRead перед началом чтения из хранилища и операцию endRead после его окончания. Операция обновитьАналоговыйДатчик вызывает операцию монитора startWrite перед началом записи в хра- нилище и операцию endWrite после ее окончания.

class ХранилищеПоказанийАналоговыхДатчиков private multiReadSingleWrite : ReadWrite public читатьАналоговыйДатчик (in идДатчика, out значениеДатчика, out верхнийПредел,

out нижнийПредел, out условиеТревоги) multiReadSingleWrite.startRead();

значениеДатчика : == хранилищеПоказаний (идДатчика, значение);

верхнийПредел := хранилищеПоказаний (идДатчика, верх); нижнийПредел := хранилищеПоказаний

(идДатчика, низ); условиеТревоги := хранилищеПоказаний

(идДатчика, тревога); multiReadSingleWrite.endRead() ;

end читатьАналоговыйДатчик;

public обновитьАналоговыйДатчик (in идДатчика, in значениеДатчика)

-- Критическая секция операции записи. multiReadSingleWrite.startWrite() ;

хранилищеПоказаний (идДатчика, значение) := значениеДатчика;

if значениеДатчика >= хранилищеПоказаний (идДатчика, верх)

then хранилищеПоказаний (идДатчика, тревога) := верх;

elseif значениеДатчика <= хранилищеПоказаний (идДатчика, низ)

then хранилищеПоказаний (идДатчика, тревога) := низ;

else хранилищеПоказаний (идДатчика, тревога) := норма;

end if; multiReadSingleWrite.endWrite();

www.pdffactory.com

end обновитьАналоговыйДатчик;

end ХранилищеПоказанийАналоговыхДатчиков;

10.2.6. Синхронизация нескольких читателей и писателей без ущемления писателей. В предыдущем варианте решения есть одно неудобство. Если от читателей постоянно поступают запросы на чте- ние, писателю в течение неопределенно долгого времени может быть отказано в доступе к хранилищу. Этот феномен называется ущемле- нием писателя (writer starvation). Ниже показано решение проблемы путем введения дополнительного семафора writer Waiting. Операция startWrite теперь должна захватить семафор writerWaiting до захвата семафора readWrite Semaphore. Операция startRead захватывает (и ос- вобождает) семафор writerWaiting перед тем, как захватить reader Semaphore.

Поясним, для чего нужны такие изменения. Предположим, что несколько читателей заняты чтением, а писатель в этот момент пыта- ется обновить данные. Он успешно захватывает семафор writerWaiting, но дальше вынужден ждать, пока читатели освободят семафор readWriteSemaphore. Если приходит новый читатель, то он вызывает startRead и приостанавливается, ожидая освобождения семафора writerWaiting. Тем временем уже имеющиеся читатели заканчивают свои операции, и последний освобождает семафор readWriteSemaphore, который тут же переходит в распоряжение ожидающего писа- теля, а тот освобождает семафор writerWaiting, позволяя занять его читателю или писателю. В приведенном ниже псевдокоде реализации операций startRead и startWrite изменены:

monitor ReadWrite

--Предотвращает ущемление писателей за счет

--дополнительного семафора.

--Предназначен для предоставления доступа к

--ресурсам нескольким читателям и одному

--писателю.

--Объявляет целочисленный счетчик числа

--читателей.

--Объявляет семафор для доступа к счетчику

--читателей.

--Объявляет семафор для взаимно

www.pdffactory.com

-- исключающего доступа к буферу. -- Объявляет семафор для ожидающих -- писателей.

private числоЧитателей : Integer = 0; readerSemaphore : Semaphore; readWriteSemaphore: Semaphore; writerWaitingSemaphore : Semaphore;

public startRead ()

--Читатель вызывает эту операцию перед

--началом чтения. writerWaitingSemaphore.acquire; writerWaitingSemaphore.release; readerSemaphore.acquire;

if числоЧитателей = 0

then readWriteSemaphore.acquire;

Увеличить числоЧитателей; readerSemaphore.release;

end startRead; public endRead ()

--Читатель вызывает эту операцию после

--окончания чтения. readerSemaphore.acqui.re;

Уменьшить числоЧитателей; if числоЧитателей = 0

then readWriteSemaphore.release;

readerSemaphore.release; end endRead;

public startWrite ()

--Писатель вызывает эту операцию перед

--началом записи. writerWaitingSemaphore.acquire; readWriteSemaphore.acquire; writerWaitingSemaphore.release;

end startWrite; public endWrite ()

--Писатель вызывает эту операцию после

--окончания записи. readWriteSemaphore.release;

www.pdffactory.com

end endWrite; end ReadWrite;

Класс Хранилище Показаний Аналоговых Датчиков может пользоваться всеми преимуществами нового решения, хотя мы не из- менили в нем ни одной строчки.

10.3. Проектирование разъемов для межзадачных коммуникаций

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

Сервисы для межзадачных коммуникаций и синхронизации может предоставлять многозадачное ядро. Подобные механизмы есть также в некоторых языках параллельного программирования, в частности Ada или Java. Но ни один из этих языков не поддерживает слабо свя- занный обмен сообщениями. Чтобы реализовать указанную возмож- ность, необходимо спроектировать скрывающий информацию класс MessageQueue, инкапсулирующий очередь сообщений и предостав- ляющий операции для доступа к ней. Классы такого вида называются

разъемами.

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

зоваться как в однопроцессорной так и в многопроцессорной системе

сразделяемой памятью.

10.3.1.Проектирование разъема, реализующего очередь сооб-

щений. Разъем, реализующий очередь сообщений, используется для инкапсуляции механизма слабо связанного обмена сообщениями. Это монитор, инкапсулирующий очередь, которая обычно существует в виде связанного списка. Разъем предоставляет синхронизированные операции send для отправки сообщения (вызывается задачей- производителем) и receive для получения сообщения (вызывается за- дачей-получателем) – рис.10.4. Производитель приостанавливается, если очередь заполнена (messageCount = maxCount) и возобновляет работу, когда освобождается место для размещения нового сообще-

www.pdffactory.com

ния. Поместив сообщение в очередь, производитель продолжает ра- ботать и в состоянии посылать новые сообщения. Потребитель при- останавливается, когда очередь пуста (messageCount = 0) и ак- тивизируется, как только в очередь поступит сообщение. Потреби- тель не приостанавливается, если в очереди есть сообщения. Предпо- лагается, что может быть несколько производителей и один потреби- тель.

Рис. 10.4. Пример разъема для реализации очереди сообщений

monitor MessageQueue

--Инкапсулирует очередь сообщений,

--рассчитанную максимум на maxCount

--сообщений. Операции монитора выполняются

--взаимно исключающим образом.

private maxCount : Integer; private messageCount : Integer = 0; public send (in message)

while messageCount = maxCount do wait;

Поместить сообщение в очередь;

Увеличить messageCount;

if messageCount = 1 then signal; end send;

public receive (out message) while messageCount = 0 do wait;

Извлечь сообщение из очереди;

www.pdffactory.com

Уменьшить messageCount;

if messageCount = maxCount - 1 then signal; end receive;

end MessageQueue;

10.3.2. Проектирование разъема, реализующего буфер сообще-

ний. Разъем, реализующий буфер сообщений, используется для ин-

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

Разъем предоставляет синхронизированные операции для отправки и получения сообщений (рис. 10.5). Производитель вызывает операцию send, а потребитель – операцию receive. Производитель приостанав- ливается, если буфер заполнен. Поместив сообщение в буфер, произ- водитель ждет, пока потребитель примет его. Потребитель приоста- навливается, когда буфер пуст. Предполагается, что может быть не- сколько производителей и один потребитель.

monitor MessageBuffer

--Инкапсулирует буфер сообщений, в котором

--может находиться не более одного

--сообщения. Операции монитора выполняются

--взаимно исключающим образом.

private messageBufferFull : Boolean = false; private messageCount : Integer = 0;

public send (in message)

Поместить сообщение в буфер; messageBufferFull = true; signal;

while messageBufferFull = true do wait; end send;

public receive (out message)

while messageBufferFull = false do wait;

Извлечь сообщение из буфера; messageBufferFull = false; signal;

end receive;

end MessageBuffer;

www.pdffactory.com

Рис. 10.5. Пример разъема для реализации буфера сообщений

10.3.3. Проектирование разъема, реализующего буфер сообще-

ний с ответом. Разъем, реализующий буфер сообщений с ответом,

используется для инкапсуляции механизма сильно связанного обмена сообщениями с ответом. Это монитор, инкапсулирующий буфер на одно сообщение и буфер на один ответ. Разъем предоставляет син- хронизированные операции для отправки и получения сообщений, а также для отправки ответа (рис.10.6). Производитель вызывает опе- рацию send для пересылки сообщения, а потребитель – операцию receive для приема сообщения и операцию reply для отправки ответа. Поместив сообщение в буфер, производитель ждет ответа от потре- бителя. Потребитель приостанавливается, когда буфер пуст. Предпо- лагается, что может быть несколько производителей и один потреби- тель.

monitor MessageBuffer&Response

--Инкапсулирует буфер сообщений, в котором

--может находиться не более одного

--сообщения, и буфер, в котором может

--находиться не более одного ответа.

--Операции монитора выполняются взаимно

--исключающим образом.

private messageBufferFull : Boolean = false; private responseBufferFull : Boolean = false; private messageCount : Integer = 0;

public send (in message)

www.pdffactory.com

Поместить сообщение в буфер; messageBufferFull = true; signal ;

while responseBufferFull = false do wait;

Извлечь ответ из буфера; responseBufferFull = false;

end send;

public receive (out message)

while messageBufferFull = false do wait;

Извлечь сообщение из буфера; messageBufferFull = false;

end receive;

public reply (in response)

Поместить ответ в буфер; responseBufferFull = true; signal ;

end reply;

end MessageBuffer&Response

Рис.10.6. Пример разъема для реализации буфера сообщений с ответом

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

www.pdffactory.com

Разъемы для этой подсистемы изображены на рис.10.7; есть два разъ- ема – очереди сообщений и один разъем – буфер сообщений.

Объект Очередь Сообщений Управления Банкоматом инкапсу-

лирует очередь входных сообщений задачи Контроллер Банкомата, для которой есть несколько производителей. Объект Очередь Сооб- щений Приглашений инкапсулирует очередь сообщений, посылаемых задачей Контроллер Банкомата задаче Интерфейс Клиента. И в том, и в другом случае производитель вызывает операцию send объ- екта-разъема, а потребитель – операцию receive того же объекта.

Имеется также разъем буфер Сообщений Устройства Считывания,

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

ми Контроллер Банкомата и Интерфейс Устройства Считывания Карточек.

Наконец, есть объект заместитель Банковского Сервера. Он скрывает детали коммуникации с удаленным Банковским Сервером, применяя синхронный обмен сообщениями без ответа. Например, в языке Java этот заместитель воспользовался бы механизмом вызова удаленных методов (RMI), описанным ранее.

Рис.10.7. Пример кооперативных задач, использующих разъемы

www.pdffactory.com