"Stefan Sommerfeld" <[EMAIL PROTECTED]> 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.
