Re: [ECOS] Multiple Inheritance used in eCos class Cyg_Thread

[Nick Garnett <nickg at ecoscentric dot com>]

"Fabian Scheler" <fabian.scheler@gmail.com> writes:

> > I was hesitant to raise this subject, but I am delighted to see the
> > discussion that has grown out of my initial query.  Discussions such as
> > this can only serve to make eCos a more reliable and relevant real-time
> > operating system in embedded system development.
> 
> Another issue that would have to be addressed to improve the real-time
> capabilities of eCos is the execution order off dsrs, as these are
> just executed in the order of their activation (or the reversed
> order?). In an event-triggered system, this might lead to hard to
> predict or hard to estimate delays of high priority events as they are
> normally mapped to interrupts, ie. isrs/dsrs.

This is not an issue if DSRs are used properly. For a start, any
prioritizable processing should be done in threads. That is what they
are there for. DSRs exist to interface between ISRs and
threads. Consequently they should only contain a few lines of code,
just a call to signal a condition variable or a semaphore, nothing
more.

If we prioritize DSRs we need to consider what priority space they
should occupy. There seem to be two options: hardware interrupt
priorities or thread priorities. The patch to make DSRs execute in
activation order means that they now track interrupt priorities fairly
closely, any extra code here would be a lot of work to very little
effect.

DSRs are not preemptable, and currently all pending DSRs must run to
completion before any thread gets to execute. So as far as worst case
thread response time is concerned, prioritizing DSRs amongst
themselves will have no effect. So the only alternative approach would
be to prioritize DSRs in the same space as threads so that only DSRs
of equal or higher priority than the current thread would be allowed
to execute.

However, this approach still doesn't allow DSRs to be preempted, and
would introduce a whole range of other issues regarding priority
inversion and DSR starvation. Threads are preemptable and
prioritizable, and any code that needs those sorts of properties
should go into threads. We should not try to add those properties to
DSRs.


On a philosophical note, I am beginning to wonder whether it was a
mistake to expose a functional interface to the DSR mechanism, since
it tempts people to write code in them. In hindsight the interface
should have been a simple signal a condition variable/semaphore
operation. I think things would have been much simpler.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


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