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 > >
