Re: [Xenomai-core] [RFC][PATCH 2/3] Switch to handle-based fast mutex owners

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> +	xnarch_atomic_set(mutex->owner,
>>>>>> +		 	  set_claimed(xnthread_handle(owner),
>>>>>> +				      xnsynch_nsleepers(&mutex->synchbase)));
>>>>> Ok. I think you have spotted a bug here. This should be mutex->sleepers
>>>>> instead of xnsynch_nsleepers.
>>>> BTW, why do you need to track sleepers separately in POSIX? Native
>>>> doesn't do so, e.g.
>>> Because of the "syscall-needed-when-unlocking-stolen-mutex" issue I
>>> already explained (sleepers - xnsynch_nsleepers is precisely the count
>>> of pending threads which have been awake then robbed the mutex).
>> Hmm, sounds like the new lock owner should better clear the 'claimed'
>> bit then, not the old one on return from unlock. Or where is the
>> pitfall? How does the futex algorithm handle this scenario?
> 
> Ok. Please read my explanation again, I have already explained this in
> another mail.

I did this, but I'm unable to derive the answer for my question from it.
Let's go through it in more details:

When we pass a mutex to a new owner, we set its reference in the fast
lock variable + set the claimed bit if there are more waiters. Instead,
I would simple set that bit if there is a new owner. That owner will
then pick up the mutex eventually and clear 'claimed' on exit from it
lock service (if there are no further waiters then). If the new owner is
not able to run and we steal the lock, we simple keep the 'claimed' bit
as is. On exit from the stolen lock we find it set, thus we are forced
to issue a syscall as it should be.

OK, what happens if some waiter wants to leave the party while we are
holding the stolen lock? Then the sleeper number must be correct - that
is one pitfall!

I will have to dig into this more deeply, considering more cases. But
the additional "sleepers" field remains at least misplaced IMHO.
xnsynch_sleepers should better be fixed to respect lock stealing, as
lock stealing is an xnsynch property, nothing POSIX-specific.

Jan

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