Разным нюансам реализации, и не только программным, обсуждавшихся идей ВОС посвящены целые монографии. По необходимости коротко остановимся потом только на немногих моментах — с учетом специализации как раз программных, — разрешающих лучше уяснить архитектурно-декомпозиционный подход, принятый в модели ВОС, при взоре со стороны ПО настоящей открытой совокупности. светло кроме этого, что очень многое зависит от конкретных аппаратурных и программных средств таковой совокупности, исходя из этого предстоящее направляться разглядывать скорее как ориентировочную иллюстрацию неспециализированного подхода.
Хорошо как мы знаем, что реализация функций связи очень ресурсоемка. Определенное представление об этом возможно было составить из уже усвоенного материала. Исходя из этого для исполнения связных процедур и для обработки простых (прикладных) задач значительно чаще применяют отдельные системы. В большинстве случаев, полная система связи — это некий отдельный конструктив. В нем объединены: локальный процессор связи; память, имеющая количество, достаточный для хранения программных реализаций протоколов, участвующих в обработке данных; схемы, нужные для реализации физического интерфейса с сетью. Эти включают в себя данные о (локальном) состоянии протокола каждого из сообщения и уровней, передаваемые между уровнями.
Прикладные процессы пользователей выполняются на основной (host) совокупности. Сотрудничество основной ее подсистемы и системы связи опирается на ПО межпроцессорных связей, имеющееся в обеих совокупностях. Синхронизация обмена данными между ними обеспечивается совокупностью прерываний.
Рис. 3.1. Структура очередей взаимодействующих задач
Программные реализации протоколов смежных уровней должны быть независимы в том же смысле, что и сами эти уровни, потому что в другом случае будут потеряны все преимущества многоуровневой архитектуры. Исходя из этого полная система связи реализуется в виде пакета модулей задач (процессов), по одному на любой уровень, с добавленными задачами для исполнения (локальных) обработки прерываний и функций управления таймера. Задачи взаимодействуют между собой посредством комплекта очередей либо почтовых коробок, как это продемонстрировано на рис.3.1, применяемая дисциплина — FIFO (первым пришел — первым обслужен). Межзадачное сотрудничество осуществляется через локальное ядро, функционирующее в реальном времени. Это же ядро создаёт планирование задач и обработку прерываний, поступающих от таймеров.
Смежные уровни взаимодействуют между собой посредством примитивов. Это сотрудничество имеет атомарный (неделимый) темперамент, что проявляется неоднозначным образом. С одной стороны — сами примитивы — это первичные, неделимые элементы описания сервиса. С другой — движение обработки протокольным автоматом одного из них не может быть прерван обработкой другого, не обращая внимания на асинхронность моментов их появления. Для обеспечения атомарности обработки каждого входного события (принятия примитива к обработке) другие локальные события передаются протокольному объекту тем же методом, что и те, каковые поступают сверху и снизу от смежных уровней. С таким подходом мы встретимся позднее при рассмотрении организации управления ВОС и одолжений СЭПС информационных работ управления с доступом их примитивов конкретно на необходимый уровень. Тут же чуть ниже заметим, что подобно обрабатываются примитивы таймера.
Любой примитив работы совместно со связанными с ним параметрами формируется в буфере памяти, именуемом блоком управления событиями (БУС). Форма представления этих параметров локальна и соответствует языку реализации протокольных объектов (задачи в целом).
В большинстве случаев, тип и число параметров зависят от примитива, но с каждым протокольным объектом связывают единую структуру (БУС) символьных данных. Наряду с этим в заголовке каждого БУС имеется поле типа примитива, за ним направляться поле всех вероятных параметров, связываемых с полным комплектом примитивов одного уровня. При передаче примитивов между уровнями отправляющая задача показывает тип передаваемого примитива в заголовке БУС, а приобретающая задача применяет это поле, дабы выяснить ту конкретную процедуру выходного события, которая должна быть инициирована в этом случае. Эта процедура выделяет только те параметры, каковые касаются ее, т.е. только те, которым присвоены содержательные значения.
Структура обычного БУС приведена на рис.3.2. Данный БУС относится к транспортному уровню, т.е. употребляется при сотрудничестве между сеансовым и транспортным уровнями для всех транспортных примитивов запроса, индикации, подтверждения и ответа. Полный БУС имеет структуру записи (record), а переменной ТипСобытия присваивается тип примитива работы. Об применении поля УказательНаБфДП и связанного с ним ДлинаБфДП см. потом. Поля вызываемых и вызывающих СнТДС, ТТДС и СтТДС используются в примитивах Т-СОЕДИНЕНИЕ, а поля ИдПриемника и ИдИсточника — в последующих примитивах Т-ДАННЫЕ для установления соответствия между транспортным соединением и данными пользователя, которые связаны с примитивами.
AIML-5-1-3 Программная реализация генетического метода
