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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Tue, 9 May 2017 10:34:09 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:46726 Date: 2017-05-09T10:34:09+02:00 List-Id: On 09/05/2017 08:16, Niklas Holsti wrote: > On 17-05-09 07:34 , Niklas Holsti wrote: >> On 17-05-09 00:09 , Dmitry A. Kazakov wrote: >>> On 2017-05-08 22:29, Niklas Holsti wrote: >>>> On 17-05-08 19:22 , Dmitry A. Kazakov wrote: >>>> >>>> [snip] >>>> >>>>> I don't see anything there what would prevent CPU from changing the >>>>> order of accesses to two *independent* memory locations when only the >>>>> program logic ties them nothing else. Well, except that there is no >>>>> obvious reason why it would like to change that order. >>>> >>>> I quote from an earlier post of mine in this thread: >>>> >>>> Just as in C, volatile accesses in Ada are guaranteed to occur in the >>>> order and number written in the source code and executed in the >>>> "standard" order [moreover, this includes all tasks in the program]: >>>> >>>> RM C.6 (16/3): All tasks of the program (on all processors) that >>>> read or >>>> update volatile variables see the same order of updates to the >>>> variables. >>> >>> This is ambiguous. Does it read as: >>> >>> A. Order of updates per volatile variable >>> >>> B. Order of updates to the set of all volatile variables >>> >>> B is sufficient, A is not. Depending on the implementation A may imply B >>> or not. >> >> To me it is clear that B is meant, because the text uses the plural >> "variables". >> >> If A were meant, the text would say "... that read or update a volatile >> variable see the same order of updates to the variable". >> >> Also, remember that accesses to volatile variables are defined to be >> part of the "external effect" of the program, and all of the external >> effect must occur in the canonical order defined by the Ada semantics, >> without any reordering by compiler or processor. > > Hmm... there may be some support for interpretation A in the Annotated RM. > > In the Annotated RM, the following notes follow C.6 (16/3) and IMO > support the view that this rule is meant to ensure a consistent access > order over all volatile variables, that is, interpretation B (note also > that some sentences speak or variables in plural, others speak of a > single variable, suggesting that the choice of plural or singular is > intentional and carries meaning): > > - 16.a/3 Implementation Note: {AI05-0117-1} {AI05-0275-1} To ensure > this, on a multiprocessor, any read or update of an atomic object may > require the use of an appropriate memory barrier. > > - 16.b/3 Discussion: {AI05-0275-1} From 9.10 it follows that (in > non-erroneous programs) accesses to variables, including those shared by > multiple tasks, are always sequential. This guarantees that no task will > ever see partial updates of any variable. For volatile variables > (including atomic variables), the above rule additionally specifies that > all tasks see the same order of updates. > > - 16.c/3 {AI05-0275-1} If for a shared variable X, a read of X occurs > sequentially after an update of X, then the read will return the updated > value if X is volatile or atomic, but may or or may not return the > updated value if X is nonvolatile. For nonvolatile accesses, a signaling > action is needed in order to share the updated value. > > ("Sequentially" above refers to RM 9.10, I believe.) > > On the other hand, the final note on (16/3) in the ARM, below, speaks of > the order imposed by accesses to a _single_ atomic variable ("the same > atomic variable"), which may suggest interpretation A: > > - 16.d/3 {AI05-0275-1} Because accesses to the same atomic variable by > different tasks establish a sequential order between the actions of > those tasks, implementations may be required to emit memory barriers > around such updates or use atomic instructions that imply such barriers. > > 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. The interpretation B would mean that having pragma Atomic on the read and write indices should be sufficient for the FIFO implementation. And it will be portable. P.S. It would be a great help to have a hard requirement in ARM to support Atomic for all scalar types, e.g. Stream_Element_Offset. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de