"Fabian Scheler" <[EMAIL PROTECTED]> 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
