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

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

[Jan Kiszka]

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?

Jan

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

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

[Philippe Gerum]

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.

> Jan
> 


-- 
Philippe.

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

[Jan Kiszka]

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?

Jan

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

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

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

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

[Jan Kiszka]

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...

Hmm, we could rename 'lockcnt' to 'locked' so that no one can stumble
accidentally over this change...

Jan

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