Помоги найти мой косяк. Функция Sleep перестает работать. Опции

[a9d]

У меня есть в проекте ошибка. Но я ее не могу отловить, вылетает в разные моменты времени.
Проект показывать смысла нет. Кода дохрена и никто не поймет.

Контролер ATmega8A 16MHz. Всего два процесса.
В какой то момент времени перестает работать правильно функция Sleep(). Т.е Sleep(500) начинает работать как Sleep(1) . При этом ОС работает замечательно.

Вот не могу понять. Что приводит к такому дивному эффекту? Или как эту хрень отловить.

[BAT]

Ну вроде похоже отловил причину. Не знаю как назвать, багом или особенностью Scm.

Что получилось.
Процесс с более высоким приоритетом прерывает ожидающий сообщений из канала. ConsumersProcessMap соответственно указывает, что процесс в ожидании. Далее Высокоприоритетный начинает отрабатываться достаточно долго, чтоб в ожидающем процессе произошел таймаут ожидания сообщения из канала. Ожидающий процесс встал в готовность. Теперь высокоприоритетный доходит до конца выполнения и кладет элемент в очередь сообщений, естественно не обнуляя ConsumersProcessMap (ожидающий процесс уже готов!). Далее управление передается ожидавшему процессу и тут идет проверка на наличие элемента в очереди (а он уже есть!), соответственно ConsumersProcessMap тоже в этом месте не нулится, как при вылетании по таймауту.

Итого:
Теперь если процесс попытается встать на ожидание какого-то другого события и в очередь сообщений придет элемент получится пролет ожидание этого события.

Вот думаю, что делать. Добавить чистку ConsumersProcessMap во время POP из канала? Но получится идеологически неверно влезать в сорцы оси. Но и в своем коде менять принцип не хочется.

[dxp]

Процесс с более высоким приоритетом прерывает ожидающий сообщений из канала. ConsumersProcessMap соответственно указывает, что процесс в ожидании.

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

Вот думаю, что делать. Добавить чистку ConsumersProcessMap во время POP из канала? Но получится идеологически неверно влезать в сорцы оси. Но и в своем коде менять принцип не хочется.

Там в коде в функции pop есть такой фрагмент:

Код

if(pool.get_count())                                                                          
{                                                                                              
    p->Timeout = 0;                                                                            
    item = pool.pop();                                                                        
    CheckWaiters(ProducersProcessMap);                                                        
    return true;                                                                              
}                                                                                              
                                                                                              
if(ConsumersProcessMap & PrioTag)             // waked up by timer when timeout expired        
{                                             // or by OS::ForceWakeUpProcess()                
                                                                                              
    p->Timeout = 0;                           // non-zero if waked up by ForceWakeUpProcess()  
    ClrPrioTag(ConsumersProcessMap, PrioTag); // remove current process from the wait map      
    return false;                                                                              
}

Попробуйте поменять эти два if'а местами - должно порешать вашу проблему. Сейчас готовится новая версия, там как раз такой порядок проверки условий. Заодно узнаем, правильное это решение или нет.

[BAT]

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

Согласен, не так выразился. Не прерывает, а просто просыпается более высокоприоритетный.

По поводу поменять местами. В принципе проблему решит. Правда сначала вывалится с ошибкой таймаута (практически он таки имел место), а при повторном входе сразу выйдет с уже нужным сообщением. Наверное так логичнее, чем сделал. Просто в лоб поставил чистку ConsumersProcessMap.

Код

if(pool.get_count())                                                                          
{                                                                                              
    p->Timeout = 0;                                                                            
    item = pool.pop();                                                                        
    CheckWaiters(ProducersProcessMap);
    ClrPrioTag(ConsumersProcessMap, PrioTag); // remove current process from the wait map                                                      
    return true;                                                                              
}

При таком варианте вываливания с таймаутом не будет, что наверное не совсем корректно.

[dxp]

По поводу поменять местами. В принципе проблему решит. Правда сначала вывалится с ошибкой таймаута (практически он таки имел место), а при повторном входе сразу выйдет с уже нужным сообщением. Наверное так логичнее, чем сделал.

Мы спорили промеж себя, как правильнее - фиксировать ли таймаут, если к моменту получения ожидающим процессом управления таймаут уже истёк. С одной стороны ведь событие произошло - почему бы его сразу не обработать, зачем ждать следующего входа в ожидание события; с другой - заявленный таймаут реально истёк, а уж по какой причине - дело второе. На практике особой разницы (в обозримых случаях) как-то не очень видно - всё это на уровне "гонок". Главное, чтобы событие не терялось.

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

[501-q]

Мы спорили промеж себя, как правильнее - фиксировать ли таймаут, если к моменту получения ожидающим процессом управления таймаут уже истёк. С одной стороны ведь событие произошло - почему бы его сразу не обработать, зачем ждать следующего входа в ожидание события; с другой - заявленный таймаут реально истёк, а уж по какой причине - дело второе. На практике особой разницы (в обозримых случаях) как-то не очень видно - всё это на уровне "гонок". Главное, чтобы событие не терялось.

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

Сначала был таймаут. Поэтому возвращать нужно "таймаут".

Например, окончание телеграммы в модбасе -- по таймату. Если пришёл байт после таймаута -- это уже следующая телеграмма.

Илья

[dxp]

Например, окончание телеграммы в модбасе -- по таймату. Если пришёл байт после таймаута -- это уже следующая телеграмма.

А если пришёл байт (т.е. он первым пришёл, до таймаута), но пока управление передавалось от источника этого события к его обработчику, произошёл таймаут. Как быть? Что считать результатом - событие или таймаут?