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!feed.usenet.farm!feeder3.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!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: Mon, 8 May 2017 23:29:15 +0300
Organization: Tidorum Ltd
Message-ID: <enc2orF3oloU1@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net sUQd19RSGZJBOT9YdznLRA+Jr/+BKzYPSgyA9B+41kz4YzNRgM
Cancel-Lock: sha1:K2waluB6TEtlN/IlCHofvuZo0j8=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <oeq60s$18c1$1@gioia.aioe.org>
Xref: news.eternal-september.org comp.lang.ada:46709
Date: 2017-05-08T23:29:15+03:00
List-Id: <comp.lang.ada>

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. A use of an atomic variable or other mechanism may be 
necessary to avoid erroneous execution and to ensure that access to 
nonatomic volatile variables is sequential (see 9.10).

> Yet the question stands. In particular, which Ada primitives may ensure
> safe implementations of lock-free structures when no protected objects
> used.

Pragma Volatile + RM C.6 (16/3)? If these are not sufficient, why not?

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