[ECOS] Multiple runnable DSR's

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Of course we have already written distinctly non-trivial DSRs
> ourselves, so we can hardly be said to be practising what we're
> preaching :-).

*I* haven't written DSRs that exceed the design spec. I'll refrain
 from pointing fingers at the guilty parties :-)

> 
> Perhaps it may not be unreasonable to have a default disabled
> configuration option which sorts DSRs according to the priority used
> on interrupt creation as they are inserted (for
> CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST only). It would be pretty simple,
> and would silence those who think it does matter what order they run
> in :-).[1]

Doing that would make posting DSRs non-deterministic. That's even
worse than running them in the wrong order.

However, as I said before, all DSRs have to run before any thread can,
so the exact order they run it does not matter. To properly reflect
the prioritization of interrupts we would have to implement DSR
preemption and nest execution of higher priority DSRs within lower
ones. However, this would violate the scheduler locking model which
allows only one thread or one DSR to be executing at any time.

In any case, if DSRs are to be prioritized they should be prioritized
in the same space as the threads. When a given thread is scheduled to
run then only DSRs of equal or higher priority should be allowed to
execute. This gets complex, however, when a DSR causes another higher
priority thread to be scheduled. We then need to reasses which DSRs
should be allowed to run -- something we have to do after each DSR
runs: another source of non-determinism. Also what happens when a low
priority DSR starts a high priority thread, should any of the DSRs
between those priorities have been run? We now have a form of priority
inversion. So maybe there has to be some linkage between the DSR
priority and the priorities of any threads it is allowed to schedule.

As you see, once you start down this route it all gets horribly
complicated. To eliminate all sources of priority inversion is a tough
thing to do, and would require a total rewrite of the entire kernel.

As I keep on saying, thread are the correct place to do significant
prioritized execution since that's where we can handle priority
inversion and synchronization properly. We don't want to duplicate the
same mechanisms elsewhere.

> 
> Jifl
> [1] Actually you can see their point in the existing system where DSRs
> do do real work, like the serial or net drivers. That we don't do that
> quite right of course is why the high-minded principles fall down.

Actually the ethernet drivers are a good example of how things should
be done. The DSRs are relatively small and simple, all the hard work
is offloaded to the netisr thread.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss