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!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer04.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Portable memory barrier?
Date: Tue, 9 May 2017 07:34:02 +0300
Organization: Tidorum Ltd
Message-ID: <encv5qF8lfnU1@mid.individual.net>
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> <enc2orF3oloU1@mid.individual.net>
 <oeqmqi$7ho$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 6M3WtF/wp0QmeLdH8N0MAwHUOlJ0xmoFaRpnOLMgv3yAWJuJsa
Cancel-Lock: sha1:DirzfG/HxvgS4NBs/Xcuyd1xt4Q=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <oeqmqi$7ho$1@gioia.aioe.org>
X-Received-Bytes: 2747
X-Received-Body-CRC: 3648331401
Xref: news.eternal-september.org comp.lang.ada:46718
Date: 2017-05-09T07:34:02+03:00
List-Id: <comp.lang.ada>

On 17-05-09 00:09 , Dmitry A. Kazakov wrote:
> On 2017-05-08 22:29, Niklas Holsti wrote:
>> On 17-05-08 19:22 , Dmitry A. Kazakov wrote:
>>
>> [snip]
>>
>>> I don't see anything there what would prevent CPU from changing the
>>> order of accesses to two *independent* memory locations when only the
>>> program logic ties them nothing else. Well, except that there is no
>>> obvious reason why it would like to change that order.
>>
>> I quote from an earlier post of mine in this thread:
>>
>> Just as in C, volatile accesses in Ada are guaranteed to occur in the
>> order and number written in the source code and executed in the
>> "standard" order [moreover, this includes all tasks in the program]:
>>
>> RM C.6 (16/3): All tasks of the program (on all processors) that read or
>> update volatile variables see the same order of updates to the
>> variables.
>
> This is ambiguous. Does it read as:
>
> A. Order of updates per volatile variable
>
> B. Order of updates to the set of all volatile variables
>
> B is sufficient, A is not. Depending on the implementation A may imply B
> or not.

To me it is clear that B is meant, because the text uses the plural 
"variables".

If A were meant, the text would say "... that read or update a volatile 
variable see the same order of updates to the variable".

Also, remember that accesses to volatile variables are defined to be 
part of the "external effect" of the program, and all of the external 
effect must occur in the canonical order defined by the Ada semantics, 
without any reordering by compiler or processor.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .