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!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Tue, 9 May 2017 09:16:33 +0300 Organization: Tidorum Ltd Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 8pbdmRnwG4C1+tvZ0xM/KAeI0rH0YPwyrVvl5F2sjl8x256vOj Cancel-Lock: sha1:zZhWP4f/O/po52jzPzZLGGoFB7Q= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:46721 Date: 2017-05-09T09:16:33+03:00 List-Id: 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .