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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cbd507df3efa824b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-30 10:30:22 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!newsfeed.mesh.ad.jp!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Help with Atomic_Components and whole array assignment Date: Tue, 30 Jan 2001 18:20:20 GMT Organization: Deja.com Message-ID: <9570ko$fg1$1@nnrp1.deja.com> References: <94h55t$9a1$1@nnrp1.deja.com> <3A6C2CDD.67FD79DC@baesystems.com> <94hfaq$h3n$1@nnrp1.deja.com> <94hn5p$on4$1@nnrp1.deja.com> <3A76E3B9.BD806841@averstar.com> NNTP-Posting-Host: 205.232.38.14 X-Article-Creation-Date: Tue Jan 30 18:20:20 2001 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x62.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:4718 Date: 2001-01-30T18:20:20+00:00 List-Id: In article <3A76E3B9.BD806841@averstar.com>, Tucker Taft wrote: > I don't agree with Robert's reading of this. It seems very > clear that you cannot combine multiple updates of separate > atomic objects into a single write. I disagree with Tuck. Please provide a test program where it would be theoretically possible to determine that combining writes had a semantic effect. > One of the whole points of atomic > is to make each write separate and indivisible. Indivisible, yes. Separate no. You may have intended to say this, and you may have thought it, but I don't see that the RM says, or even implies this. > It was designed specifically to address issues relating to > "active" memory, where breaking the write down into multiple > writes, or combining multiple writes into a single write, > would confuse the device. This is a total surprise to me, and certainly there is nothing in the RM that would reveal this hidden design intent. For example, an implementation which locks the bus and then does a whole sequence of writes for an atomic variable, and then unlocks the bus, CLEARLY meets the semantics of the RM. This is a case of the designer reading more into what's there than what was written. My own view is that it is almost impossible to achieve the design goal that Tuck quotes, except on an implementation advice basis. I had no idea that the design team had this view of pragma Atomic (because nothing they ever wrote in the RM implied this viewpoint). Note that the detailed list in AARM C.6(20) of disallowed transformations has no hint at all of the "separate" part of Tuck's claim, and conspicuously does not list combining writes as an improper transformation. Tuck, having something in your mind is not good enough if you do not write it down :-) > In general, that means each read/update is a separate > instruction. No, there is absolutely NO implication of this > Which particular instruction is not specified, though of > course in most cases it will be a load or a store. > I don't agree with the advice of slipping into machine code > to accomplish all of these kinds of things, if atomic can do > the job. But it can't! In particular, suppose you have four atomic byte variables next to one another. It is perfectly fine to do a word load followed by a shift and mask, but likely this would play havoc with memory mapped I/O. > I would agree that with the original code, which used an > aggregate assignment, there is no requirement to perform that > as separate byte assignments. However, if the code is > written as a sequence (or a loop) of separate assignments, > and the objects are atomic, it is a bug (in my view) if the > compiler combines these assignments into a single > assignment. You repeat this, but the RM does not support this view point. > Similarly, reordering such assignments > would be a bug, since it would change the external effect of > the program in an impermissible way. No, this is not similar at all. Everyone agrees that reordering is not permitted, because you can see external effects not corresponding to the canonical order. The RM is quite explicit in this case, and indeed AARM C.6(20.c) gives an explicit example of this not being allowed, but the AARM does not list combining. Too bad you did not list the combining case in the AARM Tuck, then we would at least have known what was in your mind, and could have discussed the point that the RM wording does not happen to capture this intent (and as I say, I think it would be almost impossible to capture this intent). For all the examples in AARM C.6(20), you can devise simple pure Ada tests that can conceptually malfunction because of a task switch at a bad point (it may be tricky to actually do the run that fails, since it depends on very precise timing). But for the combining case, you cannot devise a pure Ada test that even conceptually fails. The idea that pragma Atomic solves this problem is an old confusion, going way back to Ada 83 days, I thought we had put that to rest in Ada 95, because we never discussed the idea that Atomic *did* solve this problem. I am somewhat amazed to see the claim that it was addressed :-) Sent via Deja.com http://www.deja.com/