Hi Stefan, "Stefan Sommerfeld" <[EMAIL PROTECTED]> writes: > Hi Sergei, >> [...] [...] >> In fact one fundamental change w.r.t other algorithms is that the list >> is not checked for emptiness on entry to the DSR invocation routine, but >> the outside logic suggests it is never called with empty list, and the >> assert that I've put at the beginning has never fired for me. > > I only fear a dsr could not be runned until the next irq or scheduler > lock happened. This would produce sometimes unpredictable > delays.
No, it's impossible as outer code that calls us handles this race nicely. This race exists for any of the 3 algorithms and it can't be entirely handled here, -- only its probability could be decreased. Think about ISR happening just after you enable interrupts the last time before returning. Instead, this race is indeed handled in the calling code, see Cyg_Scheduler::unlock_inner(). > Maybe we could add a check for the dsr_list entry if a zero was read > out of the next pointer of the irq. The irqs are locked at this time. We could, but fortunately there is no need to, as calling code does it anyway, so you will get delay for a few asm instructions, not to the next scheduler lock/unlock. > >> Overall, I'm highly confident the patch is OK, but as any change it >> cries for as much testing as possible. > > I'll start testing it next week. That would be great! My system (ARM target) runs for about five days with the patch applied, but more testing is always welcome, especially on different target(s) as there is still some chance there are subtle target dependencies. -- Sergei.
