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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.86.5 with SMTP id o5mr1233496itb.14.1494706295331; Sat, 13 May 2017 13:11:35 -0700 (PDT) X-Received: by 10.157.13.170 with SMTP id 39mr198756ots.18.1494706295304; Sat, 13 May 2017 13:11:35 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!c26no1283427itd.0!news-out.google.com!m134ni4343itb.0!nntp.google.com!c26no1283422itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 13 May 2017 13:11:35 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.201.205; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.201.205 References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Portable memory barrier? From: Jere Injection-Date: Sat, 13 May 2017 20:11:35 +0000 Content-Type: text/plain; charset="UTF-8" Xref: news.eternal-september.org comp.lang.ada:46771 Date: 2017-05-13T13:11:35-07:00 List-Id: On Wednesday, May 10, 2017 at 8:47:23 PM UTC-4, Randy Brukardt wrote: > "Jere" wrote in message > > 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. Ok, that makes sense. I reread 1.1.3 on external effects (referenced from C.6(20)), and I think that helps clarify a lot of this for me. Thanks! I played around with it a bit more. I feel like the RM is very piece-meal with how it defines things. I have to find a bunch of different sections to piece together a full picture on how something is defined. Not that it is wrong in any sense, but it definitely makes it challenging for someone who doesn't yet "know" the standard. I'll get there in time. Still it's helpful that the RM is in html format with links, though sometimes there are places lacking links to definitions (again, to things that once you "know" the standard make sense, but for someone new it can be a bit deep to wade through, especially if you are used to different terminology from other language standards). Again, thanks! Your responses helped clear it up.