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:
>>>> @@ -329,6 +326,13 @@ int pse51_mutex_timedlock_break(struct _
>>>>  				break;
>>>>  			}
>>>>  		}
>>>> +		if (!xnsynch_nsleepers(&mutex->synchbase)) {
>>>> +			xnarch_atomic_set
>>>> +				(mutex->owner,
>>>> +				 clear_claimed
>>>> +					(xnarch_atomic_get(mutex->owner)));
>>>> +			xnsynch_set_owner(&mutex->synchbase, NULL);
>>>> +		}
>>>>  		xnlock_put_irqrestore(&nklock, s);
>>> I do not like this at all. I mean, unless I am mistaken, we loose more
>>> than we gain, we are adding a couple of atomic, hence heavy, operations
>>> in a common case for handling a corner case. I still prefer emitting a
>>> system call in the corner case.
>> The hunk above is in the mutex' deadlock path - I wouldn't call this a
>> common case. Moreover, we don't any expensive cmpxchg here.
>>
>> I haven't counted ops, but my strong feeling is that this patch actually
>> shortens the common code paths + it safely avoids one syscall in the
>> lock stealing case.
> 
> I have not yet understood how this happens.

Argh, it won't work for all cases: When the robbed owner retries the
acquisition while the current owner still holds the lock, that clearing
of xnsynch_owner has the fatal effect of letting the former thread
proceed as well. So we cannot get around to extend xnsynch, teaching it
about the two-level ownership management - or actually folding fast lock
support into xnsynch.

Jan

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