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

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> @@ -230,18 +230,20 @@ static inline int mutex_save_count(xnthr
>>>>  
>>>>  	mutex = shadow->mutex;
>>>>  
>>>> -	if (clear_claimed(xnarch_atomic_intptr_get(mutex->owner)) != cur)
>>>> +	if (clear_claimed(xnarch_atomic_get(mutex->owner)) !=
>>>> +	    xnthread_handle(cur))
>>>>  		return EPERM;
>>>>  
>>>>  	*count_ptr = shadow->lockcnt;
>>>>  
>>>> -	if (likely(xnarch_atomic_intptr_cmpxchg(mutex->owner, cur, NULL) == cur))
>>>> +	if (likely(xnarch_atomic_cmpxchg(mutex->owner, cur, XN_NO_HANDLE) ==
>>>> +		   xnthread_handle(cur)))
>>>>  		return 0;
>>>>  
>>>>  	owner = xnsynch_wakeup_one_sleeper(&mutex->synchbase);
>>>> -	xnarch_atomic_intptr_set
>>>> -		(mutex->owner,
>>>> -		 set_claimed(owner,xnsynch_nsleepers(&mutex->synchbase)));
>>>> +	xnarch_atomic_set(mutex->owner,
>>>> +			  set_claimed(xnthread_handle(owner),
>>>> +				      xnsynch_nsleepers(&mutex->synchbase)));
>>> Ok. Can we avoid xnthread_handle() everywhere by storing its result in a
>>> local variable and reusing this local variable, here and in the other
>>> functions where xnthread_handle is used multiple times ?
>> True for 'cur' here (will fix), but the other case have already been
>> optimized as far as possible (i.e. within the respective scope).
> 
> I have found several other spots where xnthread_handle is called
> multiple times in the same function. mutex_unlock comes to my mind.

Please point me to the concrete spot. I went again through all
xnthread_handle instances in this patch, checking that they aren't
needed due to owner changes, but only found the one above. Specifically
pthread_mutex_unlock, pse51_mutex_unlock_internal and
__pthread_mutex_unlock have only a single reference or reference
different threads.

Jan

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