Составители:
Рубрика:
receive request(clientID, kind, args);
if (kind==op_1) {[тело op_1]};
. . . . . . . . . .
else if (kind==op_n) {[тело op_n]};
send reply[clientID](results);
}
}
process Client[i=0 to n-1]{
arg_type myargs; res_type myresults;
[поместить аргументы-значения в myargs];
send request(i, op_j, myargs); # вызов op_j
receive reply[i](myresults); # ждать ответа
}
Заметим, что при обслуживании клиента рассмотренному мони-
тору не приходится задерживаться, обслуживая запрос, т. к. тело
операции содержит лишь последовательные операции.
Однако, более общий вариант монитора использует условную
синхронизацию и поддерживает несколько операций; при этом учи-
тывается, что запрос может быть обработан с задержкой. Главное
отличие реализующего его серверного процесса состоит в том, что
сервер не может ждать, если нет доступного ресурса п о данному
запросу. Поэтому он запоминает запрос и откладывает посылку от-
вета до момента освобождения ресурса.
После отправки запроса клиент ждет получения ресурса (хо-
тя могут быть и другие варианты). После освобождения ресурса
клиент посылает сообщение о его освобождении, но не ждет его
обработки.
Сначала приведем монитор, а потом — реализующий его сервер.
МОНИТОР
monitor Resource_Allocator{
int avail=MAXUNITS;
set units=[начальные значения];
cond free;
36
Страницы
- « первая
- ‹ предыдущая
- …
- 33
- 34
- 35
- 36
- 37
- …
- следующая ›
- последняя »
