This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FIFO DSRs... the 2nd


Hi Stefan,

"Stefan Sommerfeld" <sommerfeld@mikrom.de> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]