Re: [Xenomai-core] [RFC][PATCH] shirq locking rework

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Dmitry Adamushko wrote:
> On 21/06/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> > [ .. ]
>> > surprise-surprise.. sure, one way or another it must be fixed. heh..
>> > too many bugs (and I don't even want to say who's responsible) :-/
>>
>> I wouldn't accept all the responsibility if I were you.
> 
> I have no problems in this respect. I was just a bit sarcastic with
> the way to say "it's my fault".
> 
> 
>> It's a sign that the design might be
>> too complex now
> 
> frankly speaking, I don't think it's really complex :)
> 
> 
>> Things get worse, at least with XENO_OPT_STATS: Due to the runtime
>> statistics collection, we may end up with dangling references to our
>> xnintr object even after xnintr_shirq_unlock().
>>
>> We would actually need some kind of IRQ_INPROGRESS + synchronize_irq()
>> at i-pipe level. But we have the problem, in contrast to the kernel,
>> that we reschedule from inside the handler (more precisely: at nucleus
>> level), thus synchronize_irq() would not just wait on some simple
>> handler to exit...
> 
> Yeah.. we had already conversations on this topic (I think with
> Philippe) and, if I recall right, that was one of the reasons. That's
> why synchronize_irq() is in the nucleus layer.

Hmm, then we may be forced to get the cookie out of ipipe's hands again
and put it back into a nucleus irq array, i.e. move the cookie
dereferencing under a nucleus managed per-irq lock. But there is still
the issue with xnsched_t::current_account...


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