Re: Portable memory barrier?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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