Може би изтървах нишката какво точно искаше да се коментира... Сега като преглеждам постовете ти май искаш да предложиш заместване на ОС с евънт програмиране. Ако е така, не мерси! Аз поне не проявявам интерес, минал съм по тоя път и нямам носталгия

Колкото до страховете ви да ползвате някакъв ОС.... не съветвам никого да скача в дълбокото, но ако работата ти е във водата... редно е да се научиш да плуваш!

То не са толкова страхове. Трябва да узрееш за някои неща.
Но има и друго. Не всяка булка ти е по вкуса пък дори и съпруга и сам да ти я предлага.
Аз не гледам на ивент дривън и ОС като на взаимноизключващи се. Миро, предполагам, че в твоя ОС все пак ползваш прекъсвания. Това не е ли ивент дривен, макар да не движи цялата система, движи някаква част от нея.
Според моя скромен опит, при определен тип задачи, само с ивент дривън не може да се направи многозадачна ситема. Тогава идва нуждата от някакъв вид schedule driven подход. Това най-общо и повърхностно казано разбира се.

Един въпрос към тебе Миро. Като казваш, че ОС-а е съвкупност от правила, подход, стил или както там го виждаш, какво има в тази съвкупност, което помага за тестване на една такава система. Имам предвид тестване с добър процент покритие на възможните сценарии. Например в ето този линк от една друга тема има една хистограма:
https://git.embedded.rwth-aachen.de/rtandroid/docs/
Не знам какъв процент от възможните сценарии покрива тази хистограма, щото това е по-интересно, но статистически подход към тестване или по-скоро измерване на поведението на системата говори вече нещо. А не фолклор от сорта: риълтайм и по-риълтайм.
HCL сори че темата се отклонява към ОС "подхода", но подхода за който отвори темата за мен не е алтернатива, той е най-правилния подход ако имаш ресурс да го прилагаш когато е целесъобразно. Алтернативния подход е ОС-чето за микроконтролер.

Да, това е насоката на дискусията която исках да придам на разговора. Надявам се че и HCL е имал това предвид като прехвърли темата от другия топик.
Плувал съм не малко - освен кефа остава и соления вкус, плуващите дамски превръзки и други екстри които те карат да искаш да излезеш малко на някое тропическо островче и да се разнообразиш...

Като оставим общите приказки на страна, да задълбаем - ще споделиш ли каква постановка за event програмиране те е разочаровала?
И друг път съм цитирал че идеите на Miro Samek, които са точно ROOMS и statecharts от UML, т.е. "active objects" или "actors" са най-близо до идеалите ми.
Ще сложа няколко линка за справка - убедил съм се че не мога да обяснявам добре.

http://www.state-machine.com/doc/concepts.html
http://www.state-machine.com/doc/articles.html
http://embeddedgurus.com/state-space/

Тия дето се наричат "embedded gurus" (бая скромни са, а?) са все мастити имена. Колегата palavrov често цитира newsletter-а на Jack Ganssle. Barr беше правил анализа на нежеланото ускорение на тойота. Не знам дали тук беше цитиран документа, но са го пуснали в една стая без никаква връзка с външния свят, с всичкия код и документация да гледа и проучва.

Друга справка може да бъдат руснаците от Eremex - колега ги беше цитира за техния PCB рутер, но те правят и "RTOS":
http://rtos.eremex.com/

http://rtos.eremex.com/cms/f/445106/FX-RTOS_architecture_guide_en.pdf

Това е едната част - допълване на класическото виждане за обекти с екстри за контрол и управление на работата им в многозадачна система, т.е. капсулиране на поведението по отношение на поредността на външните заявки (извиквания на методи).

Другата част, която е интересна са т.нар. "pure functions" или "pure functional programming". Базовата дефиниция че кода е съставен от функции, които гарантирано ще реагират по един и същ начин (ще върнат един и същ резултат) при един и същи аргументи.
Тук уловката е че функциите са "чисти" само ако са тотално независими от каквото и да било в системата, различно от техните аргументи. Това автоматично праща каквато и да е функция ползваща динамична памет в 6-та глуха - ако я повикаш с почти изчерпан Heap тя ще гръмне, независимо че и подаваш същите аргументи ... Това се пренася за общо взето всички функции, които се опитват вътре в себе си да викат функции от други "модули". Дали ще е I/O достъп, heap или каквото и да е друго подобно няма значение. Ако викаш функцията и тя може в един момента да каже OK понеже файла съществува, а в друг да гръмне понеже файла е изтрит, отворен от друг или не е mount_ната файловата система, то тя вече не е "чиста".

Тук първата реакция (и моята разбира се) е че това е тотален шит - няма как да направиш каквато и да е смислена програма ако не ти позволяват да правиш I/O - за чий тогава я има тая програма след като не може да запише или принтне резулатата от работата си? Да, ама не Точно там почва интересното:
https://en.wikipedia.org/wiki/Functional_programming#Pure_functions
Голям бонус е че такива функции се тестват много по-лесно - те са "чисти", т.е. изолирани от каквото и да е в обкръжението и затова пускането им на друго обкръжение (например тест на PC) е безкрайно лесно.
Това е което преди имах предвид като казвах да търсим начин да намаляваме зависимостите в кода.
Има си цели езици създадени само с целта да се ползва такова програмиране - Scala например.

Като пример за такава функция е snprintf - получава всичко като аргументи и работи. Аналогичната printf има бол зависимости - putc, кой стрийм да ползва (къде да излиза) и т.н.
Друг пример за подобни функции са crc32 - всичко което ползват им е дадено като вход и резултата го връщат.

Доста ценно при тази идея е че малкото "ефекти" от тези функции са ясни и стабилни - например брой цикли за изпълнение и количество зает стек. "Стандартната" концепция може съвсем скрито от програмисти вътре да повика блокиращи функции (putc в printf например) и от 10мкс да станат 10с или да излющи 1К стек щото някой по линията (сериен драйвер?) решил да прави буферче или нещо друго.

Тази концепция не налага да се пишат функции мастодонти - не е проблем да се викат други функции, стига и те да са "чисти"...

Двете части се връзват заедно е един общ модел - active objects реагират на събития-дразнители и изпълняват компактни run-to-an-end сегменти код. Тези сегменти код се описват като "чисти функции" и се постига желаното действие. Прегрупирането и реизползването на код са улеснени от чистотата на функциите (липсата на зависимости). Поведението в живата система е ясно поради модела на активния обект - той е един thread, действията в него се изпълняват без да се прекъсват (последователно - message queue). Не са необходими мерки за защита от preemptive повикване - това се осигурява от еднонишковото подредено изпълнение. Не може да има гадости като deadlock поради тоталното разделение на отделните обекти (в отделни thread-ове) и връзката им през queue-та.

Двете концепции работят заедно в стила на обърнат контрол (Inversion of Control). Ако имаме протоколен стек и транспорт - например MQTT протокол и TCP транспорт, то те остават тотално независими. MQTT сорсовете не include-ват нищо подобно на "transport.h" или "tcp.h" или "stream.h".
Протоколният стек и транспорта си остават два тотално независими компонента, каквито и трябва да бъдат. За да сработят заедно се появява един трети играч, който се заема да създаде инстанции от двата компонента и организира прехвърлянето на "MQTT буферите" с форматирани заявки към избрания от него транспорт - tcp. TCP компонента не знае че данните са MQTT, МQTT не знае че минава през TCP. Компонентът MQTT има аргументи като user, pass но няма аргументи от типа на "transportType" и/или "IPaddress". Тези данни са известни на интегриращия (третия играч) които дава половината на транспортния компонент (ip адреса) и другата на на MQTT протоколния стек (името и паролата). Това е доста по-чисто от реализацията при която MQTT получава всичко и трябва да предаде тия данни (IP адреса) на следващия.
Да, интегриращият има всичките аргументи, но той пък не включва никаква имплементация на транспорт или протокол. Затова смяната му е лесно - когат има нужда да се направи връзка с друг транспорт. Когато се появи тази нужда новата имплементация на "третия" играч ще свърже MQTT със сериен например - но тогава спецификата на връзката (различното API) на серийния драйвер се решава точно в тази интеграция. По този начин няма нужда да се прави абстрактно представяне на серийния да прилича на TCP (или обратното).

Не си прав - не е част, това си е АБСОЛЮТНО 100% цялата система. Няма едно нещо дето да не е "ивент дривен", пък ако ще да се говори за линукс, виндоус, андроид или каквото и да е друго.

Много хора остават с погрешното впечатление че има нещо като "вътрешни събития" - няма такова нещо. Тези вътрешни събития гарантирано са предизвикани от някой интеръпт в системата. Да, може да са "забавени" и обработени в по-нисък приоритет, но за всяко едно от тях точно може да се каже кое хардуерно прекъсване ги е предизвикало и да се проследи върволицата до началото.
Има едно погрешно схващане че някой неща са вътрешни понеже се случват в superloop_а на системата или след определено време (на определен интервал). Мда, само че тоя интервал откъде дойде? От прекъсването за тик на ос-а (или съвпадение на време при tickless кърнел), или от вдигането на флаг в UART регистъра който superloop-а дебне с polling щото не знае как да си пусне прекъсването.

Едит: отричането на event базираното програмиране трябва да бъде първото, което да си изясним тук. Иначе няма поле за дискусия изобщо.

Едит2: Zdrav, мерси че се включваш, имаме нужда да ги изговорим тия неща и да обменим опит. Това е добро начало.

Да допълня линковете че горе се отнесох - разгледайте MQTT реализацията на Eclipse Paho проекта - по-точно embedded C клиента.
https://eclipse.org/paho/clients/c/embedded/
Там има една част която се казва "MQTT packet" - serializer - той разбира от MQTT термини - име, парола, публикуване, регистриране. Функциите му получават аргумент буфер и след като бъдат извикани попълват в тоя буфер (връщат) пакета описан според MQTT спецификацията. По този начин те са независими от транспорти и тем подобни по веригата.
Който иска да ги тества може да ги ползва като им подава аргументи и следи какво са напълнили в буферчето - безпроблемен "unit" тест без mock-ове или странни тестови имплементации на тцп през локалхост към някаква сложна тестова система.
Върнатият буфер е крайната точка на MQTT - от тук никой вече не знае нищо за MQTT спецификацията или терминология. Дали ще ходи по TCP или през морзов телеграф са неща които няма как да повлияят на MQTT сериализатора.

gicho,
Въпрос на гледна точка струва ми се. В моята терминология има външни събития(ивенти) и вътрешни. Критерия по който ги разделям е дали идват от външния за системата свят или от вътрешния. Дали предизвикват прекъсване или не това е друг въпрос. Ако идват от външния свят не винаги можеш да определиш кога и колко често ще се случат докато още калъпиш системата т.е. on build time. Докато schedule driven събитията, които са твърдо във вътрешния клок домейн и се управляват от кода, който пишеш, има възможност да ги определиш как и кога ще идват още on build time.
Когато казвам ивент дривън имам предвид системата да е като слейв на външните събития. Те и определят ритъма и разни цикли или предизвикват непериодични асинхронни на нея събития и тя се синхронизира и адаптира по тях - външните събития. Най-често използвайки прекъсвания. Най-простото - прекъсване вързано на бутон или прекъсване от запълнено FIFO на сериен канал от данни дошли отвън.
Докато schedule driven е като програматор за пералня или сфетофар, твоя код, твоята система, командва и налага ритъма. Пак може да има прекъсвания от таймер, ADC или DMA например, но те не са генерирани от външни за системата събития.
Не ми казвай пак, че прекъсване от таймер е на еди си колко си микросекунди от външно събитие(натискане на бутон), защото таймера не е задължително да се клочи от бутон или да се спира/пуска/ресетва от него.
Както каза tgi преди време в една друга тема просто "курдисана аларма"
Бутона го натиска задклавиатурното устройство, когато най-малко го очакваш и когато то само си реши.
Разбира се за да изясня терминологията говоря за опростени системи. Все пак в голямата си част ембедед системите с микроконтролер все още са такива, нали?
Нямам за цел да таксономизирам всички ембедед системи, само исках да изясня терминологията, която използвам. Правилна или не.
И не става въпрос за отричане на ивент дривън. За мен ивент дривън и скеджуъл дривън не са взаимноизключващи се. Обикновено правя някакъв хибрид между двете.

Точно така е, ама не баш. Да изясним това чудо наречено "вътрешни" събития и да потърсим разлики с "външните". Таймерът твърдя че е външно събитие понеже не виждам разликата между него и коя да е друга периферия. Какви бутони имаш предвид? Да, има клок, но не виждам причината и да го няма - RC верига пак е времезакъснение. А това че таймера се пуска и спира от външно събитие няма как да не го приемем - тоя таймер е или таймаут на някаква операция (значи "старт" му е започването на операцията, която може и да е бутон, може да е приет етернет фрейм или каквото и да е друго) или някакъв вид тик. Тия тик-ове има смисъл когато функцията дето викат прави някаква проверка (polling) и веднъж на много викания сработва друга линия от кода им - понеже са видяли флаг на UART или нещо друго - ВЪНШНО. Т.е. това е замаскиране на събитие, или polling за откриване на събитие. Но това не променя истината че кода след това трябва да е написан като евент - за да може да се ползва както на системи дето poll-ват, така и на нормални interrupt-capable системи.
Характеристиките, по които ги отделяш доколкото виждам са:
- schedule driven - тука малко ме загуби и трябва да поясниш - може би имаш предвид че това са "събуждания" през семафори, мейлбокси, таймаути, т.е. такива които сработват когато шедулъра каже давай? Ако е така да разгледаме историята преди това "давай" - разплитайки нишката това ще доведе до нещо "външно", което е предизвикало стигането до тази точка. Например усера е натискал бутона и 3 часа по-късно изтича времето според което телевизора да се спре понеже изглежда някой да е захъркал на дивана. Махаме натискането на бутона (външното събитие) и вътрешното изчезва. Реалното "външно" е изтеклия таймер (дали ще е хардуерен и тик който врътва един от много "софтуерни" е без значение).
- системата да е слейв на външни събития - еми коя система не е? не ограничавам питането до ембедед, говоря за всички.
- програматорът за пералня не е нищо повече от sequencer или таймер (пак го броим за външно понеже си е периферия) - справка - ако го пишеш тоя програматор дали няма да закачиш state машината на таймерското прекъсване? (не разбирай буквално, таймерското може да буди таск който да свършва работата, но този таск дето чака нещо да го събуди си е пак евент хендлър който обработва евента "изтекло време").
Това което предлага Samek (мисля че го има добре описано на някой от статиите са сайта му) е да се ползва шедулър и тредове, но в друга постановка. А тя е active objects:
- отделните активни обекти работят в собствени тредове
- заявките (събитията) към актъорите влизат асинхронно - най-често през мейлбокс или queue
- треда е организиран така че има само едно място на чакане (блокиране) - това е чакането на входния мейлбокс/кю
- забранено е блокиране на други места в треда
- обработката на събитие се случва в приоритета на треда и други събития тоя active object (актъор) не обработва докато не свърши първото
Постановката е: тред, while(1), в него wait() и след него стейт машината или каквото там имаш нужда, описано като run-to-an-end функции или парцали код (които не блокират никъде), но в определени места могат да излъчват други събития (които заминават и влизат в кютата на други актьори).
Предимствата са много - ако знаем че никой друг паралелно не пипа нашите вътрешни данни нямаме нужда от забрана на прекъсвания, мутекси и други грозни неща за да пазим 1 байт от нашите (вътрешни, собствени, капсулирани) данни. Остави че става по-кратко, по-важното е че се избягват допълнителните "екстри" като инверсия на приоритетите.

Практически препоръката е:
- намирате си RTOS за вашата платформа / микроконтролер - така най-лесно и безболезнено получавате работещ шедулър за тая платформа
- пишете си в горния стил като ползвате само шедулъра и кюто (за по-лесно може да си направите абстракция на тия сървиси но има и по-чист вариант)
- свиркате си

По-чистият вариант е да изолирате тия услуги и да направите един фреймуък който да борави с термините актьор, събитие. Частта със създаването на треда, въртенето му, while(1)-то остават във фреймурка (приложния код не ги прави и не ги вижда). Приложният код дава информация за актьора - приоритет и функция която да бъде викана когато има събитие за този актьор. Реално приоритета се задава на интеграционно ниво - имам предвид че пишейки MQTT актьора не задаваме приоритет.
Фреймуърка прави създаването на тред за всеки актьор, има си прототипна функция в която се намира while(1), чакането на кю-то и т.н.
Т.е. функцията която пишем в приложението загубва частта с while(1) е става неблокираща - тя ще бъде викана от фреймуърка когато има нещо за вършене и трябва да върне без блокиране когато свърши работата.
Това не значи че този код ще тича без да има preemption - ако се появи нужда друг, по-високо приоритетен актьор да направи нещо то нашия тред ще бъде preempt-нат и другия ще си сработи. Само за нашия алгоритъм това е без значение - ние не делим нищо с него и за нас неговото включване е невидимо (баш като прекъсване). Ако той има да ни каже нещо, т.е. иска да повлияе на нашия актьор, то той праща събитие - което обаче влиза в кю-то и пак не ни пречи.

Самек предлага такъв фреймуърк - QP. Той е малко повече от това - той си прави шедулъра за поддържаните от него платформи и прави обкръжението. Но това е комерсиално нещо и макар с отворен код струва една шапка пари - върти ми се 8 бона за лиценз за един продукт ...

Кога го изписахте това бе?

Дълго време (от 90 и някоя до 2000 и някоя) съм бачкал точно с евент-дривън подхода. Просто тогава използвах едно контролерче (Philips XA51) дето беше 16-бит надсройка на 8051 и имаше концепция с приоритети и софтуерни заявки. Така вместо нишки лесно се пишеше в софтуерните заявки, няма ОС, няма кърнел, хардуерът сам се грижеше. Ако искаш нещо да се изпълне вдигаш един бит и когато текущото ниво падне под приоритета на заявката, проца сам превключва...
Всъщност и сега повечето контролери могат софтуерно да вдигнат заявка за кое да е прекъсване и то ще се изпълне "когато му дойде времето"... Но да се върнем на..... да се върнем на теорията. Всяка една система на теория трябва да изпълнява определен брой задачи. При изпълнението на задачите трябва да се получи някакъв логически верен резултат. Сега ако системата е за реално време, то всяка задача освен че трябва да даде верен резултат, трябва да го даде и в определен интервал от време. Ако не успее да стори това, имаме провал. Имам предвид и верен и навреме. Всичко останало е провал, примерно няма значение че е дала верен резултат ако не го е дала навреме.

Това е грубо казано теорията. От тук нататък какъв подход ще използваш няма значение, важното е да няма провали. От гледна точка на операционната система, нейната работа е така да разпредели ресурсите (процесорно време) на отделните задачи, че да няма провали. Съответно има различни алгоритми и те се оценяват. При евънт-дривъна също може да има вариации, може да се използват статични приоритети, т.е. ако имаш две или повече събития, събитието с най-висок приоритет получава проца. Това е напълно аналогично на RMA. Но може да има и други реализации. При всички случаи за реал тайма е важен алгоритъма, а не дали организацията е такава или онакава...
С две думи няма значение как е "driven" важен е алгоритъма за споделяне на наличните ресурси. Останалото е въпрос на вкус Левски срещи ЦСКА

Все пак, въпреки че евент-дривъна няма предимства/недостатъци от гледна точка на теорията, то чисто практически е по-кофти подход, защото ние малко или много мислим алгоритмично и понякога е много по-лесно да опишем последователност от събития на едно място в кода. Изобщо не всичко е евънт дривън, имам и други варианти. И затова стандартния ОС подход с нишки е по-добър, защото не те ограничава в един или в друг стил. Ако щеш си бачкай само с евънти, ако щеш полирай, ако щеш - каквото щеш... Тук някой може да каже, че ако следваме точно определен стил и следваме само него ще е по-лесно да се хващат бъгове. Така е, само че това важи за повечето стилове и не е нужно силът да е точно еди какъв си...

Смисълът от всяка една теория и изобщо науката е да прави предвиждания. Щото има много теории, примерно в една тема дето обсъжат торсионни полета - теории, теории, ама накрая нищо дето да го мернеш практически....
При ОС-вете, поне големите и добрите често пишат тестове, една част са точно следствие от теорията. Приерно типичния малък RTOS е с RMA scheduling. Тоя алгоритъм се знае, че се справя стига cpu-usage ти да е под 69.9%. Ето ти един прост тест, т.е. пряка полза от тва че използваш нещо, а ни си измисляш сам "теории".
Разбира се, някои предлагат и специализирани тестове за най-различни неща... Примерно ако видиш фуксията там има повече тестове, отколкото полезен код. За мен са полезни тестовете на стековете, друго почти не ползвам. Но и аз не се интересувам кой знае колко от real time или пък safty.... Слава Богу, не изстрелвам совалки

Да, единия начин е да се правят софтуерни прекъсвания. Но в общия случай те също са лимитирани и ако не стигат трябва да се добави някакъв вид preemptive scheduler.
"По-лесно" е субективно понятие и често е в конфликт с други критерии, например портируемост на кода. Може да ми е най-лесно да повикам някоя функция от стм32 периферал библиотеките директно в mqtt модула, но това съвсем не се връзва с "по-добро".
Стандартният подход с нишки те води към определен подход. Както казах RTOS-а е добра база за реализиране на евент дривън програма, но поради натрупаната история в нашите глави и написания код наличието на RTOS подвежда да се пише "алгоритмично", да ползваме твоя израз.
Това е "лошо" по няколко причини - написания код става зависим от наличието на RTOS и на следващия проект, който иска да ползва 5% от кода на оригинала пак трябва да слагаш ОС.
При нас често се налагат подобни "скалирания" и нещо трябва да върви както на 8-битов, така и на няколкокоров атом с линукс. Дали сме сбъркали че не сме се мъчили да подкараме микро-линукс на стм8 или 8051?

Ако позволите, нека да запазим стила и да се опитваме да изчистваме термините и изразите, които ползваме. Няма смисъл да пускаме с убеденост твърдения без доказателства или поне пояснения.
- има ли системи, които не са евент дривен? нека не хвърляме в дискусията огромни системи от типа "PC" за които няма да имаме време да говорим, дайте примери за отделни задачи които трябва да потвърдят тезата за наличие на не-евент дривън задачи
- стилът не е само за да ни е "по-лесно" - понякога лесно за нас значи трудно за други, или трудно за нас на по-късен етап; критериите за стил могат да бъдат по-ефективно тестване, по-ефективно код-генериране на база някакъв модел (UML като изчерпващ пример) и други
- налагането на конкретен стил или подход трябва да стане само след много внимателна оценка понеже определя съдбата на екипа/продукта/фирмата за доста години напред - ако ми наложиш да ползвам rtos, не дай си боже конкретен rtos за да ползва твоя код то това не е отборна игра

Евент-дривън системите има много предимства от гледна точка на теорията:
- отговарят на критериите за RMA: https://en.wikipedia.org/wiki/Rate-monotonic_scheduling http://www.state-machine.com/doc/concepts.html

- използват по-ефективно ресурса на система
= не изискват имплементация на мутекс, футекс, шитекс, Priority inheritanсе и прочие
= не разходват излишно рам
= не изпълняват излишен код като влизане в лок, излизане от лок, взимане и връщане на семафори

Справки:
http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095
http://www.drdobbs.com/high-performance-computing/215900465

И пак да потретя - да не бъркаме ОС с preemptive scheduler, т.е. да не ги отъждествяваме. Да, типичните RTOS-и съдържат и preemptive scheduler който е разширение на концепцията за ексепшъни/прекъсвания на ядрото към по-гъвкава и софтуерно-разширяема такава, но пак базирана на същата идеология и начин на приложение.
Но този шедулър има приложение и като самостоятелна единица и реално за това говоря - как шедюлъра да се преизползва в системи които не налагат "алгоритмичния" (блокиращ) модел от класическите ОС, ами използват евент-дривън такъв поради предимствата му.

И аз казах, че на теория нещата са равни и е въпрос на личен избор, което е субективно. Но като се има предвид статистиката кой какъв модел използва, ще видиш че едното е екзотика а другото масова практика. А това вече си е съвсем "обективен" критерии ако трябва тепърва да избираш




Ако нещо си направил по добър начин, няма причина да искаш следващия път да го направиш по по-лош начин. Пак казвам, че моето виждане за RTOS е по-абстрактно и не визирам нито един конкретно, а цялостно като инструментариум. Ако щеш замени RTOS с евент-дривън и ако това за теб е най-подходящото не виждам защо би трябвало да се притесняваш че ще се обвържеш с евент-дривъна... Всъщност виждам едно чисто практическа - стъпваш на екзотика и за следващия ти проект може и да не намериш лесно поддръжка за евент-дривъна.... Но така или иначе тия нещата важат и за двата подхода.



По дефиниция системите са евент дривен. Но нашата работа не е да правим заданието, а имплементацията. Говорим за софтуер, който обработва евънти. Т.е. това че хардуерно по задание имаме система с евенти, не означава че софтуерния модел също трябва да е система с евънти. Може и да е, а може и да не



Тук грешиш, няма никаква разлика от гледна точка на теорията.... Пак ти казвам, теорията на RT и на OS касае алгоритъма на споделяне на ограничен ресурс и в зависимост от тоя алгоритъм какъв резултат получваш на края. Освен това евент-дривъна може да има различни алгоритми на шедулинг, не е само RMA.
A останалото за ресурсите и т.н. си е чисто рекламна брошура и няма връзка с теорията. Аз също мога да кажа примерно за моя ОС че използва много ефективно ресурсите. Мога да ти пускам нишки с 0 (нула) байта стек и те да ползват 99% от системните функции, включително да работят с кой да е хардуер или стек. Но това, че драйверната ми система, кърнела и системните библеотеки не използват юзерския стек си е моя приумица и няма НИКАКВА връзка с темата.


Нещо не схванах кое преизползваш... Разговорът ни има смисъл, ако не си нагаждаме условията на задачата. В теорията няма "различни" задачи. Задачата е една - имаш ограничен ресурс и трябва да го използваш най-ефикасно. Не може да кажеш тая систима иска еди-какво си, ама следващата не изисква.... ВИНАГИ се иска ефективното използване на ресурсите. Без значение евънти ли са, не са ли... Разбери че обобщеното понятие RTOS е универсално решение и няма причина да се търси частично решение, т.е. някакъв ОС само за конретен тип задачи. Не и от теоретична гледна точка. На практика - да, единия ос идва работещ за една платформа, ама за друга не работи... Или пък работи по-добре в една ситуация отколкото друга, но това е следствие от практиката, а не теорията.

Казвам че шедулъра е нещо отделно, което се използва както в ОС, така и в концепцията на активни обекти. Т.е. не е уникална характеристика на ОС, нито на обектите. И че ползването на шедулър се прилага и при активните обекти.
Софтуерният модел може да се направи по много начини, не споря. Въпросът е в каква конкретна ситуация, когато имаш както ти казваш по задание системата е евент дривън (reactive), има резон да правиш различен модел на кода? Какви са целите, имаш ли практически примери? Не че не може да се направи - няма невъзможни неща. Но нещата се правят с цел, дефинирана по критерии. Дали да преизползваш кода в бъдеще, дали да стане с минимален ресурс. Все нещо трябва да се цели като се прави инак?
Това че кода е организиран "алгоритмично" както приехме да му викаме и има тред, while(1), код, чакане на семафор, код, чакане на друго, код, вземане, код, връщане и т.н. не променя реалния модел. Стигайки до първото чакане ти си стигнал до чакане на евент - няма как и да е иначе по простата причина че проблемът върху който работиш (заданието) е да чакаш бутона. Както и да се въртиш все стигаш до това чакане. Да, може някъде да циклиш всека милисекунда и да проверяваш "флаг", но това не е друг модел на софтуера. Това е увъртане което не води до нищо положително (повече код е, по-бавно е).
Недостатъците на тоя модел са че отивайки да чакаш даден евент ти блокираш и твоя тред не може да обработи други заявки. И това не е зависимо от приоритета на ТВОЯ тред ами от приоритета на тоя когото чакаш. Това вече е големия проблем - онзи може да е никой в системата и да чака да дойде пролетта, или лятото ако системата е по-натоварена. Това вече не е детерминистик поведение и е неприемливо - за теб идва нова заявка която в 99.99999% процента от случаите си обработвал в границите на милисекундата. Ама сега си блокиран и не можеш. За да се реши това често експлодира броя на тредове - да може всеки евент да върви в собствен тред. Това става но е крайност и пак е точно active object-а - една точка на чакане, един тред. Ако обаче двата треда (за бутоните "старт" и "стоп") са зависими от стейт, т.е. достъпват общи данни отиваме пак на кино - почваме да ключим променливата за стейт с нещо ОС-овско.
Активните обекти обединяват един или повече евента да тичат (да се обработват) в един и същ приоритет. Което позволява да се редуцира броя на тредовете и да се решат проблемите с евенти, които са част от една стейт машина.

Приемам че натрупания "опит" в програмистите има своя резон - т.е. имаш ресурс който е свикнал да пише по някакъв тиртип (стил). Това е аргумент свързан с "елементната" база в отдела. То затова и по инерция се трупа код по този начин.
Но тук говорим за research и търсене на по-добро решение, затова промяната е неизбежна в тази линия на мислене.

Ти можеш да конфигурираш твоя ОС да не поддържа семафори например и ще постигнеш същия размер на кърнела - само че никое приложение няма да сработи. Освен може би такива които са ползвали ОС-а ти за да изградят active objects приложение. Въпросът е не какво още да добавяме, а какво може да се махне (цитат по спомен). И разбира се задачата да се реши.

Същото е и с динамичната памет - бяхме говорили преди по темата. Типична, добре позната и често използвана концепция която обаче е пълна с кусури и трябва да се избягва при всеки удобен случай. Да, това е шок за екипа, да, не е толкова лесно, но ако знаеш колко човекогодини имаме при нас в търсене на някакъв спорадичен проблем който идва от heap-а ще се замислиш. И както знаем, шанс 1:1000000, при клиента става 9 от 10 пъти. И имаме системи където има 4 (!) различни (отделни) heap-а в една и съща система поради различните нужди - едни искат бърза памет, другите искат много памет, третите искат хем бърза, хем много, четвъртите не знаят какво искат ама го искат еди как си. Това е дивотия - приемам че е оправдано в 1-2-5 процента от задачите да е оправдано да се ползва heap. Но останалите 95% не бива да го правят на общо основание, щото в линукс така се правело.

Ooo, примерите в тая посока с лопата да ги ринеш. Честно казано при мен почти липсва ситуация, в която да завися от един единствен евент, та да правя само неговата обработка. Ако ме питаш за такъв пример бих се затруднил повече
Нормалната ситуация ми е от поне 3 събития. Да кажем пращаш/получаваш нещо. В случая чакаш сигнал от хардуера за потвърждение на поредната порция. Но пък не никога не можеш да разчиташ на хардуера, особено ако получаваш... може никога да не се получи, ако някой се спънал в кабела. Така че за да се избегне блокаж ти трябва да се ослушваш и за втори сигнал от някакъв таймер (таймоут). Но целия тоя процес е цикличен в някаква операция, а операторът може да му писне и да иска да я прекъсне, така че ето ти трето събитие.
Но и 3 са рядкост, понеже рядко една нишка е източник или получател само. Обикновено е по средата, т.е. чете от едното място и праща на друго и при пайпалайн си стават 5 събития за които да чакаш едновременно.
И ако това е една операция, то не е задължително да е вечна. Напротив почти никога не е. До операцията обикновено се стига след като са налице едни или други условия. Или пък имаш поредици от различни операции дето трябва да се изпълнят последователно. Естествено че това много по-лесно се описва алгоритмично - при ресет тръгваш от еди кой си режим, после правиш това, чакаш онова, ако стане правиш това и това... Сложно е. И затова пък описването трябва да е просто и прегледно. А не да се опитваш да натъпчеш всичко в схема - събитие -> реакция.

Същото е и по отношение на динамичната памет. Необходима ми е може би в 99.999% от случаите. Или поне е много по-лесно в такъв процент от случаите, т.е. НЕ-използването ми е по-трудно и по-проблематично. Разбира се, нормално е да гледаш да не ползваш нещо безпричинно. И аз се старая, но това изисква повече внимание. Примерно при работа със стрингове много по-опасно е да работиш с char[] отколкото със string... Да, стрингът е по-бавен, ама пък и по-сигурен щото няма буфер оverflow и т.н.
По-скоро въпросът е КАК да ползваш динамична памет, така че да е ПО–СИГУРНО. Защото и аз съм минал през проблемите с освобождаването и т.н., но като всяка детска болест отминава

Аз малко късно отворих тая тема... За какво изобщо става въпрос?

За спам както винаги

Темата беше на HCL за "софт" дизайн/архитектура... демек фпга (и не само). Но после я омазахме на тема има ли по-добри алтернативи на стартното "hard core + rtos" порно...