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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Wed, 10 May 2017 20:14:53 -0500 Organization: JSA Research & Innovation Message-ID: References: <36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494465294 3251 24.196.82.226 (11 May 2017 01:14:54 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 May 2017 01:14:54 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46759 Date: 2017-05-10T20:14:53-05:00 List-Id: "Jere" 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.