Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Hi Gilles,
>>>>> trying to understand the cb_read/write lock usage, some question came up
>>>>> here: What prevents that the mutexq iteration in pse51_mutex_check_init
>>>>> races against pse51_mutex_destroy_internal?
>>>>> If nothing, then I wonder if we actually have to iterate over the whole
>>>>> queue to find out whether a given object has been initialized and
>>>>> registered already or not. Can't this be encoded differently?
>>>> We actually iterate over the queue only if the magic happens to be
>>>> correct, which is not the common case.
>>> However, there remains a race window with other threads removing other
>>> mutex objects in parallel, changing the queue - risking a kernel oops.
>>> And that is what worries me. It's unlikely. but possible. It's unclean.
>> Ok. This used to be protected by the nklock. We should add the nklock again.
> Well I do not think that anyone is rescheduling, so we could probably
> replace the nklock with a per-kqueue xnlock.

If nklock or per queue - both will introduce O(n) at least local
preemption blocking. That's why I was asking for an alternative
algorithm than iterating over the whole list.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to