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!feeder.erje.net!1.eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Sat, 6 May 2017 23:42:53 +0300 Organization: Tidorum Ltd Message-ID: References: <36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net iTgWZPwlcICkcx6pr8I4Fw8afjNi7LSxLoYpvA+CDUzDRp9z1s Cancel-Lock: sha1:uRzLYZzn/B2PuKExEc46Dtov1O4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:46690 Date: 2017-05-06T23:42:53+03:00 List-Id: On 17-05-06 22:41 , Jeffrey R. Carter wrote: > On 05/06/2017 04:17 PM, Jere wrote: >> >> Side note: If I read it right, you seemed to indicate that volatile >> has nothing >> to do with sequence. I'm no Ada expert, so I wanted to ask your >> interpretation >> of section 16/3 of C.6. I'm used to C and C++ where if you have two >> volatile >> variables being updated like this: >> >> Vol_Var_1 = 0; >> Vol_Var_2 = 23; >> >> That the C and C++ standard guarantees the "compiler" will not reorder >> those two >> statements. Note this says nothing about atomicness (which is only >> one reason >> among others why Volatile is not sufficient for threading). It also >> doesn't >> prevent the processor from reordering them. When I read that section >> in C.6 of >> the RM, the verbage made me think Ada also prevented the compiler from >> reordering the statements (again no relation to atomicness or CPU >> reordering). >> >> Is this not the case? > > Volatile is intended to guarantee that all reads and writes deal with > the memory location directly. Well... for some value of "directly". As I understand it, reading or writing a volatile variable can still use the cache, so depending on the cache architecture and state, a read may or may not read the "real" memory, and ditto for a write. > The idea is for things like memory-mapped > H/W registers, where the H/W might change the value of the register or > writing to the register causes the H/W to do something. And such registers are usually defined in the HW as non-cacheable, so in the end volatile access to such registers works as intended, and as you say. > This prevents > optimizations that keep the value in a register for a while before > writing it back to memory, for example, but not reordering the accesses > to different variables IIUC. 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: 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. A use of an atomic variable or other mechanism may be necessary to avoid erroneous execution and to ensure that access to nonatomic volatile variables is sequential (see 9.10). RM C.6 (20): The external effect of a program (see 1.1.3) is defined to include each read and update of a volatile or atomic object. The implementation shall not generate any memory reads or updates of atomic or volatile objects other than those specified by the program. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .