Определить причину зависания процесса Опции

[BAT]

Виснут процессы с более низким приоритетом.
При этом более старший процесс спокойно крутится и имеет у себя в цикле ожидание сообщения с таймаутом + Sleep.
Можно как-либо по переменным оси определить, где подвис младший процесс, или куда деваются ресурсы?
Версия оси 3.10.
До этого была 3.05. Но там я наступил на грабли не прохождения сообщений на ожидании с таймаутом, потому перешел на более новую.

[BAT]

про грабли - было следующие

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

Flag or message missed - ID: 2848274
Last Update: Settings changed ( sb-sf )
Details:

Flag or message missed if waiting process timeouted, but new event signaled
before timeouted process gets control.

Обновил. Проблема ушла.

По поводу текущей проблемы. Есть какие-нибудь ограничения на использования channel
в обработчике прерывания? Обработчик оформлен по всем правилам работы с осью.

Работаю с AT91Sam7x512 из под IAR 5.30

[dxp]

Обновил. Проблема ушла.

Это давнишняя вещь, просто релиз давно не выпускали. А в репозитории оно давно лежит.

По поводу текущей проблемы. Есть какие-нибудь ограничения на использования channel
в обработчике прерывания? Обработчик оформлен по всем правилам работы с осью.

Основное и главное ограничение - надо следить, чтобы не возникло ситуации, когда при записи в канал там не оказалось для этого места (или при чтении оказалось нечего читать). Если места не окажется, то канал попытается перевести процесс в ожидание, а в прерывании этого делать нельзя... Вот цитата из доки на эту тему (стр 77):

При использовании сервисов в прерываниях есть определенные особенности. Например, очевидно, что использовать TMutex::Lock() внутри обработчика прерывания является достаточно плохой идеей, т.к., во-первых, мутексы предназначены для разделения доступа к ресурсам на уровне процессов, а не на уровне прерываний, и, во-вторых, ожидать освобождения ресурса, если он был занят, внутри обработчика прерывания все равно не удастся и это приведет только к тому, что процесс, прерванный данным прерыванием, просто будет переведен состояние ожидания в неподходящей и непредсказуемой точке. Фактически процесс будет переведен в неактивное состояние, из которого его вывести можно будет только с помощью функции ForceWakeUpProcess. В любом случае ничего хорошего из этого не получится.

Аналогичная в некотором роде ситуация может получиться при использовании объектов-каналов в обработчике прерываний. Ждать данных из канала
внутри ISR не получится и последствия будут аналогичны вышеописанным, а записывать данные в канал тоже не вполне безопасно. Если, к примеру, при записи в канал в нем не окажется достаточно места, то поведение программы окажется далеко не таким, как ожидает пользователь.