This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Stano,
Thanks for your rapid response.
>On 31.03.2013 10:10, Randy wrote:
>
>> But why? If other interrupt could be enable when processing DSR, why
>> is the same interrupt not allowed?
>
>1) Other interrupt does not need to synchronize access to the hardware
>and/or data structures shared between the ISR and corresponding DSR.
That's right, it should be the reason why we don't allow the interrupt to recur during DSR.
>Remember, neither the ISR nor DSR can block. 
I know this rule, but I'd like to ask you why. 
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?
>Disabling interrupts outside of interrupt handlers is generally frowned upon.
I don't see this, could you please make it more clearly?
>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? 
Does one DSR interrupted by other interrupt could become a pending DSR? No, right?
>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
>
>
Thanks a lot..
Best regards,
Randy

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]