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.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list