Re: [Xenomai-core] Fast native mutexes vs. RT_MUTEX_INFO.lockcnt

[Jan Kiszka <jan.kiszka@domain.hid>]

Philippe Gerum wrote:
> 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.

Ah, that's also visible at that place. But the owner is still available
as userland writes its own xnthread_t into the lock variable. We just
face the same issue as with RT_MUTEX_INFO.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux