обслужен»), а активизировать эту задачу нужно будет не во всех случаях, когда приходит почта, а только при поступлении корреспонденции на имя конкретного клиента. Как было выяснено в гл. 3, реализация специальной дисциплины обслуживания с использованием параметров вызова в языке Ада весьма затруднительна. Обойти эти трудности можно, если предоставить каждому клиенту «почтового отделения» свой собственный внутренний вход в задачу пакета MAILROOM. Очевидно, что

I----

MAIL р

ITEM (с задер

жкой)

Пакет "почтовое отделение"

Ожидания нет

SEND

RCVE

CUSTOMER NAME MAILITEM (если есть.

Задачи-клиенты

Рис. 5.7. Динамическая взаимосвязь в обратном направлении при получении почты в системе «почтовое отделение».

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

Рассмотренная ситуация является примером, когда желательна динамическая связь в обратном направлении. Вместо того чтобы организовывать внутреннюю входную очередь к процедуре RCVE, можно использовать эту процедуру для передачи параметров вызова пакету MAILROOM. Если в данный момент для вызывающей задачи корреспонденции нет, то она может выполнять свои собственные действия до тех пор, пока опять не окажется готовой к получению сообщений. Для этого она должна активизировать оператор приема, принадлежащий входу, к которому обратился пакет MAILROOM, когда поступит соответствующая «корреспонденция».

Такой способ реализации взаимодействий иллюстрируется на рис. 5.7. Единственное, за чем здесь нужно следить, это чтобы задачи почтового пакета (который, разумеется, представляет собой активный пакет) не заставляли задачи-потре-

бители ждать приема вызовов GIVE (ВЫДАЧА) и тем самым не задерживали других клиентов, желающих отослать или получить почту.

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

MAILBOX*,

release

Пакет "почтовое отделение" Ожидание почты

rcve

Задачи-клиенты

Рис. 5.8. Статическая взаимосвязь в прямом направлении при получении почты в системе «почтовое отделение».

RCVE удобен лишь для получения только одного почтового отправления.

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

Единственной альтернативой динамической взаимосвязи является организация почтовых ящиков. Почтовые ящики похожи на окошки в примере BANK с той лишь разницей, что они могут использоваться для многократного взаимодействия с почтовым пакетом. Этот подход иллюстрируется на рис. 5.8. Клиенты могут абонировать и освобождать почтовые ящики, используя их идентификаторы для передачи и получения сообщений. Внутри почтового пакета идентификаторы почтовых ящиков могут быть использованы для индексирования элементов семейства входов. Таким образом, имея почтовый ящик,

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

5.2.3. Динамическое порождение задач

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

• путем объявления экземпляров определенных типов, порождаемых в динамике, например, локально в процедуре;

• путем определения параметров доступа (указателей) для различных типов задач и порождения их конкретных экземпляров с использованием оператора NEW.

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

Пример динамического порождения задач по мере возникновения надобности в них (для системы BANK) представлен на рис. 5.9. Заметим, что тело задачи TELLER-TYPE не содержит цикла, вследствие чего каждый экземпляр задачи существует лишь то время, в течение которого он работает. В целях упрощения в этом примере не наложено никаких ограничений на количество порождаемых задач-кассиров.

Более важно в аспекте проблем проектирования рассмотреть затронутый выше вопрос о том, что для обеспечения динамической связи задач должны использоваться их параметры доступа. При таком подходе необходимо динамическое порождение задач, но совсем не обязательно это должно делаться по требованию, как показано на рис. 5.9. Например, в системе BANK задачи кассиров могли бы порождаться диспетчером в процессе их запуска, а затем им могли бы передаваться их параметры доступа для дальнейшей «самоидеитификации». Указанный принцип в логическом плане очень близок к использованию номеров окошек (рис. 5.1, а), но только теперь номера окошек заменяются параметрами доступа.