Владимир Паронджанов писал(а):
У меня в книгах было предусмотрена такая возможность на всякий случай
Сдается мне, это "на всякий случай" вовсе не случайно. А имеет глубокие корни.
Вообще, часто для понимания некоторых проблем в самых разных областях весьма полезно бывает обратиться к истокам, корням, "откуда ноги растут".
Итак, место появления "Дракона" - а точнее, технологии ГРАФИТ-ФЛОКС - НПЦ АП имени Пилюгина. Фирма, занимающаяся созданием систем управления ракет-носителей и разгонных блоков.
И ракеты, и разгонные блоки - сложные технические системы. И те, и другие должны выдерживать заданные нетривиальные циклограммы (требующие выполнять временные соотношения между операциями) полета.
Неудивительно, что в "графический алфавит" ГРАФИТа входят примитивы для обозначения действий, связанных с отсчетом времени - в данном конкретном случае "Пауза", "Установка таймера", "Синхронизатор".
Однако, в то же время, характерный срок действия системы управления ракетой или разгонным блоком - всего минуты. Ну, десятки минут. И все - ступени догорают, миссия блока выполнена.
При этом решаемые задачи достаточно однообразны и предсказуемы .
Неудивительно, что это подталкивает к простым техническим решениям без излишнего усложнения (а значит, с большей надежностью, что для космической техники имеет первостепенную важность), в частности, к организации вычислительного процесса в системе управления без четкого выделения "классической" операционной системы и вытесняющей многозадачности.
Взамен полноценной операционной системы реального времени (вроде VxWorks, Lynx, QNX и пр.) могут иметься некоторые самописные "рудименты" диспетчера задач - скорее всего, на машинах "Бисер" НПЦ АП подобным образом и организован вычислительный процесс, не исключено вообще что "пакет" задач носит фиксированный характер с выделением входящим в него четко определенным при проектировании процессам "квантов времени" в каждом "системном цикле" - так называемая "синхронная" диспетчеризация без прерываний.
Не исключено вообще, что все эти "таймеры" и "задержки" реализуются парой системных примитивов нижнего уровня, непосредственно вызываемых из функциональных программных модулей.
В подобных условиях достаточно четкое понятие "входа" задачи, инициируемое по наступлению некоего события или по окончании заданной временной уставки, размывается.
Если же брать, скажем, космические аппараты ДЗЗ, производимые РКЦ "Прогресс", они имеют срок активного существования несколько лет (а не минут!), более разнообразный и широкий набор бортового оборудования, большее разнообразие функционального программного обеспечения, связанного с управлением теми или иными бортовыми системами (их может быть порядка десятка, а модулей функционального ПО, функционирование которых, подчеркну, должно организовываться
параллельно), а также требуют большего разнообразия и динамичности в функционировании, что обуславливает большую адекватность асинхронной вытесняющей диспетчеризации. И даже если то системное ПО, что этим занимается, не носит названия "операционной системы", по сути ей является.
Неудивительно, что здесь возникает необходимость более четкого разграничения и понимания, когда функциональный управляющий алгоритм прерывается (его поток исполнения приостанавливается), и происходит передача управления в диспетчер, а когда - возобновляется ("вход").
Соответственно, в графическом языке примитив для "входа" очень даже себе встречается и семантически обоснован.
Не помню, выкладывал ли я уже эту картинку на форуме, но, думаю, она будет весьма познавательна.
Примечания: 1) Д2Вх1 - диспетчер БОС, на примитивах "выхода" указывается, что ему передается управление 2) Вход 1 включается из других функциональных программ, работающих параллельно в многозадачной ОС. Их имена, например, А25 и Р11, указаны рядом с граф.примитивом входа. У других входов подобные имена не указаны, поскольку это - части одного "функционального" алгоритма. Здесь мы наглядно видим отражение сложности межзадачного взаимодействия.