[PATCH 18/22] atomic: Consolidate atomic_full_barrier implementation

[Wilco Dijkstra]

Hi Adhemerval,

>> 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>

LGTM.

Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

>>  #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.

It doesn't make any difference, all the barriers will be replaced by thread_fence
anyway in a follow-up patch.

Cheers,
Wilco