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 15:01:49 -0500
Organization: JSA Research & Innovation
Message-ID: <oet77d$5ia$1@franka.jacob-sparre.dk>
References: <e8d229c0-317e-4f5a-8d54-cf56c3aede7a@googlegroups.com>
 <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com>
 <oep7mj$1g3f$1@gioia.aioe.org>
 <e87ac3c3-8390-4d1d-979d-0bcc7e4d3dde@googlegroups.com>
 <oeq60s$18c1$1@gioia.aioe.org>
 <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com>
 <oeqmqm$7ho$2@gioia.aioe.org>
 <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com>
 <8a968aae-79e4-421b-ba4b-e0a9a33ce0db@googlegroups.com>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1494360109 5706 24.196.82.226 (9 May 2017
 20:01:49 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 9 May 2017 20:01:49 +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:46736
Date: 2017-05-09T15:01:49-05:00
List-Id: <comp.lang.ada>


"Jere" <jhb.chat@gmail.com> wrote in message 
news:8a968aae-79e4-421b-ba4b-e0a9a33ce0db@googlegroups.com...
...
>I am still digesting some of this, so forgive the simple question:

Don't bother, it's irrelevant if you trust your compiler vendor. If you 
don't, then you're out of luck on modern CPUs because mere mortals cannot 
understand them.

>What prevents the last 3 lines from being reordered like this:
>r1 := r1 + 1;
>(Write_Index'Address) := r1;
>(r3) := r4;

Assuming again that Write_Index is atomic as is necessary to make any 
guarentees, this translation is 100% wrong (can't put Write_Index into a 
register), so reordering is irrelevant. If the CPU is going to do it anyway, 
then the compiler has to do whatever the CPU vendor provided to prevent it.

If Write_Index isn't atomic, then you can make no assumptions about how the 
code is executed and hopefully you aren't (it is purely sequential code).

                              Randy.