реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> проблема захватить семафор более приоритетной ниткой, слабая нитка не уступает процессор более сильной
AlexRayne
сообщение May 18 2017, 13:02
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 258
Регистрация: 27-09-07
Пользователь №: 30 877



Использую freeRTOS8.2.1
есть мутех за который борются две нитки с разным приоритетом.
слабая нитка стартует и делает много захватов и отпускания мутеха.
пока она работает, в более сильную нитку приходит событие, и она пытается захватить мутех.
но такое ощущение что слабая нитка както не очень хочет уступить более сильной процессор - она может отпустить и тутже захватить мутех снова, а более сильная так и остается в ожидании.
Почему так происходит? как побороть?
Go to the top of the page
 
+Quote Post
Ruslan1
сообщение May 18 2017, 14:57
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 2 217
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025



из документации (Андрей Курниц, КОМПОНЕНТЫ И ТЕХНОЛОГИИ • № 8 '2011, "Проблемы при использовании мьютексов"):
Цитата
Для уменьшения (но не полного исключения) негативного влияния инверсии приоритетов во FreeRTOS реализован механизм наследования приоритетов (Priority Inheritance). Его работа заключается во временном увеличении приоритета низкоприоритетной задачи-владельца мьютекса до уровня приоритета высокоприоритетной задачи, которая в данный момент пытается захватить мьютекс. Когда низкоприоритетная задача освобождает мьютекс, ее приоритет уменьшается до значения, которое было до повышения. Говорят, что низкоприоритетная задача наследует приоритет высокоприоритетной задачи.

Оно?


(P.S. Привет Форуму! давно даже почитать не заходил не то что пописать....)
Go to the top of the page
 
+Quote Post
ViKo
сообщение May 18 2017, 15:06
Сообщение #3


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 7 435
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Не знаком с FreeRTOS. Однако, как я представляю (читал документацию на другие ОС), мьютекс определяет доступ к некоей уникальной (аппаратной, например) части. И ему без разницы, какого приоритета задача его использует. Взяли, значит, взяли. Отдали - свободен.
P.S. А в заголовке - семафор. laughing.gif
Go to the top of the page
 
+Quote Post
Lagman
сообщение May 18 2017, 16:57
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 797
Регистрация: 28-10-05
Пользователь №: 10 245



Так а какой приоритет у задач?
Кажется во FreeRTOS у самой высокоприоритетной задачи приоритет ставится в (configMAX_PRIORITIES -1) а у самого низкого приоритета tskIDLE_PRIORITY который равен 0. http://www.freertos.org/RTOS-task-priority.html
Go to the top of the page
 
+Quote Post
razrab83
сообщение May 19 2017, 05:01
Сообщение #5





Группа: Новичок
Сообщений: 4
Регистрация: 5-05-17
Пользователь №: 96 902



Цитата(AlexRayne @ May 18 2017, 14:02) *
она может отпустить и тутже захватить мутех снова, а более сильная так и остается в ожидании.
Почему так происходит? как побороть?

а при отпускании мьютекса вызывается планировщик? Если нет, то планировщик вызывается в системные тики, и при принудительном вызове (например в прерывании). Возможна ситуация, когда между 2 тиками слабая нитка отпускает мьютекс и тут же захватывает. Т.к. планировщик не вызывается, то переключение на приоритетную задачу не происходит.
Go to the top of the page
 
+Quote Post
neiver
сообщение May 19 2017, 09:04
Сообщение #6


Местный
***

Группа: Участник
Сообщений: 214
Регистрация: 22-03-10
Из: Саратов
Пользователь №: 56 123



Гуглить "инверсия приоритетов freertos".
Go to the top of the page
 
+Quote Post
AlexRayne
сообщение May 19 2017, 17:36
Сообщение #7


Местный
***

Группа: Участник
Сообщений: 258
Регистрация: 27-09-07
Пользователь №: 30 877



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

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

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

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

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

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



Цитата(ViKo @ May 18 2017, 19:06) *
P.S. А в заголовке - семафор. laughing.gif

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

А с семаформаи такая подляна бывает, или они бодрее реагируют?
Go to the top of the page
 
+Quote Post
Lagman
сообщение May 19 2017, 19:45
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 797
Регистрация: 28-10-05
Пользователь №: 10 245



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

Сделайте у задач одинаковый приоритет и посмотрите что получится, вставить в низкоприоритетной задаче vTaskDelay на несколько тиков после того как отдаете мутекс, может freertos не успевает понизить приоритет во время перехода мутекса.
Go to the top of the page
 
+Quote Post
Ruslan1
сообщение May 19 2017, 20:57
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 2 217
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025



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

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

Конкретно про SD-карту: Вы чем пользуетесь? Если FatFs - то там уже решено, множественный доступ под FreeRTOS работает без дополнительных мютексов и семафоров.
Go to the top of the page
 
+Quote Post
sonycman
сообщение May 20 2017, 09:21
Сообщение #10


Любитель
*****

Группа: Свой
Сообщений: 1 838
Регистрация: 20-08-06
Из: Тольятти
Пользователь №: 19 695



Цитата(Ruslan1 @ May 20 2017, 00:57) *
Система временно увеличивает приоритет низкоприоритетной задачи-владельца мьютекса до уровня приоритета высокоприоритетной задачи, которая в данный момент пытается захватить мьютекс.
Поэтому задача, которую Вы считаете слабой, во время владения становится такой же сильной как и та, которую Вы считаете более сильной.

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

У автора просто где-то ошибка в организации вызовов ОС, раз планировщик вызывается только в прерывании таймера.
Go to the top of the page
 
+Quote Post
AlexRayne
сообщение May 20 2017, 10:08
Сообщение #11


Местный
***

Группа: Участник
Сообщений: 258
Регистрация: 27-09-07
Пользователь №: 30 877



Цитата(Lagman @ May 19 2017, 22:45) *
Возможно где то не отдаете семафор-мутекс
возможно у задач приоритет не такой

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

Цитата(Lagman @ May 19 2017, 22:45) *
возможно приоритет прерывания "выше" чем системный тик

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

Цитата(Lagman @ May 19 2017, 22:45) *
возможно приоритет прерывания "выше" чем системный тик, возможно в прерывании не хватает portYIELD_FROM_ISR

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

Цитата(Lagman @ May 19 2017, 22:45) *
Сделайте у задач одинаковый приоритет и посмотрите что получится, вставить в низкоприоритетной задаче vTaskDelay на несколько тиков после того как отдаете мутекс, может freertos не успевает понизить приоритет во время перехода мутекса.

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

Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 20th July 2017 - 12:36
Рейтинг@Mail.ru


Страница сгенерированна за 0.01434 секунд с 7
ELECTRONIX ©2004-2016