This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] [PATCH] powerpc: Fix missing barriers in atomic_exchange_and_add_{acq,rel}


On Tue, 2014-10-21 at 21:54 +0200, Torvald Riegel wrote:
> On powerpc, atomic_exchange_and_add is implemented without any barriers.
> However, atomic_exchange_and_add_acq and atomic_exchange_and_add_rel
> (which supposedly should have acquire / release barrier semantics) both
> fall back to atomic_exchange_and_add if they are not defined (see
> include/atomic.h).  I have not reviewed existing code to see whether
> this would indeed cause a bug, but this lack of barriers likely is a
> (future) fault, and prevents any use of
> atomic_exchange_and_add_{acq,rel} that actually rely on the barrier
> semantics.  Therefore, this patch defines
> atomic_exchange_and_add_{acq,rel} using atomic_read_barrier /
> atomic_write_barrier.
> 
> I have NOT tested this.  Can somebody who cares about powerpc please
> have a look and test this?  Thanks!

This is incorrect. Do not apply these changes.

The requirement for memory barriers depend on how the result of the
exchange and add is used. For example if the value is a simple counter
or the original value (result of the larx load) is used as an address
there is NO need for a memory barrier. 

See PowerISA-2.07 BookII, Appendix B.2.1.2

So this is unnecessarily pessimistic and should not be the default.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]