[Adeos-main] RT ISR re-entrance

[Adeos-main] RT ISR re-entrance

[张晶]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

hi all,

In SMP system, an edge triggerred interrupt may be dispatched to multiple
cpus, so the RT ISR of this interrupt may be involved on multiple cpus at
the same time. The question comes: is RT ISR need to be reentrant as
designed or do I miss something?

best regards,

zhangjing

[-- Attachment #2: Type: text/html, Size: 312 bytes --]

Re: [Adeos-main] RT ISR re-entrance

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

?? wrote:
> hi all,
> 
> In SMP system, an edge triggerred interrupt may be dispatched to multiple
> cpus, so the RT ISR of this interrupt may be involved on multiple cpus at
> the same time. The question comes: is RT ISR need to be reentrant as
> designed or do I miss something?

Good question. I would say: yes, it's the I-pipe user's job to take care
of re-entrance safety.

Vanilla Linux prevents this via the IRQ_INPROGRESS flag. Xenomai 2.4 and
since 2.3.2 achieves re-entrance protection for the registered driver
handler by holding the IRQ-related spinlock while calling into that
handler. Still, this isn't something the user should build his system
upon. It is rather recommended for determinism and efficiency reasons to
assign RT IRQs to a specific CPU.

HTH,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] RT ISR re-entrance

[张晶]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

hi,

Thank you for your reply!

2007/8/27, Jan Kiszka <jan.kiszka@web.de>:
>
> ?? wrote:
> > hi all,
> >
> > In SMP system, an edge triggerred interrupt may be dispatched to
> multiple
> > cpus, so the RT ISR of this interrupt may be involved on multiple cpus
> at
> > the same time. The question comes: is RT ISR need to be reentrant as
> > designed or do I miss something?
>
> Good question. I would say: yes, it's the I-pipe user's job to take care
> of re-entrance safety.
>
> Vanilla Linux prevents this via the IRQ_INPROGRESS flag. Xenomai 2.4 and
> since 2.3.2 achieves re-entrance protection for the registered driver
> handler by holding the IRQ-related spinlock while calling into that
> handler.


AFAIK, Xenomai 2.3.3 simply uses the IRQ dispatcher of i-pipe and do not
supply its own dispatcher.

Still, this isn't something the user should build his system
> upon. It is rather recommended for determinism and efficiency reasons to
> assign RT IRQs to a specific CPU.


Good suggestion！Thanks again!

HTH,
> Jan
>
>
>

[-- Attachment #2: Type: text/html, Size: 1700 bytes --]

Re: [Adeos-main] RT ISR re-entrance

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

张晶 wrote:
> hi,
> 
> Thank you for your reply!
> 
> 2007/8/27, Jan Kiszka <jan.kiszka@domain.hid>:
>> ?? wrote:
>>> hi all,
>>>
>>> In SMP system, an edge triggerred interrupt may be dispatched to
>> multiple
>>> cpus, so the RT ISR of this interrupt may be involved on multiple cpus
>> at
>>> the same time. The question comes: is RT ISR need to be reentrant as
>>> designed or do I miss something?
>> Good question. I would say: yes, it's the I-pipe user's job to take care
>> of re-entrance safety.
>>
>> Vanilla Linux prevents this via the IRQ_INPROGRESS flag. Xenomai 2.4 and
>> since 2.3.2 achieves re-entrance protection for the registered driver
>> handler by holding the IRQ-related spinlock while calling into that
>> handler.
> 
> 
> AFAIK, Xenomai 2.3.3 simply uses the IRQ dispatcher of i-pipe and do not
> supply its own dispatcher.

The Xenomai nucleus does dispatch - to the registered handler(s).

> 
> Still, this isn't something the user should build his system
>> upon. It is rather recommended for determinism and efficiency reasons to
>> assign RT IRQs to a specific CPU.
> 
> 
> Good suggestion！Thanks again!
> 
> HTH,
>> Jan
>>
>>
>>

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]