Re: FIFO DSRs... the 2nd

[Sergei Organov <osv at javad dot com>]

"Stefan Sommerfeld" <sommerfeld@mikrom.de> writes:
> Hi Sergei,
[...]
> Yes, you're right .... i overlooked this count. So it's correct to
> clear the dsr_list pointers.

I'm glad we finally agree on that. I did try to program it as carefully
as I can indeed. My initial goal for the optimization was to get rid of
excessive ISR disable/enable invocation compared to the LIFO case, and
then I realized that I can get rid of a few volatile fetches and the
comparison inside the loop.

> Still one thing. If a new dsr is enqueued while your process the
> dsr's, the new dsr will not be processed. This may cause a longer irq
> to dsr delay. Maybe a check for new dsrs should be made before leaving
> the loop.

Well, I thought about it too and my feeling is that this won't
noticeably decrease maximum ISR-to-DSR latency as IRQ could still occur
just after you check again, only the probability is less. External code
will check/invoke the DSRs pretty soon anyway. On the other hand, it
adds yet another volatile variable fetch and subsequent check-and-branch
to *every* invocation of the routine most of which will handle single
DSR on a reasonably behaving system. Taking the above into account I
can't actually decide what is better, so I left it to be as simple as
possible for now. Somebody who is interested in actual profiling of this
thing is free to check and change it later.

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.

Overall, I'm highly confident the patch is OK, but as any change it
cries for as much testing as possible.

-- Sergei.