Re: Portable memory barrier?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .