Aner, фриртос действительно тормознее других переключалок. в некоторых моментах - существенно. после одного из таких сравнений задали вопрос автору. в итоге в лицензии фриртос появился пункт запрещающий её сравнивать с другими )))

Уж конечно я не измерял, т.к. для блокировки ресурсов всегда сразу использую корректный объект синхронизации (мютекс), но назовите мне причину, по которой я должен оставлять потенциальную возможность инверсии приоритетов?



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

И приведите пожалуйста примеры, когда вы используете удаление задачи в качестве разрешения нештатной ситуации?




Единственный объект синхронизации, привязанный к задаче - мютекс. Например, выделенная из TN_FMem или вообще из кучи память никак не привязывается к задаче (т.к. память легко может быть выделена в одной задаче, а освобождена в другой), так что удаление задачи, выделяющей память динамически, может привести к утечке памяти. Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете.

Спасибо! Будем смотреть.
А тесты в открытом доступе имеются?

Добавлено: Нашел в документации, отдельный репозиторий (:

Сообщение отредактировал Valentine Loginov - Jan 20 2015, 08:09

В доке на странице "Unit tests" в конце указано, где взять тесты: http://dfrank.bitbucket.org/tneokernel_api...unit_tests.html

кроме bla-bla-bla пример тормознутости в студию!

Да, многие не используют динамическое распределение памяти в embedded системах. Одна из холиварных тем. Но кучи в системах высокой ответственности - однозначное зло.

Сообщение отредактировал LightElf - Jan 20 2015, 09:49

Куча - согласен, зло, т.к. поведение недетерминировано. Но кроме кучи есть другие инструменты для динамического распределения памяти - например, TN_FMem (и аналоги в других ядрах). Это - не зло

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

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



Во первых половину задач я создаю динамически. Их цель выполнить операцию и прекратить свое существование.
Например дали команду с клавиатуры сложному механизму выполнить определенное движение.
На запуск движения (еще не на само движение) создается задача.
Движение сложного механизма сопряжено с выполнение многих подготовительных действий.
Это управление элементами индикации: лампочки, бузера; включение или выключение каких-то соленоидов, активация вспомогательных приводов и проч. и проч.
И вот если какая либо из этих мелочей по ходу не сработает или не даст подтверждения происходит аварийная выгрузка задачи. В MQX это будет просто команда return errorcode. И все!
Все мьютексы, семафоры, флаги, блоки памяти занятые этой задачей будут освобождены автоматически. Никаких хлопот.





Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так.

Кстати советую подумать зачем мьютексы нужны в Windows если это не система реального времени и на инверсию приоритетов... ну она там точно не важна.

померло за давностью лет. нашлась только ссылка на обсуждение http://www.microchip.com/forums/m279201.aspx
там есть а пара картинок, где виден слив, и приходит сам автор фриртоса, который заявил что вы неправильно тестите, но "правильных" результатов так и не показал.

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

а потолок "развитости" есть? и потребляемых вместе с этой развитостью ресурсов

Да блин 2007 год, крутое обсуждения незнамо чего. И по вашему с той поры Free RTOS просто замёрз и не разу не менялся и новых версий никто не видел. Так шта все это бла-бла-бла.

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


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

Но я наверное слишком идеалист для эмбеддерства и вообще не прав.


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

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

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

Шизу про догнал развивать не стоит. Я о тормозах и сравнении то о чем писали. Ссылка ни как не убедила. Возможно это еще и от арх проца зависит. Я от Микрочипа отошел давно в сторону Кортексов. Быстрее писать, отлаживать, дешевле стоит, меньше затрат, удобнее. Хотя кто как привык. TNeo возможно востребованее будет на пиках, и арх проца не последнне дело в этой оси.

Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей.
Зачем задачам которые должны абстрагироваться от аппаратуры лазить в SPI, разбираться с адресами , данными?
Это означает подкладывание под свой софт мины межплатформенной несовместимости.
Если на такую архитектуру софта рассчитана ваша RTOS, то я конечно дальше обсуждать не буду.

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

Nucleus Plus стоит на 3-х миллиардах дивайсов и не имеет мьютексов. Это должно кое о чем говорить.