This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: atomic_thread_fence() semantics
- From: Andrew Haley <aph at redhat dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Mattias Rönnblom <hofors at lysator dot liu dot se>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 19 Oct 2017 13:18:18 +0100
- Subject: Re: atomic_thread_fence() semantics
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=aph at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0086212B27
- References: <351d54cc-4da1-dd20-aace-17c5b6244e1a@lysator.liu.se> <CAH6eHdRmC_c=Ta6Ooeqf7RUk6YOBao_uTWNSw51j1zMOV5HBjQ@mail.gmail.com>
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
In this case, all non-atomic and relaxed atomic stores that
happen-before X in thread A will be synchronized-with all non-atomic
and relaxed atomic loads from the same locations made in thread B
after F.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671