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

из документации (Андрей Курниц, КОМПОНЕНТЫ И ТЕХНОЛОГИИ • № 8 '2011, "Проблемы при использовании мьютексов"):

Оно?


(P.S. Привет Форуму! давно даже почитать не заходил не то что пописать....)

Не знаком с FreeRTOS. Однако, как я представляю (читал документацию на другие ОС), мьютекс определяет доступ к некоей уникальной (аппаратной, например) части. И ему без разницы, какого приоритета задача его использует. Взяли, значит, взяли. Отдали - свободен.
P.S. А в заголовке - семафор.

Так а какой приоритет у задач?
Кажется во FreeRTOS у самой высокоприоритетной задачи приоритет ставится в (configMAX_PRIORITIES -1) а у самого низкого приоритета tskIDLE_PRIORITY который равен 0. http://www.freertos.org/RTOS-task-priority.html

а при отпускании мьютекса вызывается планировщик? Если нет, то планировщик вызывается в системные тики, и при принудительном вызове (например в прерывании). Возможна ситуация, когда между 2 тиками слабая нитка отпускает мьютекс и тут же захватывает. Т.к. планировщик не вызывается, то переключение на приоритетную задачу не происходит.

Гуглить "инверсия приоритетов freertos".

Спасибо народ что отреагировали!
Уточню задачу чтобы было меньше непоняток что происходит:
есть процесс который - слабый - который регулярно пишет много секторов на Сдкарту.
есть сильный процесс (больше приоритет) - который с этой же карты должен срочно считать несколько секторов после того как из прерывания придет сообщение - ЦАП все проиграл, давай больше данных.

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

что я вижу ныне на осцилографе:
1) запускается запись сильным проценссом - долго она идет
2) в это время прилетает несколько сигнало от прерывания сильной нитке, и она даже активируется.
3) она может удачно хватануть мутекс, и захватить Сдкарту, сделать все дела и уснуть. А может и не хватануть, а долго дожидаться пока слабая нитка не закончит свои дела.
при этом я уверен что в процессе ожидания мутеха, слаба нитка успевает провести неколько операций с СДкартой.

пока что заборол мою беду тем что сделал больше буфер в сильном процессе.

neiver:
Инверсия приоритетов - имхо тут не причем, она помогает ускорить слабый процесс, но при конкуренции за мутекс она причем?

razrab83:
при отпускании мутеха вполне надежно вызывается yield, может он и не хочет переключать. но отловить ситуацию которая меня интересует в отладчике сложно. надо както выловить момент когда конкурируют 2 независимых процесса. надо тестбенч чтоли какойто делать.




А исправить загогловок можно?

А с семаформаи такая подляна бывает, или они бодрее реагируют?

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

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

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

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

Конкретно про SD-карту: Вы чем пользуетесь? Если FatFs - то там уже решено, множественный доступ под FreeRTOS работает без дополнительных мютексов и семафоров.

И причём здесь вообще инверсия приоритетов?
При освобождении мьютекса приоритет в любом случае возвращается к исходному - низкому - и ресурс должен быть захвачен более высокоприоритетным процессом.

У автора просто где-то ошибка в организации вызовов ОС, раз планировщик вызывается только в прерывании таймера.

это было проверено первым


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


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


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