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.60.78 with SMTP id i14mr3998534pgn.93.1494458495746; Wed, 10 May 2017 16:21:35 -0700 (PDT) X-Received: by 10.157.13.170 with SMTP id 39mr184916ots.18.1494458495698; Wed, 10 May 2017 16:21:35 -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!c26no532165itd.0!news-out.google.com!m134ni1182itb.0!nntp.google.com!c26no532155itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 May 2017 16:21:35 -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:21:35 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:46752 Date: 2017-05-10T16:21:35-07:00 List-Id: On Wednesday, May 10, 2017 at 3:13:27 AM UTC-4, Dmitry A. Kazakov wrote: > On 10/05/2017 02:51, 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? > > But you don't need elements atomic only index has to. If I understood > Randy's explanation correctly atomic access to the buffer index will > give you the barrier between index and element accesses which is all > that is required. I may have misunderstood him, but from Randy's response, I gathered that Volatile has no effect on sequence, only Atomic does. My understanding is that there are two parts to sequence: compiler reordering and cpu reordering. From Randy's response I gathered that Atomic guarantees no CPU rerodering between it and volatile objects (using fences or whatever mechanism provided). If Volatile has no effect on Compiler reordering sequence, then even if Atomic can put fences between it and Volatile objects, if the compiler reorders before that happens, the fence won't help. So I can safely know that the index operations are safe, but I don't know if any assignment before or after the indexing operation is ok or not since the buffer is only volatile. In particular, I am basing it off of this response from Randy: *************************************************** (partial quote) Atomic implies sequential access for atomic AND volatile objects (note that volatile does NOT imply that). See 9.10 if you dare. (And if you understand 9.10, please join the ARG, we need you. ;-) In particular, Atomic implies that any needed memory fences are used. (Again, volatile alone does not make such a requirement.) The idea is that one uses atomic objects to protect larger volatile data structures. *************************************************** So even if Atomic does use fences, if the compiler decides to reorder the statements before the binary is created, it my not help. Did I misunderstand his response? I might have. It has been my own experience that GNAT will prevent "compiler" reordering on operations on Volatile objects, but that is probably just a GNAT extension.