Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners - v2
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 ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners - v2
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). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners - v2
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. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners - v2
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 Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners - v2
Jan Kiszka wrote: 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. Ok. I had grepped xnthread_handle and found that it was used twice in mutex_unlock, but did not checked if it was used for the same thread. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
