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
>> 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.
Xenomai-core mailing list