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!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Portable memory barrier?
Date: Wed, 10 May 2017 18:38:48 +0200
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <oevfgl$l66$1@dont-email.me>
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>
 <oet6vt$5h1$1@franka.jacob-sparre.dk>
 <e92ada63-f623-437e-aec8-e69d5e3e4a7f@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 10 May 2017 16:35:33 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="d85b2422e8a6c6a4666200c21062116e";
	logging-data="21702"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX182JxWT6SkQXf/t5Qjfbplz6+5Y5ivEnGY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
In-Reply-To: <e92ada63-f623-437e-aec8-e69d5e3e4a7f@googlegroups.com>
Cancel-Lock: sha1:JMPO4aVLA/B36uP4DaGu9/KmF5g=
Xref: news.eternal-september.org comp.lang.ada:46746
Date: 2017-05-10T18:38:48+02:00
List-Id: <comp.lang.ada>

On 05/10/2017 02:51 AM, Jere wrote:
>
> Is there a method besides Atomic?  If I am implementing a generic FIFO (lock
> free) and the FIFO elements are complex data types that may not be able to be
> atomic, do I have any other options or are protected objects my only way out?

If your indices are Atomic and your array has Volatile_Components, then I think 
things will work the way you want them to. The important reference here is ARM 
1.1.3, which says

* Any read or update of an atomic or volatile object is part of the program's 
external interactions.

* An Ada compiler must produce a program with external interactions in the order 
and timing specified by Ada's semantics.

Ada's semantics for a sequence of statements say the statements are executed in 
order.

So, if you have in task A

A (I + 1) := Item;
I := I + 1;

Then from the outside an observer must see in order

1. Read I
2. Write A (I + 1)
3. Read I
4. Write I

If task B does

if I > 0 then

then B's "Read I" will also be something the external observer can see. It might 
happen before 1., between 1. and 3., between 3. and 4., or after 4., but won't 
happen during any of 1, 3, or 4. That guarantees that B will always get a valid 
view of I.

Thanks to Holsti for pointing this out [through ARM C.6(20)]. My previous 
understanding of this was incorrect.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09