Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> BTW, I'm also preparing a patch to overcome hash chain registrations for
>>>> anonymous (handle-only) objects as I need more of them (one for each
>>>> thread) for fast mutexes - to avoid fiddling with kernel pointers in
>>>> userland.
>>> Ok. You will have a problem mangling a registry handle with the claimed
>>> bit. Or maybe we can assume that the bit 31 is not used or something ?
>> That's precisely my plan, use the highest bit (2^32 registry slots are
>> fairly unlikely even on 64 bit).
>>
>>> And by the way, I had an idea of removing the duplication of the owner
>>> field between an xnsynch and a mutex object, this would allow saving a
>>> syscall when a situation of mutex stealing happened. Using a handle
>>> would prevent this. But I am not so sure it is a good idea now (namely
>>> because it would move some compare-and-swap the owner logic to the
>>> xnsynch API).
>> How could you save one of the two syscalls on lock stealing? By
>> introducing another bit in the fast lock word that indicates something
>> like XNWAKEN? On first sight, this shouldn't require moving everything
>> into xnsynch (though generic fast locks were not that bad...) nor
>> interfere with handle-based lock words.
> 
> The problem is that when the thread that did the stealing unlocks the
> mutex, xnsynch_wakeup_one_sleeper must be called to set the xnsynch
> owner to NULL, so that the robbed thread will succeed in getting the
> xnsynch. But for xnsynch_wakeup_one_sleeper to be called, we must issue
> the syscall. If the owner was shared between the mutex and the xnsynch,
> the owner could be set to NULL by the mutex unlock from user-space.

That is what the "sleepers" field in the pse51_mutex_t structure is for.

-- 
                                                 Gilles.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to