Куча - это эмоции. А в цифрах сколько?

Если их для вас пока нет, то не используйте ось. Я вижу преимущества как в КА, в ОС, так и хоть в мэйнлупе Всё имеет право на жизнь в каждом конкретном случае


Это очень примитивное объяснение сущности ОС. Я бы сказал, что ОС это событийно-ориентированная машина, которая отдаёт время наиболее приоритетной задачи, если ей есть что делать. Одновременно предоставляя все необходимые для этого сервисы. В КА вы тоже самое не сделаете, а если сделаете, то получите ОС. Более того, благодаря сохранению контекста (регистров) в стеке, в любое время можно прервать любую задачу и передать управление любой (ну не совсем любой) другой.

Почему вы думаете, что я вам прописываю RTOS? Если вы не хотите рассказать о своих проблемах, как же я вам помогу?

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

Чукча писатель? Но все же читаем:

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

Это очень примитивное объяснение сущности ОС.
Вы пишите "ОС это событийно-ориентированная машина, которая отдаёт время наиболее приоритетной задачи, если ей есть что делать". Но вы забываете. что в функции ОС входит ТАКЖЕ расчет и динамическое изменение приоритетов задач, обеспечение интерфейса для взаимодействия и синхронизации между задачами, а также предотвращение деад локов.


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

Короче РТОС нужна где есть МНОГОЗАДАЧНОСТЬ (и причем задачи реального времени) и разделение ресурсов.

А у кого и РТОС есть подобная фича?

У меня
Благодаря специально мной спроектированной интеллектуальной дисциплине диспетчеризации у меня невозможно чтобы поток "завис" или "заблокировался".
Ну естественно приоритеты у меня динамические. Точнее сумма стат + дин приоритетов. Типа как в венде
Ими ядро управляет

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

Сообщение отредактировал Укушенный воблой - Jan 9 2017, 19:47

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

Это в той, про которую бородатый анекдот?

Остапа несло ©
P.S.
Общаться с Доктором Туамозесом, Доном Амброзио и прочими реинкарнациями вечно озабоченного бездельника и провокатора, совершенно не о чем.

Может кому-то это покажется смешно, но это ноу-хау.
До которого НИКТО в мире пока не додумался. НИКТО. Я узнавал. И постоянно мониторю инет насчет этого.
Хотя идея достаточно проста и "лежит на поверхности".

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

Теперь можете смеяться сколько влезет. Я все сказал


Я сказал "типа как в венде", а не "точно как в венде".
Поэтому у меня ОС реального времени. а не как венда.

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

Весь секрет в проектировании системы и выборе процессора

А вообще, RTOS и прочее "ногодрыганье" для программиста не сложная задача.
А вот написать какой-нибудь парсер, компилятор, IDE, САПР для 3D, экспертную систему с ИИ - вот это реально "сложные программы"

Ну вылитый неуловимый Джо.

Ни у меня никогда такого не случалось , ни в страшилках бродячих по инетам я не читал чтоб кто-то страдал от зависания потоков.
Вот инверсия приоритетов это да, почему-то бичь у NASA и подобных контор.
Правда она там длится буквально миллисекунды, но они к этому панически относятся.

В MQX все! сервисы синхронизации имеют таймаут.


Чисто схоластически отмечу, что если автомат напрямую меняет переменную стостояния другого автомата, то это один и тот же автомат.

Уккшенный воблой, если так рассуждать, то как по мне сложным является или искусственный интеллект или программа байт реверса для авр на асме меньше 12 ти комманд и 13 тактов. и если первое рано （без всяких там табличных и пересылки с порта на порт） или поздно победят, то второе наверное вечно😜

С чего вы это решили?

Да ну? scmRTOS не менят приоритеты задач на ходу, они там статически задаются на этапе линковки, и тем не менее, это ОС.

Я написал, что "Одновременно предоставляя все необходимые для этого сервисы".
Ваш троллинг не удался.

А Вы выложите краткое изложение с примерами, как именно Вы делаете, мы и подскажем.
У каждого свой подход, перенимать чужой опыт Вам будет сложно.
Например, я практически не иcпользую RTOS, в отличие от выступивших тут апологетов.
Конечные автоматы - наше всё

Это иерархия автоматов!

1.Разумеется не один и тот же.
2.Про "напрямую" это Вы сами придумали и неведомо что под этим подразумеваете.

Проблема в том, что Вы не реализовывали сколь нибудь сложных конечных автоматов и соответственно не сталкивались с тем, как из оптимально реализовывать, например, стеки протоколов в семиуровневой модели OSI как правило описываюбтся в терминах конечных автоматов и при этом на КАЖДОМ уровне это совершенно свой автомат и еще такая же стопка автоматов на встречной стороне. Причем отдельные уровни реализуются еще и на разном оборудовании разных производителей.