This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: why should ISR arrange that the same interrupt would not recur until DSR completed?
- From: Randy <randyqiuxy at hotmail dot com>
- To: "Stanislav Meduna" <stano at meduna dot org>
- Cc: "eCos Discussion" <ecos-discuss at sourceware dot org>
- Date: Sun, 31 Mar 2013 22:50:36 +0800
- Subject: Re: Re: why should ISR arrange that the same interrupt would not recur until DSR completed?
- References: <CA+QuBBfU01exmSPQQuXqhGOLASYa=4w32Gp=R0bR9DaUWvJJtA at mail dot gmail dot com>, <51546EFC dot 5050603 at dallaway dot org dot uk> <BLU0-SMTP3646F7EEA8206EF237E9FD3C3DD0 at phx dot gbl>, <5158269C dot 5000804 at meduna dot org>
- Reply-to: randyqiuxy <randyqiuxy at hotmail dot com>
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