This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [PATCH] powerpc: Fix missing barriers in atomic_exchange_and_add_{acq,rel}
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Torvald Riegel <triegel at redhat dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 24 Oct 2014 08:15:04 -0500
- Subject: Re: [RFC] [PATCH] powerpc: Fix missing barriers in atomic_exchange_and_add_{acq,rel}
- Authentication-results: sourceware.org; auth=none
- References: <1413921274 dot 8483 dot 65 dot camel at triegel dot csb>
- Reply-to: munroe at us dot ibm dot com
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.