[Mahagam 0]

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

[dimonomid 0]

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

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

 

 

Т.е. ваш код не отрабатывает аварийные ситуации, пилит и пилитдальше не смотря ни на что?

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

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

 

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

 

 

 

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

Уничтожение задачи можно вызвать и из другой задачи.

Это стандартный подход в развитых RTOS, в MQX в частности.

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

 

[becopt 0]

Спасибо! Будем смотреть.

А тесты в открытом доступе имеются?

 

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

Изменено 20 января, 2015 пользователем Valentine Loginov

[dimonomid 0]

А тесты в открытом доступе имеются?

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

[Aner 3]

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

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

[LightElf 0]

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

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

Изменено 20 января, 2015 пользователем LightElf

[dimonomid 0]

Но кучи в системах высокой ответственности - однозначное зло. :maniac:

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

[AlexandrY 2]

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

 

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

А по сути именно это происходит при захвате мьютекса самой низкоприоритетной задачей.

Тогда вопрос - почему она была сделана низкоприоритетной?

 

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

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

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

 

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

 

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

 

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

Например дали команду с клавиатуры сложному механизму выполнить определенное движение.

На запуск движения (еще не на само движение) создается задача.

Движение сложного механизма сопряжено с выполнение многих подготовительных действий.

Это управление элементами индикации: лампочки, бузера; включение или выключение каких-то соленоидов, активация вспомогательных приводов и проч. и проч.

И вот если какая либо из этих мелочей по ходу не сработает или не даст подтверждения происходит аварийная выгрузка задачи. В MQX это будет просто команда return errorcode. И все!

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

 

 

 

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

 

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

 

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

[Mahagam 0]

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

 

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

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

 

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

[den_po 0]

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

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

[Aner 3]

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

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

 

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

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

[dimonomid 0]

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

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

Когда это разумно, конечно я использую критические секции.

 

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

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

 

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

 

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

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

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

 

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

 

[Mahagam 0]

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

пока в лицензии на фриртос есть строка о запрете сравнения - фриртос можно считать тормознутым.

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

[Aner 3]

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

[AlexandrY 2]

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

Когда это разумно, конечно я использую критические секции.

 

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

 

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

 

Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей.

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

Это означает подкладывание под свой софт мины межплатформенной несовместимости.

Если на такую архитектуру софта рассчитана ваша RTOS, то я конечно дальше обсуждать не буду.

 

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

 

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