How to mask IRQ

[leonp at plris.com]

On Tuesday, 31 בMay 2005 14:34, Sergei Organov wrote:
> So, what do you think is the meaning of "RT" in "RTEMS"? ;) IMHO, one of
> the purposes of RTOS is to make it possible to design RT systems without
> huge, ugly, multi-level, multi-priority interrupt handlers mess. The
> design of any RTOS and RTEMS in particular is centered around the idea
> of having fast small interrupt handlers and threads doing most of actual
> work.
>
> I do program actual production RT systems. My experience is that context
> switch overhead is not that high for most cases, and where it is, one
> could enable interrupts in those interrupt handlers that do take too
> much time to execute. For example, in the system I program, only one IRQ
> handler enables interrupts (and FPU) during its work. All others either
> do their work quick enough (e.g., RS232 handlers that just copy a few
> bytes between hardware and software buffers), or delegate their actual
> work to threads level (e.g., Ethernet, USB, etc.).
>
> IMHO, the rule of thumb is: do minimum amount of work required to manage
> hardware in ISRs. Do everything else at tasks level. Consider doing
> other work in ISR only if measurements tell the task switch overhead
> does matter. Consider enabling interrupts in the ISR handler if
> measurements show it takes too much time to be executed at interrupts
> disabled.
>
> Besides, I wonder how many times did you indeed measure the overhead to
> make sure it's too high for particular case? If a piece of code is so
> short that context switch overhead is significant relative to it, it
> well could be executed from ISR, and maybe even without enabling
> interrupts.
>
> Overall, the solution I advocate gives programmer opportunity to build
> his system in the most optimal way instead of forcing him to use "one
> true approach".
Well, all above is absolutely correct and incorrect, IMHO.
As a general recommendation theory, it is more than correct.
But practice is always more complicated than theory. And there are different 
situation, where context switch time becomes significant factor.
As an example, our data recording system needs to acquire upto 12 fast input 
channels, while acquired messages must be time stamped with high accuracy.
Obviously, the faster the channel the more time stamp error is 
significant...:-))

Summarizing my opinion, I think this will be great to have two (enough?) 
interrupts processing models - one existing (Eric - thanks!) and one Sergei 
talks about, but how to implement this?

-- 
Leon M.Pollak