Re: why should ISR arrange that the same interrupt would not recur until DSR completed?

[Stanislav Meduna <stano@meduna.org>]

On 31.03.2013 16:50, Randy wrote:

>> Remember, neither the ISR nor DSR can block. 
> I know this rule, but I'd like to ask you why.

Well I cannot comment on design choices made by the eCos
developers, but generally:

- an ISR cannot block by definition. It is not a thread, it has
  no state (runnable / blocked / ...), it cannot be scheduled
  by the scheduler, it often gets special handling by the
  hardware itself, ... Its "scheduler" is the hardware, not
  the OS.

- a DSR is basically "the rest of the interrupt handler
  that can run later with interrupts enabled". It is not
  a thread either, it cannot be preempted, it has no
  priority, all pending DSRs are queued and serviced in
  a FIFO manner.

You can find some discussion in a 10 year old thread at
http://www.sourceware.org/ml/ecos-discuss/2003-01/msg00330.html

> I think that one DSR interrupted by other interrupt could continue to
> finish the remainder parts when it reschedule to current thread,
> then, why wait-semaphore in DSR which cause to switch to another
> thread is prevented by scheduler? This maybe because scheduler is
> locked and it could not work, but why don't we enable this function
> in DSR?

Becasue the DSR is not a thread. If you need it to be, you can make
the DSR minimal (just post an event to a normal thread) and do your
processing there. If the processing takes a considerable
amount of time, you should do that anyway. DSR is just a bridge
between the interrupt handler world and a thread world.

>> Disabling interrupts outside of interrupt handlers is generally frowned upon.
> I don't see this, could you please make it more clearly?

Generally in a real-time operating system achieving the best
possible interrupt latency and doing things deterministically
are the main goals, more important than the best possible
general performance. Disabling interrupts adds to the possible
worst-case latency. Having an unbounded number of anything
in some queue or waiting until a thread (possibly low-prio)
is done with some lock breaks determinism.

>> 2) The list of pending DSRs is now upper bounded. With the same
>> interrupt enabled it would become unbounded.
> I'd like to know which case could cause a pending DSR? 

There is a DSR queue. If your DSR could be preempted by the same
interrupt again, that ISR would possibly queue another DSR for
the same interrupt. And again and again.

Now the maximum number of DSRs in the queue basically equals
the number of possible interrupts.

> Does one DSR interrupted by other interrupt could become a pending DSR?
> No, right?

It queues the own DSR which gets processed after all already queued
DSRs. Then the originally interrupted DSR continues.

A real-time operation is not an easy task.

Regards
-- 
                                              Stano


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