Данные

Процессы.

Организация вычислительных процессов

Обычно считается, что используемая технология программирования должна обеспечить реализацию любой структуры, выдуманной проектировщиком. RTST - Real-Time Software Technology При разработке RTST мы заранее зафиксировали определенные структурные решения и тем самым ограничили разнообразие вариантов организации вычислительного процесса.

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

- Сообщений от других ЭВМ или оборудования - в непредсказуемые моменты времени. => Все функциональные процессы в один большой процесс ОС, внутри которого будем использовать синхронную организацию взаимодействия функциональных процессов, а драйверы сети, которые осуществляют буферизацию сообщений (никакой обработки!), будем реализовывать простыми обработчиками прерываний на стеке текущего процесса. Интересно заметить, что на 1 внешнее событие обычно приходится 5-10 внутренних переключений функциональных процессов.

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

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

Объектно-ориентированный подход(Во-первых, не вызовет ли разбиение данных на сравнительно мелкие объекты (с точностью до прибора)): объекты состоят из команд и данных. Внутри себя объект строго последователен. Если нужны данные другого объекта, можно послать ему сообщение. Тот вернёт соответствующее значение. У каждого объекта есть очередь входных сообщений. Каждое сообщение обрабатывается отдельно. Не возникает проблем с одновременным чтением/записью.

Посылка сообщения не менее, а может быть и более дорогое действие, чем свёртка/развёртка процесса. Это приводит к толкотне процессов.

- Можно придумать распределение задач по объектам в конвейерном стиле.

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

(АЛ – Абонентская Линия; СЛ – Соединительная Линия; ТК – Телефонная Книга; КП – Коммутационное Поле.)

программ, вызываемых по прерываниям.

Когда абонент поднимает трубку, соответствующий объект АЛ получает сообщение, принимает все цифры номера и посылает сообщение объекту ТК с принятым номером в качестве параметра. Заметим, что все это время АЛ работает только со своими локальными данными. ТК осуществляет поиск вызываемого абонента также только по своим локальным данным и посылает сообщение найденному объекту типа АЛ или СЛ. Вызываемый абонент или соединительная линия по своим локальным данным определяет, занят он или свободен, и если свободен, то посылает сообщение КП на подключение. КП по своим локальным данным находит свободную промлинию и т.д.