Особенности программирования БВК АМС

[Вадим Семенов]

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

Золотые слова! Именно об этом я и говорю. Т.е. по факту даже при статической типизации нужны средства контроля (аудит, тестирование, и т.п.). Но тогда нет никакого выигрыша

Я говорю о другом - о том что при разработке правильного языка и компилятора ситуацию можно было бы еще улучшить.

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

Наверное считаете, что сборщик мусора работает только, когда куча исчерпана? Это было бы глупо. Сборщик мусора - параллельная задача, выполняемая периодически при определенных условиях. Если при этом она еще и гарантирует в разумных пределах выполнение других задач, работающих с кучей, то все относительно красиво.

Я так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.

Нк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.

Статическое распределение страдает неэффективностью и переполнение статически распределенных блоков возможно ровно настолько, насколько возможно переполнение стека. Что же теперь, можно сделать вывод, что оно нежелательно для данного рода задач?

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

Байт-код и виртуальная машина нужны для портабельности уже скомпиленной программы.

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

Не может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.

Что вольного в работе с указателями на С++?

То что любое число может интерпретироваться как указатель.

Ассемблер тогда вообще кошмар наяву

А я и не предлагаю все писать на ассемблере.

[Unispace]

Ругаются на стенде, при анализе результатов, а до этого инженеры-программисты живут в другом мире! :shock:

Да я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже  

[Aleks1961]

Взять одну троированную ЦВМ

Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:

При отказе 1 канала, один из оставшийся в резерв и летим на одном и тд.

[Вадим Семенов]

Взять одну троированную ЦВМ

Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:

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

[bs]

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

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

[Вадим Семенов]

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

Вот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.

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

[belov2018]

Про троированную ЦВМ было бы интересно почитать, например на ту, которая на КК Союз применяется. Что там представляет отдельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

Посмотрите  в Политехническом музее, или в Виртуальном компьютерном музее, или на сайте НИИ Аргон. "Аргон-16" полетел в последний раз с людьми на МКС. За 35 лет работы в космосе ни одного отказа.

[bs]

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

Скажем так - когда-то объектно-ориентированное программирование казалось системным программистам сферическими конями в вакууме. Где мы были тогда, и где мы сейчас? Простая методология, а какой качественный скачок.

Я лишь пытаюсь протолкнуть идею о том, что не все новшества ущербны. Надо анализировать и сравнивать преимущества/недостатки.

Человек поделислся своим опытом работы с Erlang и его тут же запинали, без какого-либо анализа. Не по инженерному это

[belov2018]

Для космической БЦВМ не так важно, как быстро она считает, а то как долго и без отказов она летает!

[bs]

Взаимодействие контроллеров всё-таки более предсказуемо по последствиям, чем взаимодействие находящихся в общей памяти программ.

Спорно.

А протоколы надо использовать стандартные и массово используемые (а следовательно вылизанные), чем изобретать велосипед непредсказуемой кривизны.

Протоколы стандартизированы только на самом низком уровне. Дальше кто в лес, кто по дрова. Возьмем те же датчики ориентации. Как здесь уже писали - одни выдают направляющие косинусы, другие кватернионы. Переход с одних на другие в коде микроконтроллера и на языке высокого уровня - небо и земля. Сложность сопряжения и тестирования отличается на порядок.

[Вадим Семенов]

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

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

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

[Вадим Семенов]

Про троированную ЦВМ было бы интересно почитать, например на ту, которая на КК Союз применяется. Что там представляет отдельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

Посмотрите  в Политехническом музее, или в Виртуальном компьютерном музее, или на сайте НИИ Аргон. "Аргон-16" полетел в последний раз с людьми на МКС. За 35 лет работы в космосе ни одного отказа.

А что там смотреть? Красивые фото? Описание логики работы в сети я не видел.

[bs]

Вот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.

Ну вот, а ведь интересно было бы узреть эту систему под управлением Эрланга, при которой вообще не было бы проблем с обработкой данных

[bs]

Я говорю о другом - о том что при разработке правильного языка и компилятора ситуацию можно было бы еще улучшить.

Это уже тема DSL. Тема отдельная и заслуживающая внимания сама по себе.

Я так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.

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

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

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

Не может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.

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

То что любое число может интерпретироваться как указатель.

Если 0 - это любое число, то да Куда же подевалась жесткая типизация? Не забываем, что С++ - это язык со строгой типизацией.

[bs]

Да я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже  

Им просто нужно почаще общаться с "неразработчиками"  :lol:

[Unispace]

Протоколы стандартизированы только на самом низком уровне. Дальше кто в лес, кто по дрова. Возьмем те же датчики ориентации. Как здесь уже писали - одни выдают направляющие косинусы, другие кватернионы. Переход с одних на другие в коде микроконтроллера и на языке высокого уровня - небо и земля. Сложность сопряжения и тестирования отличается на порядок.

Если есть только 2 формата, то какие проблемы ? Обязать выдавать по опции на этапе производства либо один, либо другой, либо оба. Написать утилиты конвертации. Если производство  - у нас, конечно. Вот это и будет полезным делом, межотраслевая стандартизация. Что, так трудно создать в космической отрасли аналог IEEE или ITU ? Или там тоже у нас победил принцип либерализма, пиши-верти что хочешь, пусть другие разбираются и едят. Так виртуальная память тут не поможет, только реальная, в мозгах, и еще разум  

[bs]

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

Троирование на уровне логических элементов И-НЕ на кристалле процессора. Дальше троирование + резервирование ЦВМ "гранями" - одна активна, две в горячем резерве, одна в холодном. В простейшем случае - грань сбойнула, забыли про нее. Вводим одну из холодного резерва и работаем на 3-х оставшихся. И так дальше до одной. Можно помутить с восстановлением и диагностикой. Если диагностика прошла, вернуть в холодный резерв.

[Unispace]

Ну вот, а ведь интересно было бы узреть эту систему под управлением Эрланга, при которой вообще не было бы проблем с обработкой данных

Сию минуту! Внесу предложение, пусть перепишут миллионы строк кода под Эрланг, вот уж тогда местным НОТ-тестерам будет поле развернутсья    В системе этой и так никаких серьезных проблем нет, работает себе и работает Просто ее создавали те, кто не привык растекаться атомарным слоем по тарелке

[Unispace]

Да я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже  

Им просто нужно почаще общаться с "неразработчиками"  :lol:

С целью ? Если это НЕ-разработчики, то смысла нет  

[bs]

Или там тоже у нас победил принцип либерализма,

Ну за что боролись...

Межотраслевая стандартизация уж больно далеко за рамками досягаемости программистов. И слишком уж это запредельный аргумент в пользу микроконтроллеров.

Гибкость и эффективность на местах все-таки сподручней будут, чем надежды на никак от тебя не зависящие стандарты.