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.98.75.24 with SMTP id y24mr3412866pfa.10.1494459059452; Wed, 10 May 2017 16:30:59 -0700 (PDT) X-Received: by 10.157.31.68 with SMTP id x4mr185269otx.19.1494459059411; Wed, 10 May 2017 16:30:59 -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!c26no534387itd.0!news-out.google.com!m134ni1211itb.0!nntp.google.com!c26no534379itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 May 2017 16:30:59 -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: <657dd5c0-4559-41aa-a00f-52ffaa231978@googlegroups.com> Subject: Re: Portable memory barrier? From: Jere Injection-Date: Wed, 10 May 2017 23:30:59 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:46753 Date: 2017-05-10T16:30:59-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. Followup to my previous email: Perhaps it is easier for me to explain what I think is happening: Key Type => Prevents Compiler Reordering => Prevents CPU Reordering After reading the various responses I am under the impression that: Volatile => NO => NO Atomic => YES => YES I had hoped it was Volatile => YES => NO Atomic => YES => YES