Нет, вытесняющей


Только зачем все так сложно, если можно гораздо проще и с гораздо меньшими затратами ресурсов? Зачем проверять, поступил или нет? Зачем писать if(постипило) значит тчо-то делаем, если можно написать - при поступлении что-то делаем?


Дает он очень много - это простота кода, скорость и память. А что отбирает? То, чем и так не пользуемся?

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

Например мне кажется, что применяя SST будет сложнее обеспечить риалтаймовость конкретной задаче т.к. даже принципиальная возможность запуска задачи в конкретный момент времени зависит от того что в данный момент времени запущено, какой высоты этот бутерброд и как скоро он размотается до того момента, чтобы позволить конкретной задаче запуститься. Да да, сейчас вы предложите сделтаь этой задаче высокий приоритет и дескаать она асинхронно запустится. Всё это прекрасно до того момента пока таких задач мало)

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

SST - всё-таки вытесняющая (по крайней мере более приоритетные задачи могут вытеснять менее приоритетные).
http://embedders.org/blog/teap0t/miro-same...ch-perevod.html

Спасибо, интересно, почитал.

Да, тайм-квантов прямо в SST нет, но их можно получить свободно поверх SST. Джиттер будет и там и там.
К стати в SST фактически джиттер приоритетных задач меньше - прерывания блокируются на очень короткое время(часто на 2-3 инструкции), а часто да еще и на заточенной под это архитектуре - вообще не блокируются(lock free).
Но где пример задачи, где реально нужны тайм-кванты?
Я думаю, они нужны в сложных системах, где пользователь запускает приложения, типа линукса, где есть процессы. Да и планировщики там далеко не тривиальные. А в прикладных программах и на мк до 200мгц и DSP я им применения не вижу.
Зато там отлично работает SST, повышает скорость разработке и снижает себестоимость проекта, а значит повышает рентабельность проекта. Там, где для тредов нужен мк на 200мгц и 128кб оперативки, я с SST и C++ обхожусь 72мгц и 16-32кб оперативки.


Вот хотелось бы такой конкретный случай увидеть. Не даите конкретный примерчик, где SST неуместно/сложно/плохо?
Лично я вижу обратное - там, где все легко и просто ложится на SST(события), при чем зачастую на один поток - вешают несколько тредов, при чем 90% времени они висят в блокировке и чего-то ждут.

Ну я бы не стал столь восторженно писать, не могут 99% людей сидящих на традиционных РТОС быть идиотами. Но определенный резон тут есть, не спорю.

Я ниразу не назвал их идиотами. Выбор РТОС обусловлен не только самими потоками, но и зависимостями от других проектов и библиотек.
Я лишь показываю принцип. Сколько вижу примеров и реального использования тредов - везде одно и то же - куча сложного ненужного кода и памяти. И зачастую простейшая задача, которая ложиться не то что на SST, а даже на один поток в event-driven стиле реализована как минимум в 3-4х потоках с вытекающими отсюда проблемами.

Да и PC мир уже давно переходит на event-ы.
Как раньше выглядел Proxy-сервер? - Основной процесс в вечном цикле ждал входящее соединение, и для каждого соединения создавал отдельный процесс(даже не поток), и в каждом таком процессе создавалось по 2 потока - один ожидал данные от пользователя и передавал дальше, второй ожидал от удаленной стороны и передавал пользователю. И того на каждый коннект по 3 тяжелых потока, один из которых супер-тяжелый. Завалить такой сервак DDOS-атакой нет проблемы - память и вычислительные ресурсы быстро кончатся.

А теперь это выглядит гораздо проще - событие входящего коннекта(void on_connected(...) ) создает обьект, который в свою очередь подключается к удаленной стороне и имеет 2 обработчика событий - on_data_received_from_client и on_data_received_from_remote. Код стал в разы короче, работает в одном потоке и требует копеечные затраты памяти и проца, и способен обрабатывать на том же железе в разы(десятки раз, а иногда и сотни) больше запросов.
Мало того - события будут выполнятся тру-параллельно - планировщик сам будет раскидывать события по ядрам(на многоядерном процессоре)/процессорам.

Конечно тут есть свой порог вхождения. Дело в том, что так исторически сложилось, что мозг программиста работает в императивном стиле Ему блокирующий код понятный, он(мозг) его может шаг за шагом выполнять. Чтобы начать думать событиями нужно перестраивать свой моск, привыкать, учить другие языки, где трудно работать иначе(например Javascipt-NodeJS).
Вообще сейчас понемногу тенденция переходит с императива на другие стили - декларативное и функциональное программирование.
Вот сейчас посмотрел на текущий свой код - в классе практически нет функций и конструктор пустой, зато инициализируется куча обьектов и переменных - медленно но уверенно движемся в декларативный стиль, сами этого не осознавая...

Куча кода вот так выглядит:

Ни единой функции - одни переменные. Тело функции-конструктора - пустое!
Программы строим не из императивного кода, а из блоков - кубиков

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

а что такое "императивный код"? https://ru.wiktionary.org/wiki/%D0%B8%D0%BC...%BD%D1%8B%D0%B9

Императивное программирование

Сообщение отредактировал arhiv6 - Sep 8 2016, 02:24

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

Допустим, надо стереть flash-память, что длится до 10 секунд. По теории SST для этого случая (события!) нужно создать свою задачу. Пропади пропадом такая ОС.

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

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

Нет, физически там один поток и один стек.


Если Вы не поняли как это работает и как этим пользоваться, то это не значит, что это работает плохо или этим неудобно пользоваться.

Для стирания флеша(физически) надо всего лишь:
1. Передать несколько байт через SPI (команда стирания, возможно команда разблокировки - RWEN) и слесть с шины.
2. Через некоторое время(по таймеру) опять занять шину и проверить -стерлось или нет. Если стерлось - все, готово. Если нет - опять запустить таймер.
Но это если на шине только одна флешка. А если там еще что-то - понадобится задача. В принципе ничем не сложнее первого варианта, только действия выполняем не сразу, а в теле задачи. И когда шина освободится выполнится тело задачи и флешка будет стерта.

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

Сильно сложно?


Почитайте еще про функциональное программирование