ARM, RISC-V контроллеры

Да, похоже это баг. Внесите его в багтрекер, чтобы не забылся. Счас сам занесу. Argon, вы можете проверить этот код, чтобы внести исправление? У меня сейчас нет возможности провести полноценное тестирование :( http://sourceforge.net/tracker/?group_id=181958&atid=899286
Сейчас смотрю в свой исходник - у меня организовано несколько иначе, что-то вроде такого: bool OS::TEventFlag::Wait(TTimeout timeout) { TCritSect cs; if(Value == efOn) { Value = efOff; return true; } else { TBaseProcess* p = Kernel.ProcessTable[Kernel.CurProcPriority]; p->Timeout = timeout; TProcessMap PrioTag = GetPrioTag(Kernel.CurProcPriority); for(;;) { TProcessMap PrioTag = GetPrioTag(Kernel.CurProcPriority); SetPrioTag(ProcessMap, PrioTag); // put current process to wait map ClrPrioTag(Kernel.ReadyProcessMap, PrioTag); // remove current process from ready map Kernel.Scheduler(); ClrPrioTag(ProcessMap, PrioTag); // remove current process from wait list if( Value == efOn) { p->Timeout = 0; Value = efOff; return true; } if(p->Timeout == 0) return false; } } }Объясняется это следующим - если два процесса ждут одного флага, то по сигналу активными становятся оба, при этом управление получает более приоритетный, он сбрасывает флаг, а когда управление получает второй - флаг сброшен, но таймаут еще мог не истечь, поэтому его надо снова отправить в ожидание следующего сигнала.