[PATCH 18/22] atomic: Consolidate atomic_full_barrier implementation

[Adhemerval Zanella Netto]

On 11/09/25 12:06, Uros Bizjak wrote:
> On Thu, Sep 11, 2025 at 3:53 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>> All ABIs save for sparcv9 and s390 defines it to __sync_synchronize,
>> which can be mapped to __atomic_thread_fence (__ATOMIC_SEQ_CST).
>>
>> For Sparc, it uses a stricter #StoreStore|#LoadStore|#StoreLoad|#LoadLoad
>> instead of the #StoreLoad generated by __sync_synchronize.
>>
>> For s390x, it defaults to a memory barrier where __sync_synchronize
>> emits a 'bcr 15,0' (which the manual describes as pipeline synchronization).
>>
>> The barrier is used only in one place (pthread_mutex_setprioceiling),
>> and using a stricter barrier for s390 is ok performance-wise.
>>
>> Co-authored-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
>> ---
>>  include/atomic.h                   |  2 +-
>>  sysdeps/aarch64/atomic-machine.h   |  3 ---
>>  sysdeps/alpha/atomic-machine.h     |  1 -
>>  sysdeps/arc/atomic-machine.h       |  2 --
>>  sysdeps/arm/atomic-machine.h       |  2 --
>>  sysdeps/generic/malloc-machine.h   |  4 ----
>>  sysdeps/hppa/atomic-machine.h      |  2 --
>>  sysdeps/loongarch/atomic-machine.h |  2 --
>>  sysdeps/mips/atomic-machine.h      | 20 --------------------
>>  sysdeps/mips/sys/asm.h             | 16 ----------------
>>  sysdeps/or1k/atomic-machine.h      |  2 --
>>  sysdeps/powerpc/atomic-machine.h   |  2 --
>>  sysdeps/riscv/atomic-machine.h     |  2 --
>>  sysdeps/x86/atomic-machine.h       |  1 -
>>  14 files changed, 1 insertion(+), 60 deletions(-)
>>
>> diff --git a/include/atomic.h b/include/atomic.h
>> index a9eb4d740b..9bd2753e32 100644
>> --- a/include/atomic.h
>> +++ b/include/atomic.h
>> @@ -103,7 +103,7 @@
>>
>>
>>  #ifndef atomic_full_barrier
>> -# define atomic_full_barrier() __asm ("" ::: "memory")
>> +# define atomic_full_barrier() __atomic_thread_fence (__ATOMIC_SEQ_CST)
>>  #endif
> 
> Maybe this change should be more like Wilco's change:
> 
> +# define atomic_full_barrier() atomic_thread_fence_seq_cst()
> 
> to use macros, defined a few lines below. This is also consistent with
> how e.g. atomic_compare_and_exchange_val_acq() uses
> atomic_compare_exchange_acquire().

Right, it seems a better strategy indeed. I missed this from Wilco's
patch.