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" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Portable memory barrier?
Date: Tue, 9 May 2017 14:49:28 -0500
Organization: JSA Research & Innovation
Message-ID: <oet6g8$5be$1@franka.jacob-sparre.dk>
References: <e8d229c0-317e-4f5a-8d54-cf56c3aede7a@googlegroups.com>
 <oek2dp$lno$1@dont-email.me>
 <36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1494359368 5486 24.196.82.226 (9 May 2017
 19:49:28 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 9 May 2017 19:49:28 +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:46733
Date: 2017-05-09T14:49:28-05:00
List-Id: <comp.lang.ada>

"Jere" <jhb.chat@gmail.com> wrote in message 
news:36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com...
...
> 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. ;-)

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.

Caveat: that's an untestable requirement, so you're totally at the mercy of 
your compiler vendor to get this right.

                                Randy.

P.S. Yes, we've discussed this in the ARG. We believe the RM description has 
the right effect, but the issues and wording are both hairy, so we could be 
wrong.