|
| |
 |
Главная » Мануалы 1 ... 24 25 26 27 28 29 30 ... 32 iitsbiBsejcH только в том случге, когда у задачи PRX нет саободных буферов ;т. е. при инициализации)  Рис. 6.16. Структура управляющего пакета физического ooivieHa кадрами данных. Управляющий пакет физического обмена информационными кадрами. В пакете Р, осуществляющем управление физическим обменом, имеются только две задачи: РТХ и PRX (рис. 6.16). Эти задачи представляют собой стандартные программы обслуживания прерываний, взаимодействующие с оборудованием посимвольной передачи данных, о котором упоминалось в начале данной главы. Аппаратные средства связи, от которых исходят сигналы прерываний, осуществляют передачу отдельных символов. На стороне системы через вход SEND задачи РТХ пересылаются сверху - вниз кадры данных, а снизу - вверх - буфер ТХ, служащий разрешением на передачу информации: на входе PICKUP (ВОССТАНОВЛЕНИЕ) задачи РТХ реализуется ожидание нового кредита на передачу, если он исчерпан процедурой SEND; через вход RCVE задачи PRX пересылаются снизу - вверх информационные кадры, а сверху - вниз - свободные буферы. . Использование процедуры Р.RCVE для нисходящей передачи свободных буферов избавляет задачу PRX от необходимости непосредственного обращения к буферному пулу, что уменьшает вероятность пропуска ею некоторых символов. Благодаря такому решению задача PRX активизируется лишь при наличии соответствующего числа свободных буферов из пула (хотя бы двух). При нормальном функционировании процедура F.RCVE вызывает вход NO WAIT PICKUP задачи В в том случае, когда значение переменной TALLY (ЯРЛЫК) больше нуля. Эта переменная используется для хранения текущей разности между числом кадров, отправленных снизу - вверх, и числом свободных буферов, переданных сверху - вниз. Как будет показано ниже, вызов входа PICKUP задачи В осуществляется только тогда, когда от задачи PRX поступает сообщение, что она исчерпала свой запас свободных буферов. Задача, управляющая пулом свободных буферов, должна иметь дополнительный вход NO-WAIT-PICKUP (ВОССТА-НОВЛЕНИЕ-БЕЗ-ОЖИДАНИЯ), чтобы модуль, вызывающий процедуру Р.RCVE, не сталкивался с конфликтной ситуацией, при которой он должен стоять сразу в двух очередях: на входе задачи В в ожидании свободных буферов, и на входе задачи PRX в ожидании заполненных буферов. Добавление нового входа исключает всякую возможность возникновения подобного тупика. После того как задачей PRX осуществлен прием полного кадра, предохранитель на ее входе RCVE устанавливается в состояние TRUE (если он был в состоянии FALSE) и задача вновь оказывается готовой к заполнению очередного свободного буфера. В результате приема вызова входа RCVE полученный кадр данных передается вызывающему модулю, а предохранитель входа RCVE опять устанавливается в состояние FALSE при условии, что задача PRX располагает хотя бы одним свободным буфером, а кадров, подлежащих обработке, больше нет. Если же это условие нарушается, т. е. у задачи нет ни кадров, ни свободных буферов, то она уведомляет об этом модуль, обратившийся к выходу RCVE, возвращая ему соответствующее значение параметра состояния системы. До тех пор пока у задачи PRX имеется по крайней мере один свободный буфер, а принятые информационные кадры отсутствуют, вход RCVE остается закрытым. Для формирования внутренней очереди из копий передаваемых кадров (представленных, возможно, ссылочными переменными) в задаче РТХ имеется специальная область памяти, рассчитанная на хранение определенного числа элементов (как минимум двух). После передачи копии некоторого кадра задача немедленно освобождает занимаемое им место в памяти (уничтожая таким образом копию) и начинает обработку копии еле- дующего кадра из очереди. До тех пор пока свободные места в очереди отсутствуют, вход PICKUP остается закрытым с помощью защитной блокировки. Средства, инициирующие сигналы прерываний, осуществляют посимвольную передачу информационных кадров между программой и аппаратурой, добавляя символы в буфер или извлекая их из него. Такой способ передачи является следствием сделанного в начале данной главы предположения, что аппаратные средства системы ориентированы на посимвольную обработку; в результате производительность системы может оказаться крайне низкой. Кроме того, ввиду замедления работы системы, вызванного непроизводительными затратами времени на организацию рандеву, при выполнении быстрых операций обмена в синхронном режиме может происходить потеря символов. Подход, позволяющий избавиться от указанных выше проблем, состоит в том, чтобы писать стандартные программы обработки прерываний на языке ассемблера и, используя механизм фиксированных временных задержек, возлагать на задачу PRX, например, периодическую проверку наличия символов и извлечение их из входного буфера программы обслуживания прерываний. Альтернативный способ действий - изменение технических требований в сторону улучшения рабочих характери-i стик аппаратных средств. 6.6. Заключительные замечания к проекту При обсуждении нашего проекта мы опустили многие подробности, связанные с системными аспектами. Не рассматривались, например, реальные механизмы выделения памяти под пул буферов и формирования их указателей. Практически не исследовались вопросы организации внутренних очередей в различных модулях, в которых могут накапливаться данные, спецификации пакетов и задач не содержали излишних подробностей и были опущены детали объявления типов параметров. Логика работы системы разрабатывалась большей частью с использованием рисунков и путем словесных пояснений. Для иллюстрации некоторых новых ключевых положений мы привлекали лишь небольшие фрагменты программ. В частности, были приведены текст программы для задачи дешифратора событий, а также упрощенный вариант спецификации пакета F PROTOCOL. В то же время мы не дали описания управляющих пакетов обмена сообщениями и физического обмена кадрами данных, поскольку читатель не получил бы здесь никакой новой информации. Пакет F PROTOCOL можно было бы, конечно, сделать более универсальным, усложнив в деталях его внутреннюю структуру (соответственно уровню сложности нового варианта), однако характер его интерфейсов с локальной системой при передаче и приеме данных, а также при управлении потоком кадров остался бы точно таким, как и в вышеописанном проекте подсистемы СОММ, независимо от уровня внутренней сложности. Так, например, появление новых типов информационных кадров в протоколе обмена потребует, конечно, введения дополнительных компонентов в вариантные записи, характеризующие возможные события и действия. Подсистему СОММ в том виде, в котором она спроектирована, можно рассматривать как некоторый логический уровень эскизного описания архитектуры системы. Данный материал целесообразно использовать в качестве некоторого стержня реального проекта. Основываясь на изложенных идеях, следует разработать детализированные спецификации интерфейсов всех пакетов и задач, начав с определения опущенных нами деталей. В оставшихся разделах главы мы проанализируем проект подсистемы СОММ с двух точек зрения: в разд. 6.6.1 будут рассмотрены некоторые обобщения, ведущие к расширению функциональных возможностей, а в разд. 6.6.2 мы оценим возможности других проектных решений, ведущих к построению систем иной струкуры. 6.6.1. Обобщение результатов проектирования Проектные решения по системе в целом весьма слабо зависят от деталей протокола обмена кадрами данных. Поэтому можно сравнительно легко включить в наш проект некоторые функциональные возможности этого протокола, такие, как явное управление сквозной передачей потока сообщений, управление выключением и рестартом средств связи и передача уведомлений об отказах линии передачи данных. Эти изменения могут повлиять главным образом на пакет протокола обмена. Включение в этот пакет механизма сквозного управления потоком информационных кадров не должно влиять на механизмы локального регулирования потока информации, уже реализованные в управляющем пакете логического обмена. Способ регистрации отказов линии связи, иллюстрируемый рис. 6.17, состоит в том, что вводится специальная задача CHECKER (КОНТРОЛЕР), которая ожидает поступления на вход задачи, реализующей обмен кадрами данных, особого сигнала, формируемого при отказе линии передачи. После этого задача-контролер должна отправить уведомления от отказе всем другим пакетам и задачам, к которым это событие имеет непосредственное отношение. Конечно, для обеспечения такой структуры взаимодействий упомянутые программные модули Дополнитбльнь1Й вход Рассылка уведомлений о событиях всем задачам-пользователям Дополнительная процедура, реализующая ожидание  Пакет F Вход закрыт. Состояние если \Ъ нет необходимости в рассылке уведомлений Используется здесь для регистрации любых i существенных событий I в канале связи Рис. 6.17. Схема оповещения модулей верхних уровней системы о событиях, происходящих на уровне управления обменом кадрами данных. (Примечание. На рисунке изобра.жены не все процедуры и входы задач.) ДОЛЖНЫ быть снабжены необходимыми процедурами и входами, а их внутренняя логика соответствующим образом модифицирована. Для осуществления приема и передачи сообщений с использованием нескольких буферов (более двух) потребуется создание активного пакета управления обменом. Необходимо будет также реализовать протокол управления потоком сообщений, который обеспечивал бы автоматическое восстановление информации при выключении аппаратуры связи или удаленного терминала и рестарт системы без потери или дублирования сообщений. Возможная структура такой системы с внешними интерфейсами, как у системы, описанной ранее, изображена на рис. 6.18. Ее логика аналогична логике работы пакета F с той только разницей, что разрешения на обмен информацией выдаются в форме предоставления текущих буферов, которые после их использования должны возвращаться владельцу . Условные обозначения; заполненные буферы свободные буферы Управляющий пакет обмена сообщениями М   Задача MS, реализующая сервисные функции при обмене сообщениями GET PUT WAIT Примеча-ние 3 \\  Примечание 4 Управляющий пакет логического обмена кар^ми даииык F
Задача В, управляющая доступом в буферный пул Рис. 6.18. Возможная структура активного управляющего пакета обмена сообщениями. (Примечание. 1. Вход RCVE закрыт до тех пор, пока нет сообщений для приема. 2. Вход PICKUP закрыт до тех пор, пока не закончится передача сообщения. 3. Вход GET закрыт до тех пор, пока отсутствует информация, подлежащая передаче. 4. Вход WAIT закрыт, если нет свободного буфера сообщений RX.) 6.6.2. Альтернативные проектные решения по основным компонентам системы Подсистема СОММ была спроектирована нами с ориентацией на совместно используемые буферные пулы. Существуют по крайней мере две причины, по которым такая реализация может оказаться нежелательной: Сложность, возникающая из-за свободного состязания модулей за обладание общими буферами и возможного размножения указателей буферов, может запутать логическую структуру взаимодействий и как следствие увели-. чить вероятность возникновения ошибок при проектировании или реализации системы. Прозрачность модулей, требуемая для организации совместного использования памяти, делает невозможным распределение модулей по различным процессорам, у которых может не быть общего пространства памяти. Отметим, что при реализации верхних уровней системы принцип конкурентного доступа к общим буферам нами не применялся. Так, например, управление пулом буферов сообщений осуществлялось исключительно лишь дешифратором событий. Но что можно сказать но поводу применения аналогичного подхода к буферизации кадров? Управление буферными блоками должно быть доступно только пакету, реализующему логический обмен. В этом случае должно осуществляться не раздельное получение свободных буферов взаимодействующими модулями, а их обмен на заполненные буферы при каждом акте соответствующего взаимодействия. При этом в случае передачи пустые буферы, движущиеся сверху вниз, должны обмениваться на заполненные, а в случае приема, наоборот, заполненные буферы должны обмениваться на пустые. Несмотря на то что этот подход исключает непосредственное состязание за обладание буферами, он все еще требует наличия общего буферного пула, причем замена пустых буферов на заполненные и, наоборот, заполненных на пустые, реально означает, что буферы из совместно используемого пула передаются при обращении по ссылке. Таким образом, проблема множественности ссылок не исчезает и здесь, а прозрачность оказывается нереализованной. Если к проекту предъявляется требование обеспечения прозрачности системы по отношению к возможному отсутствию общей памяти модулей, то обмен данными при межмодульных взаимодействиях должен осуществляться в результате вызова по значению, как показано на рис. 6.19. Каждый из модулей должен при этом иметь специальную область для размещения буферов, копируемых из одного модуля в другой. При таком подходе, когда осуществляется реальное копирование информации, не имеет смысла говорить о получении разрешения на обмен в форме предоставления свободных буферов; в данном случае оно должно выдаваться путем указания числа блоков данных в передаваемом сообщении. В процессе проектирования подсистема СОММ приобрела вид трехуровневой системы, реализуемой шестью задачами (рис. 6.8). Использование в ней активного пакета М должно привести к увеличению этого числа до девяти. Сравнительно большое количество задач явилось результатом конкретного проектного решения, заключающегося в том, что каждый  Буфер для кадра ТХ (разрешение на передачу)  (а) Передача  Буфер для сообщения RXp (разрешение на прием)  Буфер , - для кадра RXy 13апопненные (разрешение [ кадровые на прием) 1 буферы  (5) Прием Рис. 6.19. Поток кадров данных в подсистеме обмена при отсутствии совместно используемой памяти. активный пакет, реализующий некоторый уровень системы, обязывает вызывающие модули ожидать при передаче данных получения разрешения на обмен и поступления информации. Таким образом, на каждом уровне системы существуют точки, в которых реализуется ожидание: вызовов от модуля верхнего уровня; разрешения от модуля нижнего уровня на передачу информации; поступления информационных объектов от модуля нижнего уровня. Вообще для обеспечения такой организации ожидания необходимо иметь в системе три задачи. Исключениями являются модуль М, который не активен, и модуль Р, для реализации ко- торого требуются лишь две задачи обслуживания прерываний - одна для передачи и одна - для приема. Число задач может быть уменьшено при условии, что в каждом пакете предусмотрены только вызовы без ожидания, результатом которых являются параметры состояния системы. При таком подходе необходимость в задачах-курьерах исчезает, однако в результате еще более усложняется внутренняя логика оставшихся задач. Нетрудно установить логическую сущность возможного компрохмисса междупроектными решениями с большим и малым числом задач. В первом случае логика функционирования всей системы и отдельных ее задач может оказаться проще по меньшей мере по двум причинам: отсутствует необходимость циклического слежения за наступлением определенных событий; при совершении события задача, которая обеспечивает его обработку, получает немедленное оповещение об условиях, в которых оно произошло. Если же число задач невелико, то накладные расходы , связанные с их контекстным переключением и диспетчеризацией, будут меньше. Маловероятно, чтобы этот вопрос имел существенное значение для верхних уровней системы, где переключение задач наверняка происходит сравнительно редко. Однако для нижних уровней он чрезвычайно важен. Приемлемые количественные соотношения в значительной мере зависят от реализации, и их обсуждение выходит за рамки тех вопросов, которым посвящена эта книга. Система DIALOGUE/COMM в целом определена нами как единый узел надежности. Поэтому проектные решения по подсистеме СОММ обеспечивают защиту системы от последствий возникновения самых различных внешних неисправностей; однако средств защиты от внутренних отказов собственной логики эта подсистема не имеет. Такие отказы могут быть предотвращены путем разбиения системы на более мелкие узлы надежности, каждый из которых защищен от неисправностей, возникающих в других аналогичных узлах. В общем случае каждый модуль многоуровневой системы информационного обмена может представлять собой самостоятельный узел надежности, связанный с модулями верхнего и нижнего уровней, возможно, ненадежными каналами. В этом общем случае могут потребоваться не только протоколы горизонтального взаимодействия равноправных модулей отдельных узлов коммуникационной сети, но, вероятно, и протоколы вертикального взаимодействия различных узлов надежности, образующих разные уровни системы. Такая вероятность должна всегда приниматься во внимание, хотя в дальнейшем мы на ней останавливаться не будем. Рис. 6.19 мог бы послужить хорошей основой для разработки системы с учетом изложенных обстоятельств. Однако независимо от способа разбиения системы на отдельные узлы надежности существует вероятность возникновения такой ошибки во внутренней логике узла, которая приводит к разрушительным последствиям для системы, но сам узел надежности при этом полностью не выходит из строя. Такая ошибка может быть результатом, например, появления неверного бита информации в кристалле памяти. Если подобная неисправность вызывает достаточно сильное отклонение от нормы, то она может привести к тому, что поведение какого-либо блока будет казаться нормальным, но в конце концов нарушит правильную работу системы. Например, что произойдет, если в каком-либо модуле синтаксические правила, диктуемые всеми протоколами, выполняются, а семантические - нет? В этом случае модуль может подтвердить прием протокольных блоков данных, отправленных другими модулями, но не полученных, что, естественно, приведет к потере информации. Решение подобных проблем сопряжено с серьезными трудностями, и один из возможных подходов к решению заключается в выталкивании симптома неисправности на поверхность с расчетом на то, что какой-либо модуль верхнего уровня в конце концов заметит возникшие неполадки и предпримет действия по восстановлению информации. Однако, применяя этот подход последовательно по всем уровням системы, мы дойдем до самого верхнего, откуда перенести решение проблемы еще выше будет уже нельзя. Тогда последним звеном в этой цепи должен стать человек-оператор системы. Другой, более дорогостоящий подход заключается в физическом резервировании ненадежных компонентов. Например, можно выдвинуть требования, чтобы в системе было два идентичных комплекта оборудования связи и активная линия связи отключалась при чрезмерно большом потоке повторных передач сообщений. 6.7. Заключение Важное значение в этой главе имеет не сама подсистема обмена СОММ (хотя она вполне жизнеспособна), а процесс ее проектирования, позволивший нам прийти к данной структуре, и графическая нотация, использованная для ее описания. Проектные решения представлялись в наглядной форме, удобной для группового обсуждения. Хотя сам процесс проектирования при этом носит относительно неформальный характер, рисунки трактуются формально в терминах языка Ада, и соответствующие Ада-программы могут быть написаны с их помощью почти механически. 1 ... 24 25 26 27 28 29 30 ... 32 |
|||||||||||||||||||||||||