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

[LRV_75]

Многозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании.

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

Одна из краеугольных проблем реального времени  

[avp]

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

Стэк кстати как элемент недетерминизма тоже можно исключить - явно запретив рекурсивный вызов процедур и выделить статически места под локальные переменные.

[avp]

Ну я уже выше писал про "И". Для повышения надежности ПО БВС КА необходимо применять по возможности ВСЕ известные методы. Цена вопроса слишком велика  

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

[TAU]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:

Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.

[Aleks1961]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:

Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.

Согласен. Но это было 20 лет тому назад...  

[bs]

Зато количество выделяемых на стеке данных не фиксировано. Улавливаете?

Нет, нет. Мой намек был более тонким. Речь о том, что таким же образом глюк в коде может привести к переполнению массива, который распределен был статически, со всеми вытекающими последствиями.

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

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

0 любое, и любое другое число тоже любое. Вот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно.

Абсурд! Произвольное число (кроме 0, и то уже в С++0x есть nullptr) без явного приведения к указателю в С++ невозможно. Похоже, что про С++ вы знаете лишь по наслышке.

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

История появления бортовых ЭВМ ряда "АРГОН"

Еще советую книгу "БСУ КА" МОКБ "Марс".

[belov2018]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:

Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.

Согласен. Но это было 20 лет тому назад...  

Производительность вычислителей на необитамых КА всегда сдерживает объем решаемых задач. И причины понятны: стойкость к ВВФ и радиации, габариты, потребляемая мощность и отвод тепла.

[bs]

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

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

[zyxman]

Многозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании.

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

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

[bs]

Там этот набор трансформировался в сингулярность монеты. Цивилизованный человек существовать в этой сингулярности не сможет.

Не сможет. Но это уже совсем другая тема.

[Aleks1961]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:

Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.

Согласен. Но это было 20 лет тому назад...  

Производительность вычислителей на необитамых КА всегда сдерживает объем решаемых задач. И причины понятны: стойкость к ВВФ и радиации, габариты, потребляемая мощность и отвод тепла.

О СПО речь, о СПО :!:  :lol:

[belov2018]

И я про СПО. Десятки МГц частота процессора и несколько МБ памяти - вот и весь ресурс для СПО. Такие машины были на американских наземных комплексах 20 лет назад. Можно посмотреть в архивах какое там было СПО.
Новое (для нас) - хорошо забытое старое (для американцев).

[bs]

Вы не правы. Как раз наоборот. В основе управления КА лежит циклограмма. Т.е. по классификации систем реального времени на "управляемые событиями" (асинхронные) и "управляемые временем" (синхронные) система управления КА как раз синхронная

Для РБ соглашусь, а для КА типа АМС скорее как раз имеем систему, управляемую событиями. Отдельные циклограммы режимов увязываются в работу последовательностью событий (ориентация на солнце выполнена, стабилизация остаточного вращения выполнена, ориентация по звездам выполнена и т.п.). Логично? Временные задержки здесь определяются начальными условиями, которые не известны. Как их положить на циклограмму? Нельзя.

Выгода от чего? От "программирования без программистов"?

Имел в виду выгоду от перехода на ПРОЛ2, на методологию, которая все равно не позволяет исключить традиционные методы контроля качества. Вот если бы она позволила заметно сократить сроки разработки, но не из чего делать такие выводы, как я уже говорил.

Думаю, нужно все-таки относиться к создателям его (неглупым весьма и весьма людям) с большим доверием. Вообще говоря, декларировалось, что им удалось повысить производительность труда при создании комплекса программ для Бурана в 10 раз!

Отношусь к ним с большим уважением! Даже наметил себе более детальное изучение основы их методологии, как только разгружусь от текучки.

Кстати, по поводу того что ООП - "гигантский скачок", не все согласны. В том числе - не последние люди в программировании.

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

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

[belov2018]

Есть и наш примеры уникальности: Аргон-15А:
10. Описание: машина одноадресная, параллельного действия. Архитектура и структура специализированные, оптимизированные для решения задач управления. Система команд включает команды вычислений синуса, косинуса и квадратного корня. Обмен информацией с внешними абонентами осуществляется каналами ввода-вывода.

Представление чисел - с фиксированной точкой.

Разрядность чисел - 16 разрядов (слово), 32 разряда (двойное слово), разрядность команд - 19 разрядов. Число команд - 71.

Время выполнения операций (мкс): сложения - 5, вычисления синуса, косинуса, квадратного корня - от 16 до 30.

Объем ОЗУ - 4 Кб, ДЗУ - 64 Кб, ДЗУ со сменой информации - 256 байт.

Система прерываний - 4 уровня. Число каналов ввода- вывода - 2.

Скорость обмена (кб/с): ввод - 200, вывод - 400

И посмотрите какой объем СПО решается А-15А на МИГ-31.
Но это смгла сделать только большая кооперация уникальных программистов за 5 лет. И летает МИГ-31 на боевое дежурство уже 25 лет

[bs]

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

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

[TAU]

Для РБ соглашусь, а для КА типа АМС

А Вы что, имеете отношение к упралению и РБ, и КА?  

скорее как раз имеем систему, управляемую событиями

Ну-ну  

Имел в виду выгоду от перехода на ПРОЛ2, на методологию, которая все равно не позволяет исключить традиционные методы контроля качества. Вот если бы она позволила заметно сократить сроки разработки, но не из чего делать такие выводы, как я уже говорил

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

Если не последнию люди в программировании не согласны с тем, что ООП позволяет резко повысить качество ПО по таким параметрам как модульность, сцепление, связность, повторное использование, сопровождаемость, то им не мешает подумать над этим как следует еще пару раз

А еще лучше - Вам прочитать то, что они написали - подумав и не раз - на эту тему. И попробовать осмыслить.

[Artemkad]

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

Менеджер виртуальной памяти зациклился и? Синий экран Винды?

ЗЫ. А вообще - таймер горячей  собаки великолепно решает эту проблему...

[Artemkad]

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

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

Порочный подход. Стандарты не должны мешать разработчику, а обязаны помогать. Для этого в узких областях пишут стандарты сами разработчики. Задача стандарта - не гадать что там с той стороны по интерфейсу приходит...

[bs]

А Вы что, имеете отношение к упралению и РБ, и КА?  

Не имею, поэтому теоретизирую на основе доступной информации. Циклограмма по определению - точное расписание комманд. От этого и плясал.

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

Хорошо, что заявлялось. Но не надо забывать как давно это было и относительно какого уровня (доисторического) производительности была успешна решена задача!

А еще лучше - Вам прочитать то, что они написали - подумав и не раз - на эту тему. И попробовать осмыслить.

Подкиньте указатель на эти монументальные труды - с удовольствием ознакомлюсь.

[bs]

Менеджер виртуальной памяти зациклился и? Синий экран Винды?

Что такое система с миллиардами возможных вариантов состояний и "менеджер виртуальной памяти"? Ни в какое сравнение. Вылизать последний реально и не сложно.

ЗЫ. А вообще - таймер горячей  собаки великолепно решает эту проблему...

На каждый таймер собаки найдется цикл, который будет его сбрасывать :wink: