From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Wed, 10 May 2017 19:47:21 -0500 Organization: JSA Research & Innovation Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494463641 2654 24.196.82.226 (11 May 2017 00:47:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 May 2017 00:47:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46757 Date: 2017-05-10T19:47:21-05:00 List-Id: "Jere" wrote in message news:f441cc24-a41e-496e-970f-989a319a2a08@googlegroups.com... > On Wednesday, May 10, 2017 at 3:13:27 AM UTC-4, Dmitry A. Kazakov wrote: >> On 10/05/2017 02:51, Jere wrote: ... > I may have misunderstood him, but from Randy's response, I gathered that > Volatile has no effect on sequence, only Atomic does. There are two "sequences" here, one is what the compiler is allowed to reorder (which is only non-volatile things, remember that atomic implies volatile), and one is what the CPU is allowed to reorder (which is anything other than atomic, the compiler has to do whatever is needed to avoid atomic reordering). ... > In particular, I am basing it off of this response from Randy: > *************************************************** > (partial quote) > Atomic implies sequential access for atomic AND volatile objects (note > that > volatile does NOT imply that). See 9.10 if you dare. (And if you > understand > 9.10, please join the ARG, we need you. ;-) > > In particular, Atomic implies that any needed memory fences are used. > (Again, volatile alone does not make such a requirement.) The idea is that > one uses atomic objects to protect larger volatile data structures. > *************************************************** > > So even if Atomic does use fences, if the compiler decides to reorder the > statements before the binary is created, it my not help. > > Did I misunderstand his response? I might have. Yes. I didn't say anything about compiler reordering, because it's crystal clear from C.6(20/5) and C.6(16/3) [and the earlier versions, too] that no compiler reordering is allowed. [Indeed, C.6(20/5) was too strong, preventing writing volatile bit-fields if taken literally (you have to do a pre-read to do a bit-field write, but that would clearly by a "memory read of a volatime object not specified by the program"), so it had to be weakened.] It's the effect on CPU reordering that isn't very clear; the AARM notes C.6(16.a-d/3) are intended to clarify this, but not everyone reads the AARM. Randy.