Я уже лет 15 использую пакет AsyncPro написанный на чистом Delphi.
Там вообще все асинхронное.

Советую кстати задуматься о том как ваш автоматно-кооперативный подход будет взаимодействовать с реально асинхронным потоком прерываний.

Это замечательно


В cortex-M прерывания реально асинхронные, одно прерывание может прерывать другое, все легло на SST без бубна и отлично работает, в том числе под интенсивным асинхронным потоком прерываний.
Над чем тут можно задумываться и какие тут могут быть проблемы?

Ничего, что в C++ сборка мусора специально выполнена в строго детерминированном варианте. А именно: в конце времени жизни объекта(после выхода из области видимости) автоматически вызывается деструктор, который чистит всё что нужно(если нужно). Т.к. время жизни объектов строго детерминировано по каждой ветке выполнения программы - сборка мусора тоже 100% предсказуема. Это позволяет применять плюсы для риалтайм систем.

Представьте что JS управляет хвостовым оперением истребителя, нужно реагировать на команды пилота, но тут вдруг не очень вовремя сборщик мусора проснулся и начал метлой махать )))

P.S. Чувствую сейчас наш гуру скажет, что его не волнует как устроена сборка мусора в JS и что она периодически выполняется JS движком, причем в отдельном потоке(сюрприз-сюрприз) он тоже не слышал
http://v8project.blogspot.com/2015/08/gett...n-for-free.html

В c++ сборки мусора нет, пользователь сам вручную управляет памятью операторами new и delete. Есть, правда, всякие библиотеки типа boehm-gc, но это не имеет отношения к теме.


Ну JS скорее всего туда не годится(хотя не факт). Потом сборщику можно дать определенный приоритет, чтобы он не мешал работать time-critical задачам. Тем более, сборщик мусора для однопоточных асинхронных приложений очень простой получается.
Динамические очереди и стек - это уже автоматическое управление памятью(сборка мусора - отработавших задач, обработчиков событий и функций), а поскольку в SST код состоит почти из одних задач, обработчиков событий и функций, то и эта сборка мусора покрывает почти весь проект, при чем работает очень быстро(порядка 4-10 тактов на cortex-m). По этому(и не только) для меня SST удобнее потоков и на нем разработка приложений происходит быстрее и багов меньше.
Осталось сборку реализовать для остальной части кода, где есть данные "сбоку" задач, например того же GUI, именно в нем я чаще всего встречаю ручное управление памятью(и то довольно редко), от которого при должной языковой поддержке можно полностью избавится. Возможно с Rust этого удастся достичь, или будем на плюсах делать велосипед. Полностью автоматическая сборка мусора - это большой плюс к скорости разработки - это нам и нужно.


Лично на моей системе приложение Node занимает 4-10 потоков. Но что там внутри и почему меня действительно не волнует - я пользователь Node, а не ее разработчик, и мой пользовательский JS-код выполняется в одном потоке и не требует синхронизации.
Или взять Qt, на винде простое приложение - 4 потока, на линуксе - 3 (у кого-то другого цифры могут быть другими, зависит от конкретной платформы и версии Qt), но меня это тоже не волнует - мой пользовательский код работает в одном потоке и не требует синхронизации(если сам своих потоков не наклепаю).

Сейчас у меня на столе встраиваемый модуль с 12-ю базовыми задачами и 6-ю динамическими.
Это обычный простейший контроллер кинематической системы. В роботах таких десятки могут быть.
Это задачи:
-системный менеджер,
-менеджер локальных входных сигналов c фильтрами, антидребезгом, тревогами и проч.
-менеджер PWM модуляторов для исполнительных механизмов и квадратурных энкодеров,
-две задачи на вход и выход CAN протоколов,
-задача USB стека,
-задача VT100 терминала и драйвера UART,
-задача коммуникационного канала с BLE устройствами,
-задача HMI управляющая около сотни элементов индикации-диагностики локально и по сети CAN,
-супервизор контролирующий жизнедеятельность,
-IDLE задача с измерением загруженности процессора,
-задача лога и записи на SD карту.
-задача риалтайм наблюдателя FreeMaster
-динамические задачи двигателя, возникают во время движения для отработки разных стадий траектории.

Вот чё тут делать с вашим методом?
Я ему кстати название придумал - АКОП (автоматно-кооперативный)
Хорошая метафора однако.
В своем акопе пытаетесь укрыться от наступления RTOS. Бесполезное занятие.

И в чем могут быть проблемы?
Подобные задачи отлично ложатся на SST и код проще выходит и ресурсов надо меньше, чем на RTOS.
Я уже приводил в этой теме сравнение асинхронного кода с традиционным блокирующим, как по мне - асинк гораздо проще и лучше., по крайней мере конструктивной критики асинк-кода в пользу блокинг я практически не увидел. Кто-то критикует его за "непоследовательность", но это дело привычки. И то, что лучше - 5-10 строк простого непоследовательного кода или 100 строк последовательного, да еще и запутанного? - каждому свое в виду его знаний и опыта в конкретном стиле. Я работал по несколько лет и в том и в другом, есть с чем сравнивать и в итоге сделал свой выбор.
Не увидел никакой конкретики почему по Вашему мнению сюда не подходит SST, одни голословные утверждения.

Во первых, никакого сравнения для embedded вы не приводили.
C того как сделать 1000 серверных сокетов на Node.js начинаются все учебники.
Это просто копипаста с вашей стороны.

Я еще могу с натяжкой поверить что вы возьметесь переписать FatFS под стиль своего АКОП-а.
FatFS стоит новичку переписать чтобы понять как работает файловая система.

Но в моих задачах не менее 4-х сторонних программных модулей сравнимых по сложности с FatFS.
Перепишете?
Задайте здесь вопрос кто верит что вы сможете переписать TCP/IP, FAT, USB с классами, драйвера уровня HAL, риалтаймную обработку событий и т.д. под AKOП и за какое время.
Флейм будет еще веселей.

Во вторых подсчеты количества строк в таких крупных проектах это ни о чем.
Где-то 50 % строк сплошные коменты.
Коменты и делают код читаемым и понятным. Одно только искусство писать коменты сделает программирование легче в 10 раз. Ваш АКОП нервно курит.
Опять же я не верю что вы строчите код с такой скоростью чтобы экономия строк имела значение. В среднем в день небось максимум сто строк можете написать.
И опять же экономить надо символы, а не строки

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


Все уже написано и переписано давно. Первым была USB(device), лет 12 назад, если не больше написал и пользуюсь до сих пор, иногда вношу какие-то недостающие фичи. Остальные аналогично. Многое использую готовое, тот же mp3, jpeg.
Многое беру готовое и применяю свои патчи(например ogg), чтобы нормально можно было из плюсов и SST работать.

Мы говорим о реальных преимуществах и недостатках SST для нового кода, а не использования несовместимого синхронного legacy кода. Если стоит задача работать с RTOS-зависимым legacy - SST Вам не подойдет, даже C++ не всегда подойдет, часто приходится на С лопатить, чтобы сохранить определенный стиль, хуже того, если проект коллективный и все программисты - сишники.
Если Вы пишете что-то новое свое, используете асинхронные библиотеки, или команда разработчиков у Вас способна учится и не зависит от legacy - SST очень здорово упростит процесс разработки и сэкономит системные ресурсы.
Я тоже на С пишу, особенно писал раньше довольно часто, тк этого требовал заказчик - проггеры, которые будут обслуживать проект не имели знаний и опыта плюсов.
A недавно перевел один проект из синхронного С++ на асинхронный, заняло не так много времени, но код стал короче, проще и появилось куча свободных ресурсов. До перевода они уже закончились, добавлять новые возможности было некуда, сейчас туда можно еще добавлять и добавлять.

По читаемости кода спорить не буду, кому-то комменты дают, а кому-то просто короткий и простой код. С таким успехом и обьектые языки можно заменить простым ассемблером с комментами
Строчу от 200 до 1000 строк в день, хотя бывает и десятка не наберется. Я еще люблю удалять код, из 1000 строк делаю 200.

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

AlexandrY прав. В итоге кроме примера в три строки как на Node.js запустить сервер мы пока ничего не видели. Мягко говоря, это не очень соответствует теме форума.

Я,в одном из своих постов, проанализировал ваш подход не с точки зрения "ай как щас модно, стильно, молодежно".
Было выявлено и показано, что вы очень ограничиваете возможности межзадачного взаимодействия!
Очевидно, что раз задача должна как можно быстрее завершиться и бежать вперед без блокировок то перед выходом из функции, освобождая стек, надо запоминать состояние. Очевидно, что если в RTOS часть состояния задачи сидит себе спокойно в стеке(естественным для программиста образом) то вам придется выделять дополнительную память уже в самом объекте(члены класса) для сохранения этого состояния. Более того - на программиста ложится доп обязанность по обслуживанию этого состояния. Да, вы экономите стек, но sizeof() вашего объекта при этом вырастет.

Опять же в реальном мире и Qt и JS ваш любимый вовсю используют потоки....
Про некоторую вашу фанатичность я уже говорил. Видимо повторяться не стоит )

Состояние и там и там надо запоминать, при чем вручную. В одном случаи - создавая переменную в стеке, в другом - переменную в классе. Кому что удобнее - я не знаю, мне лично одинаково.

Мало того, в лямбдах о состоянии заботится компилятор, а не пользователь. Те задачи, которые ложатся на лямбды - вообще не требуют ручного выделения места под состояние, а таких задач много. И то лямбды в плюсах слабые. Если появится инструмент по-мощнее - будет еще удобнее.
sizeof ессно растет, но он заранее известен, в то время как просчитать стек нереально, если там виртуалы(indirect call/indirect jump) и/или рекурсия.

Интересно было бы увидеть Ваш код, где бы Вы показали простоту/преимущества блокирующего подхода, а я бы привел его аналог в неблокирующем стиле, вот тогда и можно сравнивать. А без этого это голословные утверждения.
Повторюсь - SST уместен для нового async-кода, для синхронного legacy он не катит.

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

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

Пример простоты/преимущества блокирующего подхода засчитан?

Это всё замечательно. Только вот в процессе нашей учёной беседы мы тут обнаруживаем немало ситуаций, когда SST ваш этот жизнь усложняет, вместо того чтобы её упрощать. И даже внезапно выяснилось, что вместо сэкономленного стека sizeof() объекта таки растет. Факт этот был вами парирован тем, что дескаать sizeof то этот статичен, а размер стека непредсказуем.... Так себе аргумент, скажу я вам.... Очереди, на которые теперь ложится весь груз межзадачного взаимодействия и даже передачи данных - теперь становятся резиновыми.
НО вы тут предлагаете на ПК просимулировать всё это дело, опеределить размер очередей который понадобился, потом взять запасик и в продакшн. Было? Быыыло.

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

Нет. ) Нужен реальный пример кода на любом языке

Мне лень вам приводить здесь абсолютно типичный кусок кода из букваря многопоточного программирования )
Кстати подправил своё предыдущее сообщение, дополнил про размер стека.

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

Без кода это разговор ни о чем. Будет реальный пример - я приведу контр-пример на SST.
Стек я подобным образом(и не только, куча вариантов разных было) и вычислял, только тесты сложные ради этого надо делать и не всегда их результат верный - компилятор при первом чихе(исправите где-то одну буковку) может поменять всю картину. А с учетом блокировок - так жутко сложные выходят, блокировка хоть год может висеть.
С очередями такого нет. Да и очереди места меньше требуют, чем стек. В стеке надо все регистры хранить(и не только), а в очереди - пару указателей.
Часто для очередей хватает и места под 1 обьект, но я для запаса делаю под 8, тк расходы на это копеечные.

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

Да и работа в блокинг-стиле не исключает очереди. Одними мютексами там не обойдется, если задача более-менее сложная, придется тулить очереди и Active Objectы, а это уже жуткий гибрид, с которого по-скорее надо спрыгивать на чистый асинк.
Смесь синка и асинка в одном приложении - всегда плохо, я это уже показывал на примерах. Можете попробовать показать обратное на реальном примере кода.

Кооператив все таки слабоват - нужны прерывания, чтобы вытеснять менее-приоритетный код более приоритетным, тут на помощь приходит SST.
A пример реального кода, как глючная задача валит всю ОС я уже приводил. Так что это миф, что многопоточный стиль дает защиту, а асинк - нет. На чисто асинхронном стиле тоже можно сделать должную защиту, просто никто существующие оси(линух,винда), а тем более весь блокинг-софт,который под них работает, переписывать не будет, зато на МК мы можем себе это позволить.