[Solonovatiy 0]

11 minutes ago, tgruzd said:

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

А это уже вопрос из топика под номером 2. Должен ли модуль быть активным? Ну вот считаю не должен. Т.к. иначе он должен знать о всех тех сущностях, что он логирует. А это уже совсем не хорошо.

Если вы про то, что знает КТО его просил и КОГДА, да он и не знает. Там очередь же. Он на ней блокируется, пока не прилетит и все.

[tgruzd 11]

7 минут назад, Solonovatiy сказал:

очередь

примитив синхронизации.

7 минут назад, Solonovatiy сказал:

блокируется, пока не прилетит

 

8 минут назад, Solonovatiy сказал:

КОГДА

 

[Arlleex 190]

9 часов назад, Solonovatiy сказал:

Мне кажется, что с RTOS надо быть предельно осторожным.

Ну как сказать. Надо просто понимать суть ее процессов и заложенных механизмов, а далее влиться в терминологию и логику многопоточного программирования. RTOS не волк, пальцы не откусит.

Цитата

Зло начинается, когда БЛ начинает требовать асинхронности.

Не знаю, зла нет, просто пишется межпоточное взаимодействие. Вы же для МК пишете? Какая там сложная бизнес-логика? Зачастую драйверы периферии и стеки каких-то протоколов нужно лишь грамотно обслужить в многопоточной среде, а вся бизнес-логика - это перекладывание данных с одного места в другое, условно. Все инструменты для этого RTOS предоставляет через различного рода объекты синхронизации потоков.

Цитата

Не говоря уже про то, что лишний таск жрет ОЗУ и не мало, даже по современным меркам.

А не надо лишним таскам ОЗУ задавать от балды, а потом забить на это (ведь работает же все!) и пускать в релиз. Все в меру. Плюс, в очередном проекте задайте себе вопрос - а так ли тут нужна RTOS? Последний десяток проектов разной степени упоротости я писал в суперлупе, скорее, прикола ради, ибо повторюсь, RTOS не панацея.

Цитата

Я давно и долго не могу определиться, надо ли избегать по максимуму "активных" модулей.

Я думаю, проблема у Вас в другом. Вы наивно полагаете, что в мире реально существуют кодопроекты, в которых при необходимости одним взглядом разберется любой сторонний программист-дезигнер. Да сам боженька сходу определить логику, где что крутится, какой скелет программы в целом, как модули взаимодействуют между собой и что вообще, черт возьми, происходит, никогда не сможет. Да, в ЯВУ есть какие-то средства для сокращения явных зависимостей межмодульного взаимодействия, вот только эти явные зависимости превращаются в неявные (например, в делегатах). Так что, я думаю, надо забить на то, как монстроидально это выглядит под капотом, главное, чтобы API для вышестоящих уровней обработки и взаимодействия все было по максимуму простое.

Цитата

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

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

Цитата

Есть какие-нибудь альтернативные пути?

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

Цитата

Бонусом к 3ему, идет если данные надо передавать во вне. Это же их надо СЕРИАЛИЗИРОВАТЬ. А сериализация на С\С++ это чертова боль, огромное кол-во бойлерплейта и вообще пахнет хидерами на 2000 строк.

Вы поменьше гур-студентов из Яндексов слушайте на ютубе, они несколько в другом мирке живут - в мирке больших быстрых процессоров и ОС. И то, порой фигню несут. Всякие сериализации писались, пишутся и будут писаться как и раньше - руками. А чтобы не надо было писать хидеры на 2000 строк каждый раз заново - упрощайте задачу, либо *внезапно*

Спойлер

используйте линукс с валом готового кода и решений

, тогда и не будет каких-то левых абстракций и пространных рассуждений о правильной методике разработке ПО Ее нет, этой методики, и, как Вы говорите, пилюли тоже.

[haker_fox 61]

8 hours ago, Solonovatiy said:

таск жрет ОЗУ и не мало

Не согласен. "Не мало" - это сколько? "Таск" отъедает место в ОЗУ только под TCB, насколько я помню. Можно выключить из TCB всё лишнее, если конфигуратор ОС позволяет. Если не позволяет, то сделать своё ответвление ветки от какой-нибудь ОС. Посмотрите на scmRTOS, она работает даже на микроконтроллерах с 0.5 - 1 кБ ОЗУ и предоставлят самую настоящую вытесняющую многозадачность.

8 hours ago, Solonovatiy said:

Насколько по вашему это правильное мнение?

ИМХО, проблема надуманная. Трудно что-то одназначно ответить при отсутствии сведений о реальной бизнес-логике. Но если начать делать реальный проект, то множество абстрактных проблем исчезает. Вообще, мой скромный опыт приборостроения пока ещё не припоминает каких-либо существенных проблем с использованием ОСРВ.

 

[Forger 26]

35 minutes ago, haker_fox said:

"Не мало" - это сколько? "Таск" отъедает место в ОЗУ только под TCB, насколько я помню.

Задачи требуют индивидуальных стеков, TCB - это слезы ))

 

Все-таки впишусь в холивар 

В моих проектах стеки задач от 128 байт до нескольких кБ. Задач бывает немало, а в некоторых модулях по несколько задач/таймеров.

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

Про диагностику: в реалтайме например могу видеть кто сколько в потолке стека жрет каждая задача и соотв. давать задачам столько, сколько им реально нужно.

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

Короче, если не предусмотрено заранее средств диагностики сложного кода, то лучше даже не начинать.

Это как идти к доктору, у которого даже нет часов для измерения пульса ))

 

[haker_fox 61]

26 minutes ago, Forger said:

Задачи требуют индивидуальных стеков, TCB - это слезы ))

В данном случае я отвечал на вопрос, который обычно задают в ключе, что именно ОСРВ потребляет "кучу" ресурсов. Рассудив, что стек всё-таки зависит от выполняемых задач пользователя, я не стал его включать)

 

[Forger 26]

39 minutes ago, haker_fox said:

именно ОСРВ потребляет "кучу" ресурсов.

Речь шла про ОЗУ:  

10 hours ago, Solonovatiy said:

таск жрет ОЗУ и не мало

расход на ТСB - ничто в сравнении с затратами на стек

[Solonovatiy 0]

3 hours ago, Arlleex said:

 RTOS не волк, пальцы не откусит.

Ну вот как сказать. Мне кажется, вольное и не ограниченное использование - приведет к усложнению кода, там где можно было бы и не усложнять.

 

3 hours ago, Arlleex said:

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

Вопрос про принципы, а не конкретику.

 

4 hours ago, Arlleex said:

Вы поменьше гур-студентов из Яндексов слушайте на ютубе, они несколько в другом мирке живут - в мирке больших быстрых процессоров и ОС. И то, порой фигню несут. Всякие сериализации писались, пишутся и будут писаться как и раньше - руками. А чтобы не надо было писать хидеры на 2000 строк каждый раз заново - упрощайте задачу, либо *внезапно* возьми линукс.

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

3 hours ago, Forger said:

Задач бывает немало, а в некоторых модулях по несколько задач/таймеров.

Вот насчет таймеров еще забыл сказать. Таймеры колбечные вообще зло же какое-то, закладывающий основы callback-hell'а? Я свои все оборачиваю в синхронные оболочки, где в коллбеке попросту ставиться флаг _is_expired и проверяю синхронно, вроде if(TimerA.IsExpired()){} 
Понимаю да, что иногда надо, но когда есть возможность сделать проверку в основном потоке - лучше сделаю в нем. А то - лишний поток выполнения, на пустом месте.
Не кажется ли вам?

3 hours ago, Forger said:

Про диагностику: в реалтайме например могу видеть кто сколько в потолке стека жрет каждая задача и соотв. давать задачам столько, сколько им реально нужно.

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

Короче, если не предусмотрено заранее средств диагностики сложного кода, то лучше даже не начинать.

Вот это прикольная система. Поподробнее опишите?

11 hours ago, tgruzd said:

Сишные структуры, сэр

Вы так пример не привели. Заинтриговали же.

[Forger 26]

17 minutes ago, Solonovatiy said:

Таймеры колбечные вообще зло же какое-то, закладывающий основы callback-hell'а?

Я не использую штатные таймеры RTOS, у меня свои на базе отдельных задач, просто оформленный как таймеры. Оба обернуты в классы OS::Thead и OS::Timer соотв. Реализация отлажена один раз и больше к этому вопросу не возвращаюсь. Нет привязки к типу RTOS (про cmsis-os знаю, не рассказывайте)

А со штатными таймерами (на базе callback) есть проблема (по мне) - в них нельзя использовать сервисы задержки и ожидания событий. Для меня такие "таймеры" бесполезны.

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

Идеальное решение для цикличных действий с заранее известным периодом вызова такие таймера, например, опрос клавиатуры, каких-то входов, некая коммуникация наружу с известной периодичностью, обновление дисплея не по событию, а вот по такому таймеру постоянно с заданным FPS... Короче, вариантов применения масса.

И к тому же для таких простых целей не расходуются аппаратные таймеры.

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

 

[tgruzd 11]

17 минут назад, Solonovatiy сказал:

Вы так пример не привели.

А вы просили разве? И кстати, пример чего?

Изменено 18 ноября, 2022 пользователем tgruzd

[Forger 26]

20 minutes ago, Solonovatiy said:

Поподробнее опишите?

https://www2.keil.com/mdk5/cmsis/rtx

[Solonovatiy 0]

8 minutes ago, tgruzd said:

А вы просили разве? И кстати, пример чего?

 

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

[tgruzd 11]

Ок, кидайте сюда свой хидер на 2000 строк, внятно описывайте проблему, подумаю на досуге. 

В следующий раз, пожалуйста, выражайте просьбу как просьбу, а не как наброс на вентилятор)

Изменено 18 ноября, 2022 пользователем tgruzd

[Solonovatiy 0]

6 minutes ago, tgruzd said:

Ок, кидайте сюда свой хидер на 2000 строк, внятно описывайте проблему, подумаю на досуге. 

В следующий раз, пожалуйста, выражайте просьбу как просьбу, а не как наброс на вентилятор)

Забейте. Я устал по 10 постов вам расписывать. 

[tgruzd 11]

А мне и не надо было.  Хидер в 2000 строк у вас а не у меня.