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.237.63.36 with SMTP id p33mr1211696qtf.22.1494367632580; Tue, 09 May 2017 15:07:12 -0700 (PDT) X-Received: by 10.157.31.68 with SMTP id x4mr50799otx.19.1494367632537; Tue, 09 May 2017 15:07:12 -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!t26no23231qtg.1!news-out.google.com!v18ni89ita.0!nntp.google.com!c26no39011itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 9 May 2017 15:07:12 -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: <36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Portable memory barrier? From: Jere Injection-Date: Tue, 09 May 2017 22:07:12 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:46740 Date: 2017-05-09T15:07:12-07:00 List-Id: On Tuesday, May 9, 2017 at 3:49:29 PM UTC-4, Randy Brukardt wrote: > "Jere" wrote in message > ... > > Thanks for the response! I'm good with all that. I'm more worried about > > situations like these: > > > > Task A: > > -- Do some checks to make sure buffer not full > > > > -- Not full, so put data > > My_Array(Put_Index) := Some_Value; > > if Put_Index = Buffer_Size then > > Put_Index := 0; > > else > > Put_Index := Put_Index + 1; > > end if; > > > > Task B: > > if Put_Index = Get_Index then -- empty > > return False; > > end if; > > > > Result_Value := My_Array(Get_Index); > > -- Do other operations that update Get_Index > > > > Assuming the indexes are atomic and volatile, then I am not worried about > > partial writes to the indexes. I"m more worried about some architectures > > that > > allow for instruction reordering. > > 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. ;-) > Thanks for all the replies. That is interesting. I had assumed Ada's definition was similar to C or C++, but indeed it is different. The C and C++ definitions of volatile guarantee that the compiler will not reorder load/store operations of volatile variables. From this statement it sounds like Ada makes no such guarantee with Volatile. NOTE: The C and C++ definitions hold no guarantee versus CPU instruction reordering like Ada does with pragma Atomic. I got a test going today and tried it on two different GNAT implementations on two different processors. I found that the GPL version of GNAT (gcc 4.9.3) works as you state. Atomic prevents changes in instruction sequence. However, my older version (FSF GCC 4.1.2) does not. Atomic had no affect on sequence (from a CPU perspective at least). I am guessing that Atomic's definition was weaker back then. Again, thanks for this that helps.