Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>>
>>> next issue on my way towards fast native mutexes: as mutexes are now
>>> mostly acquired in user space, the recursion counter lockcnt will only
>>> be maintained in the context of the owning thread (at best: its process)
>>> in user space. No update on the kernel-side lockcnt will take place
>>> anymore, thus rt_mutex_inquire can only return 0 or 1, no > 1. Is it OK
>>> to break the ABI here?
>>>
>> I think so, we might lose some debug information, but that's the price for 
>> much
>> better performances. I can't imagine any sane code iterating lockcnt-times
>> blindly to unlock a mutex it owns until it is free. Nah, of course not...
>>
>> Btw, I guess that the /proc information about mutexes would have to be 
>> reworked
>> as well.
> 
> Haven't looked into this yet (or haven't stumbled over any issue). What
> conflict / lack of data do you have in mind here?
>

Basically, exporting the lock owner and the locking depth is likely no more
possible for userland optimized mutexes.

> Jan
> 


-- 
Philippe.

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

Reply via email to