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.176.71.13 with SMTP id h13mr3625436uac.35.1494459605689; Wed, 10 May 2017 16:40:05 -0700 (PDT) X-Received: by 10.157.60.148 with SMTP id z20mr187089otc.3.1494459605538; Wed, 10 May 2017 16:40:05 -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!2.eu.feeder.erje.net!feeder.erje.net!2.us.feeder.erje.net!newspeer1.nac.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!t26no326453qtg.1!news-out.google.com!v18ni1210ita.0!nntp.google.com!c26no534180itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 May 2017 16:40:05 -0700 (PDT) In-Reply-To: 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: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Portable memory barrier? From: Jere Injection-Date: Wed, 10 May 2017 23:40:05 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:46754 Date: 2017-05-10T16:40:05-07:00 List-Id: On Wednesday, May 10, 2017 at 12:38:54 PM UTC-4, Jeffrey R. Carter wrote: > 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! My previous couple of emails might be moot now that I have read this response. Here I get the impression that Volatile does prevent Compiler statement reordering. If that is the case, then I know between that and any fencing put up by Atomic objects will be sufficient. So at this point my understanding is now: Type => Prevents Compiler Reordering => Prevents CPU Reordering Volatile => YES => NO Atomic => YES => YES