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

[Randy <randyqiuxy@hotmail.com>]

Hi Stano,
Thanks for your reponse.
I read some eCos code recently but I have one question now:
After one ISR is over, the DSRs in FIFO queue starts to run one by one like A=>B=>C=>...
If one interrupt comes when B is running, then what will happen?
If B is stoped and the new ISR is going to run, then, how and when does the B come back(we may cann't use "reschedule" to describe it)?
Or, could you tell me which code snippet in eCos3.0 shows the handler?
>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.
Yes, I agree with you, if one thread holds the scheduler lock, then the DSR will be in FIFO queue and become a pending DSR..

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

>> 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.
Now, I see the rule of interrupt handler is SIMPLE, so the handler should be NOT too complicate.
>>> 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
>
>