В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 30

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 30)

возобновление некоторой фиксированной "сопрограммы", указываемой оператором

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

мониторной процедуры или появления нужного сигнала.]

Сделаем выводы:

1. Мониторы обеспечивают высший уровень рациональной абстракции от

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

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

2. Мониторы обеспечивают надежность предоставляемых процессам-

пользователям услуг - пользователь не в силах "сломать" хорошо

спроектированный и отлаженный монитор.

3. Мониторы обеспечивают ясность программирования процессов

пользователей. Достаточно сравнить наш "идеал", в котором нет ничего

лишнего, и решение с помощью семафоров.

4. Мониторы обеспечивают эффективность, когда их используют вместе со

средствами пассивного ожидания (например, сигналами).

5. Режим взаимного исключения в мониторе встроен, синхронизация

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

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

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

Итак, мониторы многим хороши, но

представляя собой средство высокого уровня (абстракции), требуют

низкоуровневых средств для своей реализации (сигналов), т.е. не могут

служить единой концептуальной основой ЯПП;

провоцируют создание адмимнистративной иерархии программ там, где по

сути достаточно их непосредственного (горизонтального) взаимодействия. В

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

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

относительно много мониторов-посредников. [Это обычные недостатки

административной системы.]

Имеются и другие причины (в частности, невозможность единой стратегии

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

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

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

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

средств низкого уровня.

2. Поиск выразительных средств, обеспечивающих "демократическое"

взаимодействие процессов без лишних посредников.

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

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

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

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

полезные примитивы.

6.6. Рандеву

Основная идея (Хоар, Хансен - 1978г.): соединить синхронизацию и обмен

в одном примитиве, моделирующем встречу (свидание, рандеву) процессов-

партнеров.

Например, для передачи данных из переменной X процесса А в переменную Y

процесса В следует написать:

task A is task B is

X : сообщение; Y : сообщение;

. . . . . .

B ! X; -- заказываем A ? Y; -- заказываем

-- рандеву с процессом В -- рандеву с процессом

-- для передачи из -- А для приема в

-- переменной Х -- переменную Y

. . . . . .

end A; end B;

Семантику рандеву опишем на псевдокоде так:

if непуста (очередь партнеров) then

[выбрать партнера из очереди; выполнить присваивание

Y:=X;, активизировать партнера];

else [приостановить текущий процесс и поместить его

в очередь партнеров по рандеву к процессу, с которым

заказывается рандеву];

Итак, процесс А, желающий передать сообщение процессу В (своему

партнеру), должен "заказать" с ним рандеву посредством конструкта В!Х. Чтобы

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

двойственного конструкта А?Y.

Внешняя среда принимает эти заказы и приостанавливает партнера, первым

подавшего заказ (первым пришедшего на рандеву) до подачи заказа вторым

партнером (т.е. до его "прибытия" на рандеву). Когда оба партнера готовы,

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

не наблюдают").

[Последнее сказано скорее для красного словца. Лучше было бы сказать,

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

(симметрично)].

Итак, в рандеву соединены синхронизация (взаимное ожидание) и обмен

(присваивание). В рандеву воплощена вполне "демократическая" идея

"горизонтальных", прямых связей между партнерами. В результате общие

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

ним. Однако все это только в случае единичного обмена.

При регулярном обмене, как в задаче "поставщик-потребитель", требуется

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

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

Эта проблема решается за счет моделирования посредством рандеву

активного разделяемого ресурса - аналога пассивного буфера-монитора. Здесь

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

рандеву - с его помощью легко моделировать нужные конструкты. Правда, для

этого требуются процессы-посредники - и это основной недостаток рандеву как

примитива.

Итак, наш новый (активный) буфер будет процессом-посредником,

взаимодействующим посредством рандеву и с поставщиком, и с потребителем.

Назовем этот процесс "буф":

task Пост is task Потр is

. . . . . .

буф ! Х; буф ? Y;

. . . . . .

end поставщик; end потребитель;

[Полезно обратить внимание на эту конфигурацию. Она может служить

источником новых идей (см. ниже о каналах)].

task буф is

. . .

Пост ? Z;

. . .

Потр ! Z;

. . .

end буф;

6.7. Проблемы рандеву

Итак,

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

связывает только активные объекты (при их взаимном "согласии").

б. Достаточно взглянуть на наш "буф", чтобы понять, что без специальных

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

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

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

возможных) готовы потенциальные партнеры.

Поскольку о такой готовности знает только операционная (внешняя) среда,

она и должна доставлять соответствующие средства отбора готовых к рандеву

партнеров. Примеры таких средств рассмотрим позже (это, например, оператор

select в Аде, alt в Оккаме).

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

формально его готовность к работе не требовалась.

в. Партнеры должны называть друг друга по именам (должны "знать" друг

друга). Это неудобно, если роль одного из партнеров - обслуживать

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

вовсе необязательно "знать" имена пользующихся его услугами процессов. По

этому принципу устроен любой общедоступный сервис.

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

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

- "клиентов"). Но в таком случае возникают неприятные вопросы о способе

передачи значения такого параметра. Статическая передача имени клиента (в

период трансляции) не дает возможности менять клиентов в динамике. А

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

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

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

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

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

неформальная теорема (о симметричном рандеву). С другой - именно она

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

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

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

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

ведь это базовый ЯП для систем реального времени (т.е. прежде всего для

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

времени). Важно и то, что ассиметричное рандеву лучше согласуется с Адовской

концепцией строгого контроля типов.

6.10. Ассиметричное рандеву (Бринч Хансен для Ады - 1977г.).

Основная идея: "сервис вместо свидания" - сохранив партнерство

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

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

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

партнере, "мастере").

Иногда говорят "процесс-слуга" и "процесс-хозяин". Однако так менее

выразительно. Ведь слуга знает хозяина (если только это не "слуга народа").

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

анонимного клиента. Поэтому мы и предпочитаем термины "клиент" и "мастер".

Точнее говоря, для определенного вида взаимодействия (вида рандеву)

выделяется процесс-мастер, предоставляющий услуги этого вида при

соответствующем рандеву. Остальные процессы по отношению к этому виду услуг

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

вида с соответствующим мастером.

При этом для клиента предоставление ему услуги неотличимо от вызова им

подходящей процедуры. Другими словами, он совершенно "не замечает"

асинхронного характера своего взаимодействия с мастером. Все особенности

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

мастере. Это проявляется, в частности, в том, что в мастере предоставление

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

операторами приема входа "accept" и др.).

Итак, при переходе к асимметричному рандеву:

а) можно написать библиотечного мастера;

б) в отличие от симметричного рандеву проще реализовать произвольные

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

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

но вполне удобно запрограммировать аналогично некоторой процедуре.];

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

управления (аналогично обслуживающему ранее рассмотренные примитивы); в Аде

это операторы accept, select и объявление входа (содержательно это

объявление вида рандеву).

6.8. Управление асимметричным рандеву (семантика вспомогательных

конструктов)

Объявление входа в Аде имеет вид заголовка процедуры, перед которым

стоит ключевое слово entry. Например,

task семафор is

entry оградить; -- без параметров, так как

entry освободить; -- семафор фиксирован.

end семафор;

Здесь записана спецификация задачи (в Аде), моделирующей семафор.

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

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

(если снабдить его соответствующим телом (см. ниже)).

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

процедуре. Например

. . .

оградить;

. . .

освободить;

. . .

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

входы одного мастера работают в режиме взаимного исключения (это - следствие

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

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

асинхронно (в том числе одновременно) из разных процессов.

Рассмотрим теперь оператор приема входа. Мастер считается готовым к

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

входа" вида

accept < заголовок_процедуры >

[ do < операторы > end ];

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

entry в объявлении входа.

Когда и партнер-клиент готов (т.е. его управление достигает оператора

вызова соответствующей процедуры-входа), то требуемая синхронизация

Характеристики

Список файлов книги