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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.99.36.69 with SMTP id k66mr875835pgk.25.1494377505658;
        Tue, 09 May 2017 17:51:45 -0700 (PDT)
X-Received: by 10.157.4.34 with SMTP id 31mr62927otc.2.1494377505596; Tue, 09
 May 2017 17:51:45 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!c26no83048itd.0!news-out.google.com!v18ni174ita.0!nntp.google.com!c26no84882itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 9 May 2017 17:51:45 -0700 (PDT)
In-Reply-To: <oet6vt$5h1$1@franka.jacob-sparre.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=173.71.201.205;
 posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf
NNTP-Posting-Host: 173.71.201.205
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e92ada63-f623-437e-aec8-e69d5e3e4a7f@googlegroups.com>
Subject: Re: Portable memory barrier?
From: Jere <jhb.chat@gmail.com>
Injection-Date: Wed, 10 May 2017 00:51:45 +0000
Content-Type: text/plain; charset=UTF-8
Xref: news.eternal-september.org comp.lang.ada:46742
Date: 2017-05-09T17:51:45-07:00
List-Id: <comp.lang.ada>

On Tuesday, May 9, 2017 at 3:57:50 PM UTC-4, Randy Brukardt wrote:
> "Robert Eachus" wrote in message 
> ...
> >The compiler will play some games, and certainly will leave Write_Index in 
> >a register if possible.
> 
> It better not is Write_Index is Atomic.
> 
> Which is my point on this discussion: what the CPU does is irrelevant if the 
> compiler is implemented correctly. If it isn't, then the compiler is wrong. 
> QED.
> 
> Only the compiler vendor need worry about this level of discussion. 
> Honestly, I doubt anyone else is qualified. (I'm not, and I AM a compiler 
> vendor... ;-)
> 
>                                      Randy.

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?

As an example, if my FIFO was an array of some records that contained a 64 bit 
integer?  I know I can make the FIFO volatile, but as you indicated, that isn't 
enough.  I can't make it Atomic either.