Действительно нет примеров где нельзя без РТОС. Всякими суперлупами и прочими недо-РТОСовыми решениями можно что угодно написать. Другое дело, разумно ли..

Зачем третья задача? Двух задач, использующих флешку без блокировки этого ресурса, достаточно для нарушения нормальной работы. Например, предположим что для записи во флеш нужно сначала передать по SPI команду на запись, потом адрес, потом передавать данные для записи. И есть две задачи: А хочет записать какие-то 100 байт по адресу 0x1000, Б хочет записать 100 байт по адресу 0x2000. Теперь последовательность без мютекса:

* Задача А передает команду на запись и адрес 0x1000
* Задача А начинает передавать данные для записи - передала 10 байт из 100
* Высокоприоритетная задача Б вытесняет задачу А
* Задача Б передает команду на запись и адрес 0x2000
* Задача Б передает данные для записи - 100 байт
* Задача Б уходит в ожидание, управление передается задаче А
* Задача А продолжает передавать данные - передает оставшиеся 90 байт, но они уже будут записаны не туда, куда нужно.


Нет.



Не буду хаять, извините, потому что сам всерьез и не использовал. От коллег, имевших опыт работы как с FreeRTOS, так и с TNKernel, наслушался, что FreeRTOS очень медленная по сравнению с TN: назывались цифры типа от момента отправки сообщения в задачу до получения задачей управления происходит примерно в 2 раза больше инструкций, чем в случае с TN. Но сам я все это не проверял, так что ручаться не буду.

Может когда-нибудь и дойдут руки до подобных сравнений, но пока нет. Есть более важные вещи.

Вообще, по чесноку, я на вашем месте, наверное, взял бы FreeRTOS и не парился. Если не будете успевать - возьмите железо мощнее. Ведь, как вы заметили, над FreeRTOS работает команда, а не один человек, так что шансы на то, что проект вдруг перестанет поддерживаться, у FreeRTOS гораздо ниже. TNKernel вот уже, фактически, не поддерживается; TNeo сегодня поддерживается, а завтра - неизвестно.

Так это запросто, если вы знаете FreeRTOS то должны знать, что то там нет такой фичи как Event group connection

А это реально очень полезная фича.
В задачу действительно могут посылаться и события и майлбоксы и потоки и на все надо реагировать сразу без последовательного полинга всех объектов синхронизации от которых ожидается изменение состояния.
Во FreeRTOS такого простого механизма реагировать на все сразу в одном вызове сервиса RTOS нет.

Правда в TNeo это реализовано несколько прямолинейно и не гибко.

В MQX, например, не надо создавать некую группу специфических флагов, а у очередей, семафоров и проч. сервисов можно установить специальную функцию нотификации.
А в функции нотификации можно уже взводить хоть флаги хоть кучу флагов для разных задач.



Это понятно, но приоритет тогда зачем поднимать. Тогда семафора достаточно.

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

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


Хм, вообще коллбэк - хорошая идея, надо подумать. Гибкость, действительно, на высоте: в коллбэк-функции можно делать что хочешь, если надо.

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

Может, у вас есть какие-то примеры, что еще может быть реально полезно сделать в этом коллбэке?

Ну и если нужно только установить флаг, то в случае с коллбэком нужно будет сделать для этого больше телодвижений, чем сейчас: нужно будет написать специальную функцию, в ней вручную ставить/снимать флаг, и зарегистрировать коллбэк в TN_DQueue. А сейчас нужно просто вызвать tn_queue_eventgrp_connect() и передать туда указатель на группу флагов и маску.

Подумаю, спасибо.



Мютексы и семафоры созданы для совершенно разных задач, и некоторая схожесть их API порождает огромное количество путаницы в головах. Семафор - механизм сигнализирования, мютекс - механизм блокировки ресурсов. Статья Michal Barr была именно об этом, вот еще до кучи вопрос-ответ на stackoverflow: http://stackoverflow.com/questions/62814/d...phore-and-mutex

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


Чтобы не было инверсии приоритетов, т.е. чтобы не получилось так, что высокоприоритетная задача Б будет ждать низкоприоритетную задачу А (из моего прошлого примера про SPI флешку)

рассмотрите возможность 11. не плохо бы разместить поля id_task, id_mutex и прочие в режиме TN_CHECK_PARAM разместить в начале структур, чтобы проще выявлять виновников портящих память

Спасибо что напомнили, готово в BETA: https://bitbucket.org/dfrank/tneokernel/com...591035f9feac374

Помню, что уже когда-то видел ваше сообщение в ветке tnkernel, мысль правильная, но руки тогда так и не дошли.

http://www.freertos.org/FreeRTOS-Event-Groups.html ?

event group-то есть, а event group connection нет.

Этот connection нужен для того, чтобы, например, ждать сообщения сразу из нескольких очередей. http://dfrank.bitbucket.org/tneokernel_api...ventgrp_connect

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




Все эти рассуждения в принципе наверно правильны если мы говорим об OS типа Windows.

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

К сведению в RTOS Nucleus Plus вообще нет мьютексов, там их роль блокировки к разделяемым ресурсам выполняют семафоры.
Приоритеты задач в Nucleus не поднимаются семафорами автоматически, для этого есть явные функции управления приоритетами. И это более близко по духу к realtime.
А есть еще такие понятия как Lightweight Semaphores, угадайте чем они отличаются от обычных семафоров.
А например в MQX подъем приоритета семафоры делают также как и мьютексы.

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

Т.е. не советую как аргумент ссылаться на stackoverflow.com где большинство в глаза видели один лишь PC.

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

"Семафор", как следует из названия, нужен для сигнализирования, а "мютекс", как опять же следует из названия (mutual exclusion - взаимное исключение), нужен для блокировки ресурсов между конкурирующими потоками.

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

В TNeo роль этих объектов предельно близка к парадигме. Мютекс мы можем заблокировать (tn_mutex_lock) и разблокировать (tn_mutex_unlock); семафор мы можем ждать (tn_sem_wait) и сигналить (tn_sem_signal).

Философия однако, не даром западные программисты все доктора философскмх наук, а не доктора лингвистики по языкам. Для кого как а для меня "мютекс" это и есть один из видов "Семафора". Наверное как и вы, я пользую (к примеру при юзании Free RTOS) их очень много и везде, не очень понимаю как без них можно писать, начиная уже с 2-3 ниток, даже средненький софтик. Но вот разницу в TNeo и Free RTOS к примеру в v7.1 не очень увидел. TNeo, возможно ценна другим, ... вот в чём?

Главное отличие между мютексом и семафором в том, что у заблокированного мютекса есть задача-владелец. У семафора владельца нет и быть не может.

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

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

С семафором же все совершенно иначе: задача А может семафор ожидать, а задача Б, или даже прерывание, может семафорить. И корректное использование семафоров заключается именно в том, что одна задача (или прерывание) семафорит другой: типа, у меня все готово, теперь ты давай.

Еще раз дам эту ссылку на stackoverflow, где человек чуть подробнее объясняет то же самое: http://stackoverflow.com/a/86021/1099240.


Я уже выше писал, что я всерьез не использовал FreeRTOS, так что не смогу вам ответить. Ну вот товарищ AlexandrY отметил, что в FreeRTOS нет event group connection, а это иногда ну очень удобно. От коллег слышал что FreeRTOS значительно медленнее TNKernel, но сам не проверял.

Сообщение отредактировал dimonomid - Jan 19 2015, 18:51

Ну зачем париться об инверсии если не подводите структуру задач под Rate Monotonic Algorithm ?
Есть там инверсия или нет инверсии вашему софту все равно будет по барабану.
Это же не deadlock, а вполне себе невинная коллизия.

И потом, разве в TNeo мьютекс не будет удален при удалении создавшей его задачи?
Логично ожидать его удаления, а значит мьютексы можно разблокировать и из других задач.
Т.е. принципиальная разница с семафором не такая уж и огромная.

Про то что FreeRTOS значительно медленнее TNKernel думаю, так говорить некорректно; от задачи и окружения зависит, и еще от "прокладки" между монитором и стулом.

Нет, не по барабану. Если вашему софту по барабану, значит, вашим задачам и приоритизация вообще не нужна: сделать все тупо одного приоритета, да и все. У меня же бывают задачи, для которых существуют требования типа "задача X обязана отреагировать на сообщение Y в течение времени Z". Необязательно все прям рассчитывать с точностью до микросекунд, бывает просто эмпирически становится ясно, что определенная задача перестает успевать за естественными требованиями по времени.


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

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


Я устал тратить время на доказывание того, что белое - это белое. Как я уже сказал в самом начале, тот факт, что многие эмбеддеры не хотят понимать разницу между мютексами и семафорами, и используют одно вместо другого - для меня не новость. Можно и саморезы в стену молотком забивать - держаться будут. Так что принципиальная разница между гвоздями и саморезами не такая уж и огромная.

Если есть что-то конкретно по TNeo - с удовольствием отвечу, а если только холивар про использование примитивов синхронизации, то давайте лучше просто займемся своими делами.



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

Если я заморочусь когда-нибудь на подобное сравнение, я напишу. Пока нечего сказать.

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



Т.е. ваш код не отрабатывает аварийные ситуации, пилит и пилит дальше не смотря ни на что?
А у других 90% кода это сплошь обработка аварийных ситуаций знаете-ли, иначе сертификацию не пройдут.




Не будем наделять задачи разумом, а скажем так - при вызове функции уничтожения задачи происходит уничтожение и всех объектов синхронизации которые были привязаны к ней.
Уничтожение задачи можно вызвать и из другой задачи.
Это стандартный подход в развитых RTOS, в MQX в частности.