Re: Portable memory barrier?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oeq60s$18c1$1@gioia.aioe.org...
> On 2017-05-08 17:56, Robert Eachus wrote:
>> One sentence summary: The CPU will play lots of tricks behind your
>> back, but in such a way you can pretend your code works as you intended.
>> (Er, after you get the bugs out.)
>>
>> On Monday, May 8, 2017 at 3:45:26 AM UTC-4, Dmitry A. Kazakov wrote:
>>
>>> I don't believe either of the sequences can get reordered by the CPU,
>>> but it is only belief and common sense.
>>
>> Silly rabbit, Trix are for kids. Oops, silly programmer, common
>> sense  has nothing to do with modern CPUs.
> [...]
>> Is any of this important to a high-level language programmer? Not
>> really, unless they are working in hard real time. (Which I did.) If you
>> program in assembler, or more likely work on a compiler back-end,
>> knowing which instructions fit together is important. Even more
>> important is coding so that an instruction that references a new cache
>> line in memory is followed by as many instructions as possible that
>> don't use that value. Some times you run into cases where you want to
>> take advantage of write combining or some other trick involving the
>> write pipe--but today, smart compiler optimization is about accesses to
>> main memory and not much else.
>
> 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.
>
> Wikipedia provides a more simple example of the problem:
>
>    https://en.wikipedia.org/wiki/Memory_barrier
>
> The case of a lock-free FIFO is different because it involves index and 
> array element.
>
> For practical use when the buffer size is > 1 there cannot be any problem.
>
> Yet the question stands. In particular, which Ada primitives may ensure 
> safe implementations of lock-free structures when no protected objects 
> used.

Atomic objects make such a guarentee. Nothing else does (well, ignoring 
protected objects, of course, since you excluded them). End of story. 
(Except that compilers might not implement it right, as I noted before.)

                             Randy.