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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Tue, 9 May 2017 15:18:41 -0500 Organization: JSA Research & Innovation Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494361122 6100 24.196.82.226 (9 May 2017 20:18:42 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 9 May 2017 20:18:42 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46738 Date: 2017-05-09T15:18:41-05:00 List-Id: "Niklas Holsti" wrote in message news:end561F9mocU1@mid.individual.net... ... > It would be nice to hear from some ARG member re the correct > interpretation of RM C.6 (16/3), as this seems to define whether pragma > Volatile is enough to let us implement lock-free synchronisation routines. (You shouldn't have these discussions while I'm on vacation. ;-) No. You miss the point about "non-erroneous programs" in the AARM note. Almost all accesses to shared variables by multiple tasks is erroneous, unless something makes them sequential. That something can be a rendezvous, a protected action, or an atomic object read/write. Without one of these, volatile guarentees nothing. AARM C.6(16.c/3) was my attempt to explain the difference between volatile and non-volatile, since in most instances there isn't one. (The main answer is that a volatile object can be trusted in another task after an access to an atomic object, and a regular object cannot; otherwise they're identical.) AARM C.6(16.d/3) answers the OPs question: uses of an atomic object implies barriers/fences if one is needed. Note that volatile as a second, separate meaning that should never have been mixed in to the tasking one (that is, access to memory-mapped hardware/software). That has different requirements at this sort of edge. (There's a proposal on the table to split volatile into parts to clarify which kind of use is intended.) Randy.