dimonomid

Хм. Насчет мютексов примерно ясно: действительно, можно запрещать только планировщик, а не все прерывания, т.к. мютексы в прерываниях не используются. Ок, но как, например, с таймерами? Если запущено много таймеров, то эту очередь надо как-то обслуживать, и чем больше таймеров в очереди, тем больше времени это занимает. Ладно, спасибо за инфу, когда будет время, попробую разобраться. :)

Вам нужен AVIX тогда. :) http://avix-rt.com/ Она никогда не запрещает прерывания, вообще. Но денег стоит.

Мда, поторопился я ответить. :) Прямой зависимости от количества задач нет, но, действительно, критические секции добавляют задержку: если говорить про мютексы, то чем больше задач одновременно ожидают мютекс, тем больше времени требуется, чтобы определить приоритет той задачи, которая захватила этот мютекс. Вы правы. Другое дело, что на некоторых платформах (пока только dsPIC/PIC24) есть возможность запрещать в критических секциях не все прерывания, а только определенный диапазон приоритетов прерываний. Но тогда из остальных прерываний нельзя вызывать сервисы ядра.

Как в FreeRTOS - не знаю, а в TNeo, как и в TNKernel, количество задач не влияет на скорость переключения контекста: для каждого приоритета есть связанный список задач, готовых к запуску. И есть битовая маска, каждый бит которой отражает приоритет, в котором есть готовые к запуску задачи. Таким образом, когда ядро выясняет, какую задачу нужно запустить, оно делает следующее: - Находит номер младшего установленного бита в маске. Некоторые архитектуры имеют специальную инструкцию для этой операции (Find first set). Если такой инструкции нет, то приходится вручную проверять каждый бит, но тогда время выполнения зависит не от количества задач, а от количества приоритетов. - Передает управление первой задаче из связанного списка для соответствующего приоритета. Время константное. От количества задач эта задержка тоже не зависит.

Так, отставить, я ерунду написал в прошлом сообщении: для TNeo-то я взял существующий настроенный проект, а для FreeRTOS создал новый, и забыл в нем оптимизацию включить. Пардон. Так что отличия поскромнее: В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека), в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека).

Насчет FreeRTOS: Ради интереса, таки провел сравнение, вопреки лицензии FreeRTOS. Пример простейший: две задачи: А (высокоприоритетная) и B (низкоприоритетная). А ждет семафора, B через определенный интервал сигналит семафором. Т.к. А высокоприоритетная, то как только B сигналит семафором, управление передается задаче А. Измерял время от момента вызова сервиса сигнализирования из задачи B до получения управления задачей А. В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека), в FreeRTOS: 1215 тиков (1075 с отключенной проверкой переполнения стека). UPD: в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека). Я по запаре накосячил с измерениями первый раз, см. след. сообщение. Измерения производились на PIC32MX с помощью stopwatch в MPLABX. TNeo: volatile int i; /* * Low-priority task (2). The lower value, the higher priority. */ void task_b_body(void *par) { for(;;) { tn_task_sleep(10); i = 0; //-- stopwatch start tn_sem_signal(&sem); } } /* * High-priority task (1). The lower value, the higher priority. */ void task_a_body(void *par) { for(;;) { tn_sem_wait(&sem, TN_WAIT_INFINITE); i = 1; //-- stopwatch stop: 624 cycles (594 without stack overflow check) } } FreeRTOS: volatile int i; /* * Low-priority task (tskIDLE_PRIORITY + 1) */ void prvTaskB (void* pvParameters) { for (;;) { vTaskDelay(10); i = 1; //-- stopwatch start xSemaphoreGive( mySem ); } } /* * High-priority task (tskIDLE_PRIORITY + 2) */ void prvTaskA (void* pvParameters) { for (;;) { xSemaphoreTake( mySem, portMAX_DELAY ); i = 0; //-- stopwatch stop: 863 cycles (624 without stack overflow check) } }

Нет особых причин, соберите новым компилятором, проблем быть не должно.

Вы меня совершенно неправильно поняли. Где именно я так неясно выразился? Конечно, мютекс принадлежит той задаче, которая его захватила. Когда задача его разблокирует, он снова ничей. А семафор ничей даже когда задача его "захватила" (в кавычках - потому что некорректный термин для семафора). И в этом главное отличие семафоров от мютексов. Когда задача А заблокировала мютекс, задача Б не может его разблокировать. Когда задача А "заблокировала" семафор, задача Б (или даже прерывание) может его "разблокировать". Не знаю как у Кейла, может, и не так. Это не новость, что эти термины постоянно путаются, к сожалению. Ну еще раз дам ссылку на статью: Mutexes and Semaphores Demystified, почитайте там хотя бы The Myth: Mutexes and semaphores are similar or even interchangeable, а также The History of Semaphores and Mutexes.

Согласен: иногда, действительно, задача удобнее мютексов. А иногда наоборот. Я где-то противоречил этому?

На вскидку: Отдельная задача - в контексте вытесняющей РТОС это означает, как минимум, выделение в RAM отдельного стека для нее, и двойное переключение контекста каждый раз, когда нам нужно выполнить какие-то действия (если вернуться к тому же примеру, то речь идет о действиях с SPI). 1) Задача требует значительно большего кол-ва RAM. Например, на MIPS минимально необходимый размер стека - 36 слов (144 байта), это если задача вообще ничего делать не будет, только крутиться в цикле. Соответственно, чтобы она делала что-то полезное, этот размер стека еще значительно увеличится, раза в два легко - т.е. около 300 байт если без жира. Плюс еще нужна память для структуры очереди сообщений, и буфер для этой очереди. Еще минимум 50 байт, это если буфер совсем маленький. Мютекс занимает в RAM 36 байт - грубо говоря, в 10 раз меньше. Если на каждый ресурс лепить отдельную задачу - RAM кончается слишком быстро. Если у вас полмегабайта RAM - ерунда конечно, но в моих embedded-проектах на камне никогда не было больше 32К RAM. 2) Оверхед по времени выше: любое использование SPI ведет, как минимум, к двойному переключению контекста. Например, рассмотрим последовательность действий, когда шина SPI свободна. Отправляем сообщение из задачи А в задачу SPI, которая свободна (ждет сообщений) : * отправляем сообщение из A в SPI, * сохраняем контекст (32 слова для MIPS) в стек задачи А, * восстанавливаем контекст задачи SPI, * задача SPI принимает сообщение и делает свою работу, * сохраняем весь контекст в стек задачи SPI, * восстанавливаем контекст задачи А. В случае с мютексом, действий нужно гораздо меньше: * блокируем мютекс, * модуль SPI делает свою работу, * разблокируем мютекс. Так что использование мютекса работает несколько быстрее и требует значительно меньше RAM. Плюс еще можно упомянуть, что их использовать проще, чем городить отдельную задачу, набор команд для нее, очередь сообщений. Поэтому, как правило, я использую мютексы. Если такое решение меня не устраивает по каким-то причинам, то тогда уже использую отдельную задачу. А в чем именно заключается нефункциональность? А, _Pasha, то есть вы никогда не используете РТОС, правильно? Класс, я ждал, пока кто-нибудь отпишется, спасибо. Вот видите, AlexandrY, есть тут люди, которые пишут без РТОС! :) Ждем человека, который пишет исключительно на асме.

Подходящие или неподходящие - это значит, что в одной ситуации отдельная задача на ресурс (типа вот "менеджер SPI шины") окажется более удачным решением, чем использование мютекса, а в другой ситуации - наоборот, мютекс будет более удачным решением. Вы же говорите об отдельной задаче как о панацее, а о мютексах как о безусловном зле. В TNeo, как и в TNKernel, вы можете применять любое решение: и мютекс, и отдельную задачу. И даже семафор, если вам очень хочется использовать его для блокировки ресурсов. Так что не совсем понятно, что вы имеете в виду под "TNeo более похожа на неподходящие решение".

Не плохие и хорошие, а подходящие или не подходящие для решения конкретной задачи.

Ничего не имею против такого подхода, и я уже писал об этом. Процитирую сам себя: Можно, конечно, на каждый ресурс делать задачу и слать ей сообщения. Иногда это разумно, иногда разумнее использовать мютекс. Панацеи нет. Конечно не есть необходимость, как я уже говорил, можно и без мютексов все написать, а можно и без РТОС. Дискуссия выходит на второй круг.

Совсем необязательно задачам, которым нужно так или иначе что-то прочитать из флеши, самостоятельно "разбираться с адресами, данными". К железу привязан только bsp-layer (board support package). Задача обычно вызывает функции далеко абстрагированного от железа модуля, который, прямо или косвенно, в итоге читает из флеши то, что ему нужно. И расскажите, как здесь правильно пользоваться сервисами очередей. Подобные аргументы говорят в первую очередь о хорошем маркетинге. Я не работал с Nucleus и поэтому о ней самой ничего не скажу, но аргумент типа количества установок говорит о маркетинге. Как следствие, конечно, большое сообщество и т.д. В ThreadX есть мютексы и она стоит на миллиарде девайсов (как у них на сайте указано), ну и что.

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