А, ясно. Лаптопско проблемно видео, втора част

Правим каквото можем

Но за разлика от лаптопското видео тук авторът на темата е сериозен предполагам... тъй че ако има някой със сходни интереси - да се включва, ние ще отидем другаде да спамим

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

да, аз знам... даже май не са една идеите ти. Обаче вероятно HCL не е запознат с шантавите ти идеи, тъй че си хортувайте. От мен успех!

Така, стигнахме до истинската дискусия.
Точно така е - някакъв компонент (викахме му актьор горе) реагира на няколко взаимно свързани събития. Ти вече спомена няколко:
1. някой може да поиска от теб да пратиш нещо
2. ти може да чакаш потвърждение че пращането се е случило
3. и да искаш да излезеш с таймаут ако не стане пращането за еди какво си време
4. или някой да поиска да откажеш
5. да дойде нещо (я отговор на твое ако си клиент, я нова заявка от някого ако си сървър)

Ако не разглеждаме опростени частни случаи можем спокойно да кажем че всяко едно от тези 5 събития може да дойде във всеки един момент.

Стигаме до специфичните ситуации, които изискват повече внимание:
А. пратили сме заявка, чакаме отговор (надяваме се) обаче вместо него се изреждат другите, например "abort", или нова заявка за пращане, или неочаквано приемане
Б. нищо не сме пращали но идва таймаут
В. нищо не сме пращали но трябва да съумеем да реагираме на приети данни (говорим за протоколи в които slave-а може да изстреля непоискано съобщение - например emergency в CANopen)

Конкретен въпрос - ако сме повикали блокиращата функция "wait_for_answer()" как правим така че нашия тред да се откаже от чакането (щото друг тред му е извикал cancel()) или как обработваме "emergency_received" callback-а с който CAN драйвера ни информира че е дошло нещо дето не е поисканото от нас? за тия случаи мисля че едната опция е "wait for multiple events" ако се поддържа от ОС-а, но това не е смислено - това си е извъртане до активен обект защото на всяко място за чакане трябва да сме готови да дойде всеки един евент

Едит: това горе да поясним че е стейт машина - нещо дето има стейт и реагира на определен набор събития според собствения си стейт.

Малко се отклони, но това е добре. Един ден ще прикачим едно Wiki към форума и ще систематизираме нещата там. За сега хвърляйте всичко накуп, на мен лично написаното ми е особено интересно. Малко по-късно ще се включа и аз.

Да си кажа и аз 2-те стотинки по темата, така и така @gicho ме намеси в по предната страница. Верно, че следя embedded muse на Jack Gannsle - от време на време има добри неща, човека е много старо яре от още по стара коза. За Miro Samek и идеите му за state machines като алтернатива на процедурното програмиране - определено има идея, но не ми допадна, че е стъпил на UML. Не ме кефи така и до там. Навиците ми са да чета текстов сорс, не картинки и диаграми. Съответно си ме дърпа в тази посока и съм му гледал навремето bare bone arm scheduller-а като пример как се прави това за arm докато се чоплех с тези неща. Та за дребни неща може и да става, но за по сложни просто не го виждам. Ако трябва да има TCP/IP, USB и т.н. по на високо ниво комуникации състоянията стават толкова много, че в един момент едва ли ще може човек да го осмисли всичко. Т.е. едно такова формализиране на нещата колкото и добре да изглежда на теория на практика ще е катастрофа. Затова и масово се е наложил стила на програмиране който всички ползваме в момента. Мисля, че нещо средно между идеите на @gicho и първоначалното питане на @HCL са разните fort процесори - много ядра с много малко памет и изключително малък набор инструкции за сметка на това адски бързи. Да ама и те не са се наложили - дали е заради патенти, дали е заради прекалената сложност да се раздробят проблемите на толкова дребно ниво, че да се опишат с по 100 инструкции за някакво супер малко ядро, но е факт, че почти не се ползват. Поне не и mainstream. Проблема го виждам в изключително високата цена за поддръжка на едно такова решение - всичко ще е толкова оптимизирано и ще е само в главата на създателя му в момента в който го прави. След няколко години дори и той самия няма да може да си спомня в детайли кое за какво е. Затова и се ползват езици като C - защото с тях е евтино, лесно се намират програмисти които да поддържат след време стари продукти.

ти си дал и отговора... да, wait for multiple objects е класика в жанра.
В общия случай целта е нишката да ползва процесорно време, само когато има какво да прави (едно или друго събитие). Проблемът е, че в по-сложните системи има голяма динамика коя нишка, кое събитие и каква реакция трябва да има. Представи си, че споменатия по-горе интерфейс може да е произволен - CAN/USB/Ethenet... Протоколът и операциите също могат да варират. Много трудно би свързал конкретно събитие с конкретен изпълним код.
Аз лично предпочитам да работя със сигнали, защото те са напълно абстрактни. Не ме интересува кой стои "зад сигнала", нито имам някаква обвързване на сигнала с друга информация примерно защо ме сигнализира. За мен това е само 1 бит информация - има сигнал, няма сигнал. Толкоз! Това ми позволява да синхронизирам каквото си поискам, без да се притеснявам от подробности, просто защото сигнализацията е просто сигнализация, без да е обвързана с друга информация. Поне не и на ниско ниво.
Но да оставим какъв е моят вкус, въпросът е че по принцип (поне читавите ОС-и) се стремят да изграждат абстрактност. Демек да не се обвързва конкретно събитие, неговият източник и кодът който обработва събитието, още по-малко начинът на обработка. И поради тия тенденции малко трудно се правят евънт дривън или поне не директно, защото цената на абстракцията е точно счупване на връзката между евънта и неговата обработка. Другият (д)ефект от тая работа е, че се такова мамата на реал тайма супер лесно. То и затова шарените ОС-и не стават много (или хич) за RT.
Разбира се, на теория и при евънт дривъна може да се правят абстракции, но поне аз не бих тръгнал в тая посока...

@gicho, aко искаш да се преместим другаде, макар че аз вече се изчерпах на тема евънти, а и не знам що я дъвчем изобщо Ако ще правиш нещо и ти е полезно обсъждането - ОК, но аз определено не съм голям фен на тая и много други нестандартни техники... Между другото моето мнение е, че липсват качествени "класически" RTOS/OS за ембедед и особено контролери. И ако трябва нещо да се копа, то е в тая насока.

Подкрепям, аз не ползвам графичния му инструмент. Реално UML е базиран на идеята за statecharts и активни обекти. Това е което харесвам и дотам. Имплементацията му в неговия фреймуърк също е ценна. Описанията на концепциите (дето го ликвам 2 пъти в темата) същото е много добре синтезирано начало.
Относно TCP/GUI или други проблеми, които изглеждат големи и неприложими - мисля че това е по-скоро защитна реакция която напира във всеки от нас. И не е само по отношение на актьорите, всяка принципно нова постановка ме кара по инерция да тръгна да търся специфични случаи, с които да оборя използването и.
За GUI мисля че няма нужда да спорим дали е или не е евент базирано? Ако някой знае пример за не-евент базирано gui да каже, ще ми е интересно.
За TCP - широко наложеният BSD API модел за мен е кофти, особено ако извадим "select()". Все повече стекове предлагат и асинхронно API (lwip, threadx netx, ...).
Но реално въпросът, който продължава да стои на дневен ред и за TCP и за GUI е дали задачата е ивент базирана. Другото е въпрос на скалиране - ако намерим причина една хубава идея да не се скалира добре нагоре значи има резон. Това е интересна тема, но мисля че е за по-късно - нека първо докажем че това е "хубава идея" пък тогава ще мислим за скалиране.
При "алгоритмичния модел" (класическите тредове) не виждам какво е по-добро - активните обекти целят да отделят "обектите" но не само като сорс код (класове) но и като рънтайм поведение. Т.е. те добавят методики за дефиниране на проблемите с мултитредово програмиране, каквито липсват в класическите C++ класове.
В класическия модел само привидно има разделение - причината е че работата на моя тред е силно обвързана с работата на други тредове и тяхното поведение. Под "силно" имам предвид повече от това дефинирано от приоритетите им. Там вече става голямата боза, която преборваме с още повече усилия.
Колкото до поддръжката - мисля че и там не виждаме цялата картинка. Какви са ми аргументите:
1. Щом нещо е удобно за моделиране значи е добре структурирано и ще е лесно за поддръжка
2. Щом нещо е добре капсулирано значи ще е лесно за поддръжка
3. Щом нещо е лесно за тестване (самостоятелно, като unit) значи ще е лесно за поддръжка
4. Колкото по-малко зависимости (dependencies) има в едно нещо толкова по-лесно е за поддръжка
И един минус:
1. Колкото по-малко хора разбират едно нещо толкова по-трудно е то да се поддържа

@Миро:
Известен ми е модела в който се ползва "wait for multiple..." но не мога да разбера какво решава. Да изчистим тезата - т.е. твоя стил:
- ползваш wait_for_multiple() на всяко място в треда, където очакваш или искаш да можеш да реагираш на повече от един ивент?
- пожелателно горното значи че на всяка точка на блокиране ползваш винаги wait_for_multiple()?
Това означава че на всяко място в кода след wait() трябва да слагаш код който да може да реагира на всеки възможен тип ивент.

"Произволен интерфейс" - това е което целим да поддържаме, съгласен съм. В предно мнение съм описал точно такава постановка. Можем спокойно да я разширим до "произволна абстракция на какъв да е интерфейс", или по-точно "произволен софтуерен интерфейс към произволен протокол на произволен бъс".
При абстракцията има проблем - избрания интерфейс става нещо като задължителен. Това в общия случай води до замърсяване на namespace-а на другите обекти с този конкретен интерфейс (да кажем, posix stream или нещо подобно). Така TCP стека се жени за posix и не може да се ползва (лесно) на други платформи.

Дали се прехвърля бит или повече не е от голямо значение. Да, един бит е най-простия евент. Ако казваш че при теб се ползва само този механизъм ("сигнал") е ок, но казваш че ползваш wait_for_multiple() което не е един бит (е, бит е за получателя ама са много отделни битове на изпращачите). Получателя ще иска да знае кое от тия много му е вдигнал неговия един. Това той не може да направи сам (без ОС-а дето му е имплементирал wait_for_multiple()).
Кю-тата които са входа на активните обекти са аналогия (по-точно алтернативата):
- будят треда при кое да е вкарване на нещо в тях (multiple частта на wait)
- дават информация конкретно какво е това което те е събудило (тип на събитието)
- могат да са дълбоки - нужно е понеже говорим за мултитред система и не можем да си позволим загуба на заявки идващи от неизвестен (за нас) брой дразнители (предполагам че wait_for_multiple за който говорим също има някакво FIFO, по възможност приоритетно)
- а могат и да са плитки - когато система е по-проста и интегратора прецени че е допустимо (дълбочината на входното кю не е част от имплементацията на обекта - то е конфигурационен параметър който фреймуърк-а използва при създаването на обекта за да нагласи дълбочината - също както ползва и параметъра "приоритет" - треда и кю-то са част от фреймуърк-а и се настройват за всяка интеграция без това да променя кода на актьорите)

Това пак ни води към един от постулатите на предните линкове: ползвайте тредове но се стремете те да имат само една обща входна точка (кю-то) защото:
- не знаете кой, кога, какви, кому и колко заявки ще ви вкара
- отговора "зает съм, опитай по-късно" е автогол от световна величина, т.е. това не е допустимо рънтайм поведение, това е фатална грешка при която системата ви трябва да изпадне в защитно състояние (абе да вдигне голяма грешка) - показва че интеграцията в тази система не е оценила връзките и е забравила да сложи правилния размер на входното кю на някой актьор, и това което се очаква е ... firmware update който да реши този бъг
- не искате да дублирате кода за проверка на типа на заявката (dispatcher-а) на много места (дето на всичко отгоре е стеит-зависим)
- сигурно имате вътрешен стейт който променя реакцията ви на някой от евентите - понеже сте стейт машина

Едит: ако модератор прецени да сцепи темата в нова - нещо като "Event базирано програмиране за ембедед системи - концепции, реализации, предимства и недостатъци"?

Пак ти казвам, това деление е от чисто практична гледна точка. В теорията няма такова деление, т.е. ако има някакви "предимства или недостатъци" те са следствие от конкретната имплементация, а не от това какъв подход си ползвал.

Който подход ти харесва, него си ползвай. Аз не искам да участвам в подобна дискусия. Предпочитам да си говорим за по-практични неща и проблеми

Добре, как да го организираме? Моята цел беше да се допитам до хора с опит как се решават конкретни технически проблеми при писането на софтуера - с идеята че покрай опита си са се сблъскали с тези и други проблеми и имат натрупано know-how.
Опитал съм се постепенно да достигна до тези конкретни проблеми, за да можем да говорим за тях - без да увъртаме. Целта ми не е да накарам някого да смени подхода си - това си е лично мнение. Моето търсене е какви са алтернативите - защото не смея да твърдя че съм намерил идеално решение на тези конкретни проблеми и продължавам да търся, но и не искам да карам по инерция. Да не говорим че поради наследения код не мога винаги да прилагам идеите си на практика.
Надявам се че подобна дискусия може да е добра база и може би ще помогне на някого, някой ден? Очаквам и други колеги да се включат вече, мисля че сме съвсем близо до практиката - дали ще са предложения, дали ще е описание на решение, дали ще са въпроси по изложеното. Опитвам се да включвам и конкретни примери - за мен често е по-лесно да си представя нещата когато са подплатени с конкретни житейски ситуации. Иначе става твърде академично и неразбираемо.
Тъй като екипът в нашата фирма е силно обременен с наследството търся начини - примери, начин на описание, които да ми позволят да сведа тоя подход до тях. Никак не е лесно, но ще дам пример - разбирането на актьорите оставаше на ниво "много хубаво, но не става за нас, няма големи ползи". В момента в който вкарахме "чистите" функции като подход (в началото съвсем отделно от актьорите) имаше просветление - видяха се много предимства, но почнаха да светкат лампичките и да се търсят начини тия "чисти" функции да се вкарат в практиката, т.е. да се интегрират в мултитред системите. Там вече актьорите придобиха цвят и обем и изведнъж част от хората (тези за които ползите от "чистите" веднага биха влезли в употреба) почнаха да правят връзката и да виждат общата картинка.
Сега проблема е (какво във всеки екип) че немалка част не могат или не искат да превключат. Другите натискат и макар че са на по-високо ниво срещат достатъчен отпор за да сме в леко патова ситуация. Силови методи има, но за мен са грешни - от моята камбанария правилното е да успея да представя нещата по разбираем начин така че опълченците поне да свалят леко гарда.
Та в тази връзка може би е малко егоистично да използвам форума като "пясъчник", но се надявам това да бъде извинено. От моя страна остава отворен за дискусията. Ако прецените че трябва да я отделим (преименуваме) нямам проблем. Ако кажете че искате да сменим насоката, ще приема. Но най- ще се радвам ако някой желае да сподели нещо.

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

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

Малиии, що писане сте изписали...

Що бе, "проблемното видео" май е 20 и горница страници, ние сме на трета? Що с тоя двоен аршин?

Миро, да, проблеми има и много други, както във всеки екип който се блъска да направи нещо и има sizeof > 1. Това става за оправдание да се кара по инерция.
Аз оставам отворен за продължаване на дискусията ако има желаещи.
Пак уточняват какво целя - да се дефинират проблеми свързани с организацията на софтуера и да се предложат и обсъдят решения.
Между другото, някой може ли да ме насочи или свърже с "кадри" в БГ които работят в тази област? Софтуерно инженерство май му викат. Преподаватели, лектори? Изобщо наблизо (Балканите) има ли предлагане на обучения по темата, но с достатъчна компетентност и дълбочина? Надявам се че ще успея да издействам бюджет при нас, но не намирам лектори по нашите ширини.
Може би някой преподавател в софийския?
Сигурно има конференции по темата? Нещо като "EmbedCon" ...

Защото само в тая тема не съм писал - ето ти програмата на тукашната Ембедед конференция (стр.4-6), Ноември 22-23
http://www.delegia.com/app/Data/Project ... nda_10.pdf