This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: atomic_thread_fence() semantics
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Mattias Rönnblom <hofors at lysator dot liu dot se>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 20 Oct 2017 12:54:58 +0200
- Subject: Re: atomic_thread_fence() semantics
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=triegel at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DDA44C07C58D
- References: <351d54cc-4da1-dd20-aace-17c5b6244e1a@lysator.liu.se> <CAH6eHdRmC_c=Ta6Ooeqf7RUk6YOBao_uTWNSw51j1zMOV5HBjQ@mail.gmail.com> <9c91456c-1900-fddf-0bc6-c2df47816203@redhat.com>
On Thu, 2017-10-19 at 13:18 +0100, Andrew Haley wrote:
> On 19/10/17 13:10, Jonathan Wakely wrote:
> > There are no atomic operations on atomic objects here, so the fence
> > doesn't synchronize with anything.
>
> Really? This seems rather unhelpful, to say the least.
>
> An atomic release operation X in thread A synchronizes-with an acquire
> fence F in thread B, if
>
> there exists an atomic read Y (with any memory order)
> Y reads the value written by X (or by the release sequence headed by X)
> Y is sequenced-before F in thread B
You write that X is an _atomic_ release operation, but that would have
to be an atomic memory_order_release store. Alternatively, it would
have to be an atomic memory_order_relaxed store sequenced after a
release fence. There are only nonatomic stores in this example, so
reordering them before the release fence is not observable in a correct
program (ie, a data-race-free one).