Главная » Мануалы

1 ... 5 6 7 8 9 10 11 ... 32

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

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

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

4. Буфер: комбинация компонентов планировщик и исполнитель ; реализует прием информационных объектов на хранение и их отбор для передачи.

5. Секретарь: задача, обладающая большей автономностью по сравнению с планировщиком-исполнителем (буфером); она не только выполняет сервисные функции и осуществляет планирование процессов, но и обращается к другим задачам за получением результатов их выполнения.

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

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

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

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



Отправитель \ ) -О Вызывающий



/ \ Вызываемый

Адресат


(а] в зависимости от направления (S] В зависимости от направления

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

Рнс. 3.13, Классификация системных модулей в зависимости от направления пересылки данных и управляющих воздействий,

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

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

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

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

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

Задачи и активные пакеты полезно разбить на классы в зависимости от направления их взаимодействий с другими задачами и активными пакетами в операциях управления и передачи данных. Такая классификация представлена на рис. 3.13.

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



НИЯ конкретных примеров проектирования в последующих главах.

Проанализируем теперь взаимодействие нескольких задач с пассивным пакетом коллективного пользования; возникающая при этом проблема координации может быть решена так, как показано на рис. 3.14, а, где изображен пакет STACK (гл. 2). Видимые процедуры этого пакета имеют доступ к общим внутренним данным. Будет ли стек в действительности использоваться несколькими задачами или нет, не имеет значения для понимания существа развиваемых здесь идей. На рисунке приведены структурные графы и скелеты программ для его основных компонент.

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

Пассивный стековый пакете иcxoднo? виде (см. рис. 2.3, 2.4)

PUSH

Д' SPACE

package STACK is

procedure PUSH (.. .);

procedure POP {...); end STACK;

package body STACK is

procedure PUSH {...) is

- -ВЫПОЛНЯET ФУНК1ДИЮ PUSH, ИСПОЛЬЗУЯ ОБЩУЮ -- ПАМЯТЬ SPACE

end PUSH;

procedure POP (,..) is

- - ВЫПОЛНЯЕТ ФУНКЦИЮ РОР,ИСПОЛЬЗУЯ ОБЩУЮ : -- ПАМЯТЬ SPACE

end POP: end STACK;

(a) Исходный пассивный пакет. Рис. 3.14. Пакеты коллективного пользования; пример организации стека.




task STACK is

entry PUSH (. . .);

entry POP (. . .); end STACK;

task body STACK is

procedure INTERNAL PUSH is

- - ВЫПОЛНЯЕТ ФУНКЦИЮ РиЗН/ИСПОЛЬЗУЯ ОБЩУЮ -- ПАМЯТЬ SPACE end INTERNAL PUSH;

procedure INTERNALPOP is

ВЫПОЛНЯЕТ ФУНКЦИЮ POP, ИСПОЛЬЗУЯ ОБЩУЮ -- ПАМЯТЬ SPACE end INTERNALPOP;

begin loop select

accept PUSH (...] do INTERNAL PUSH; end)

accept POP (,.,) do INTERNAL POP; end; end select; end loop; end STACK;

(6) Эквивалентная задача.

Рис. 3.14 (продолжение),

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

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

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



НОЙ задачей-планировщиком, обеспечивающей исключение взаимных наложений.

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

Можно ли считать какое-либо из предложенных на рис. 3.14 решений предпочтительнее других? Решение на рис. 3.14,6 привлекательно тем, что в нем используется единственная задача-исполнитель; оно сочетает интуитивную очевидность с высокой надежностью. Решение, представленное на рис. 3.14, в, заманчиво тем, что в нем сохраняется неизменным внешний вид исходного пакета. Наконец, техническое решение, показанное

push

Вложенная задача-планировщик


internal-push

space J

internal-pop

Активный

стековый

пакет

package body stack is

task scheduler is

entry seize;

entry release; end scheduler;

task body scheduler is separate;

procedure internalpush (. , .) is

выполняет функцию push, используя общую память space end internal push;

procedure internal pop (. ..] is

- - выполняет функцию pop, используя Общую память space

end internal pop;

procedure push is begin

scheduler.seize; internal push (. . .]; scheduler.release; end push;.

procedure pop is begin

scheduler.seize; internal pop(. ..i; schedule r.release;

end pop; end stack

(e] Эквивалентный активный пвквт. Рис. 3.14 (продолжение).



separate (STACK) task body SCHEDULER Is BUSY : boolean := FALSE; begin loop select

Ч when not BUSY=>, accept SEIZE

do BUSY TRUE; snd;

accept RELEASE , -do BUSY := FALSE; endr end select; end loop; end SCHEDULER;

(г) Задача-планировщик,

PUSH

SPACE

Исходный пассивный стековый пакет


Задача-планировщик

,{д) Ис><одный пакет оставлен без изменения - потребители

синхронизируют работу сами, используя задачу-планировщиКГ

Рис. 3.14 (продолжение).

на рис. 3.14,5, предоставляет задачам-пользователям излишне сложный интерфейс и, кроме того, потенциально ненадежно, так как не содержит средств прямой защиты содержимого пакета от использования задачами, которым не разрешен доступ к этому пакету.

3.3.3. Структуры с односторонним взаимодействием

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



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

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

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

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

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

Предположим теперь, что единственная задача-отправитель хочет что-то переслать единственной задаче-адресату (рис.3 3.15, а). Совершенно ясно, что здесь имеются две возможности: переслать сообщение путем безусловного обращения к вызываемому адресату (рис. 3.15,6), либо вызывающий адресат, обратившись к отправителю, может запросить нужное сообщение: при этом вызов носит условный характер i(pnc. 3.15, б). Очевидно, что первый подход более предпочтителен



ДЛЯ адресата, а второй - для отправителя; чтобы сделать окончательный выбор между указанными вариантами, требуется дополнительная информация.

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

Отправитель

Адресат

\а) Поток информации.


[б] Вь!зывающий отправитель, вызываемый адресат.


(в) Вызываемый отправитель, вызывающий адресат .


(г) Промежуточное средство транспортировки вызова.


Id) Пром?жуТ9ЧНЬ1Й буфер



Проектно-ориентированная методика наглядного-описания систем 83

Ь-.- --.-----

-ЗАДАЧА-КУРЬЕР НЕ ИМЕЕТ ВХОД06 task TRANSPORTER is end TRANSPORTER;

- - ЗАДАЧА-КУРЬЕР РАБОТАЕТ В ЦИКЛЕ SET-PUT task body TRANSPORTER is

begin loop

SENDER.GET (ITEM);--УСЛОВНОЕ ОЖИДАНИЕ

TARGETPUT (ITEM); end loop; end TRANSPORTER

.--. У АДРЕСАТОВ И ОТПРАВИТЕЛЕЙ ОБЫЧНО БЫВАЕТ

-- НЕСКОЛЬКО входов

--В ПРОТИВНОМ СЛУЧАЕ ЗАДАЧА.-КУРЬЕР ВРЯД ЛИ НУЖНА

task SENDER is

--входы ОБЪЕДИНЕНЫ В ЕДИНСТВЕННОМ.РПЕРАТОРЕ

--ВЫБОРОЧНОГО ОЖИДАНИЯ

entry GET (ITEM ; out 1ТЕ1И ТУРЕ);--УСЛОВНОЕ 0ЖИДА(4ИБ.

end SENDER task TARGET is

--ВХОДЫ ОБЪЕДИНЕНЫ В ЕДИНСТВЕННОМ

--ОПЕРАТОРЕ ВЫБОРОЧНОГО ОЖИДАНИЯ

entry PUT {ПШ : in 1TEM TYPE);

end TARGET;

(e) Пример задачи-курьера.

Рис. 3.15. Стандартные конфигурации односторонних взаимодействий между парами задач.

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

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

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



ВКЛЮЧИТЬ в единственный оператор приема, принадлежащий вызываемой задаче.

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

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

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

На рис. 3.15, (? представлено альтернативное решение для высоких уровней интенсивности взаимодействий. Между отправителем и адресатом помещается буферизующая задача, которая может временно хранить избыточные объекты, порождаемые отправителем; в результате отпадает необходимость в собственной буферной памяти задачи-отправителя. Подобное решение приемлемо в том случае, когда задача-адресат взаимодействует с другими задачами только при посредничестве буферизующей задачи. Эту проблему мы еще обсудим ниже. Пример Ада-программы для буферизующей задачи был приведен в гл. 2.

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

А что происходит, если сообщения передают несколько задач, как показано на рис. 3.16, а? Как и прежде, здесь возможны два варианта непосредственных взаимодействий: адресат может быть инициатором вызова (рис. 3.16,6) или вызываемым (рис. 3.16, б). Однако по сравнению с рис. 3,15 здесь заметно явное отличие даже при отсутствии какой-либо допол-



1 ... 5 6 7 8 9 10 11 ... 32

Яндекс.Метрика