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: Mon, 15 May 2017 17:45:33 -0500 Organization: JSA Research & Innovation Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494888333 19799 24.196.82.226 (15 May 2017 22:45:33 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 15 May 2017 22:45:33 +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:46792 Date: 2017-05-15T17:45:33-05:00 List-Id: "Robert Eachus" wrote in message news:fcf4a91a-bfdf-44ee-a888-7bb9a1c52b48@googlegroups.com... On Wednesday, May 10, 2017 at 9:02:22 PM UTC-4, Randy Brukardt wrote: >> Write_Index needs to be atomic in order for the OP's algorithm to work. >> Atomic objects fall under C.6(20/5) -- all reads and updates are included >> in >> the external effect of the program. Optimizing them out (in any way) is >> wrong (excepting of course a true as-if optimization, but that doesn't >> make >> any sense in this case). In particular, saving the value in a register is >> useless, because you still have to read the object again at the next >> reference. >Even if there is no intervening read or write of anything? Yes. >It seems to me that must be an "as if," since there is no way to prove >otherwise. >You may be thinking of reads of memory external to the CPU, part of some >other hardware, where the other hardware can intervene. I'm not "thinking" that, the language defines it that way (it's part of the external effect of the program, C.6(20) and 1.1.3(8-14)). I don't know how a compiler could possibly know if someone has a way to see the external effects (some CPU monitor, active memory, etc.), so one has to assume that they CAN tell. And in any case, the intent of the language designers is crystal-clear -- ignore that at your peril. ... >Hmm. You need to read the (x86 and most other) rules for prefetching memory >locations. >As I stated earlier in this thread, any CPU core is allowed to do a >prefetch of any location, >as long as it does not cause an action like an interrupt. This is >necessary, or you wouldn't >be able to have any Atomic accesses. The CPU reads an entire cache line, >usually 64, 128, >or 256 bytes into the cache, but even the widest of CPU writes are only 64 >bytes wide, and >those are multiple floating-point values. I have the compiler generate the "correct" code and don't worry much about what the CPU does to it. (That's one reason I was completely in favor of removing the bogus requirement to read/write all the way to memory -- it doesn't make sense on CPUs that do caching.) That's out of my hands in any case as a software guy. (Refer to my response to Jere.) There's a requirement to prevent CPU reordering, but nothing else. But I wouldn't be implementing the language if I started ignoring the requirements on the compiler by leaning on an as-if optimization, especially one that can be detected with active hardware. Especially as if I did so, there would be no possibility of ever writing portable synchonization code... Randy.