Re: Portable memory barrier?

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

"Jere" <jhb.chat@gmail.com> wrote in message 
news:bcb9bcd3-34f2-4075-905d-bd1957657dc6@googlegroups.com...
> On Tuesday, May 9, 2017 at 3:49:29 PM UTC-4, Randy Brukardt wrote:
....
> I got a test going today and tried it on two different GNAT 
> implementations on
> two different processors.  I found that the GPL version of GNAT (gcc 
> 4.9.3)
> works as you state.  Atomic prevents changes in instruction sequence. 
> However,
> my older version (FSF GCC 4.1.2) does not.  Atomic had no affect on 
> sequence
> (from a CPU perspective at least).  I am guessing that Atomic's definition 
> was
> weaker back then.

It was never "weaker", but the implications on compilers were not as well 
understood (especially the ones about fences). AI05-0117-1 was the original 
discussion on this topic, it was mostly worked on in 2010. (It originated 
earlier, but all work was in 2010 and 2011.) AI05-0275-1 clarified this 
further in late 2011 and early 2012.

So it's likely that compilers implemented prior to 2010 don't implement any 
fences for atomic objects, mostly likely because the need for them wasn't 
understood. (I personally had no idea...) More recent compilers are much 
more likely to do it right.

Also note that the 2010 AI was classified as an Amendment, so it only 
applies to Ada 2012. I'm not sure why that was (the definition in Ada 2012 
is *weaker* than the one in earlier Ada versions), but it does mean that any 
Ada 95 or Ada 2005 implementations may not deal with this properly.

                                      Randy.