Перейти к содержанию
    

проблема захватить семафор более приоритетной ниткой

Использую freeRTOS8.2.1

есть мутех за который борются две нитки с разным приоритетом.

слабая нитка стартует и делает много захватов и отпускания мутеха.

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

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

Почему так происходит? как побороть?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Для уменьшения (но не полного исключения) негативного влияния инверсии приоритетов во FreeRTOS реализован механизм наследования приоритетов (Priority Inheritance). Его работа заключается во временном увеличении приоритета низкоприоритетной задачи-владельца мьютекса до уровня приоритета высокоприоритетной задачи, которая в данный момент пытается захватить мьютекс. Когда низкоприоритетная задача освобождает мьютекс, ее приоритет уменьшается до значения, которое было до повышения. Говорят, что низкоприоритетная задача наследует приоритет высокоприоритетной задачи.

Оно?

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

P.S. А в заголовке - семафор. :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так а какой приоритет у задач?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

она может отпустить и тутже захватить мутех снова, а более сильная так и остается в ожидании.

Почему так происходит? как побороть?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо народ что отреагировали!

Уточню задачу чтобы было меньше непоняток что происходит:

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

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

 

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

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

 

что я вижу ныне на осцилографе:

1) запускается запись сильным проценссом - долго она идет

2) в это время прилетает несколько сигнало от прерывания сильной нитке, и она даже активируется.

3) она может удачно хватануть мутекс, и захватить Сдкарту, сделать все дела и уснуть. А может и не хватануть, а долго дожидаться пока слабая нитка не закончит свои дела.

при этом я уверен что в процессе ожидания мутеха, слаба нитка успевает провести неколько операций с СДкартой.

 

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

 

neiver:

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

 

razrab83:

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

 

 

 

P.S. А в заголовке - семафор. :laughing:

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

AlexRayne, Вы прочитали что я Вам процитировал?

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

И причём здесь вообще инверсия приоритетов?

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возможно где то не отдаете семафор-мутекс

возможно у задач приоритет не такой

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

 

возможно приоритет прерывания "выше" чем системный тик

вот этот пасаж я не догнал - что он может означать?

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

 

возможно приоритет прерывания "выше" чем системный тик, возможно в прерывании не хватает portYIELD_FROM_ISR

а каким образом этот елд может помоч переключиться процессу освободившему мутех?

с ловлей сигнала от прерывания проблем не ощущаю - ловится своевременно.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...