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 _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core