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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1a4f1da89a53b5ea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-10 10:00:07 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!jussieu.fr!fu-berlin.de!uni-berlin.de!ppp-4-155.5800-10.access.uk.worldonline.COM!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Pragma Atomic Date: Wed, 10 Jan 2001 17:53:02 -0000 Message-ID: <93i7oi$a6laq$2@ID-25716.news.dfncis.de> References: <93g48c$ehk$1@nnrp1.deja.com> NNTP-Posting-Host: ppp-4-155.5800-10.access.uk.worldonline.com (62.64.176.155) X-Trace: fu-berlin.de 979149395 10704218 62.64.176.155 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: supernews.google.com comp.lang.ada:3868 Date: 2001-01-10T17:53:02+00:00 List-Id: "Adam Beneschan" wrote in message news:93g48c$ehk$1@nnrp1.deja.com... > I'm having trouble understanding what pragma Atomic is for. > > The RM says that "all reads and updates of the object as a whole are > indivisible." (C.6(15)) The RM never defines what "indivisible" > means, however. On first glance, my understanding would be that if > you have an indivisible record type: > > type Rectype is record > Field1 : integer; > Field2 : integer; > end record; > pragma Atomic (Rectype); > > then when you read (or write) an object of that type, nothing can come > between the read of Field1 and the read of Field2. Thus, the process > can't be interrupted in between reads of the two fields, and no other > processor on a multi-processor system can access the object in between > and (say) modify Field2 after the first processor reads Field1. At > least, that's my interpretation of the word. I agree with your interpretation this far. > It wouldn't make sense > to declare a scalar object, whose size is a natural size on the > processor, to be Atomic, since the processor's reads and writes of > such an object would automatically be indivisible anyway. Yes it does make sense, because not all scalar objects are the size of a 'natural' machine word, and not all machine architectures have a memory bus the same width as the natural machine width. Sometimes a scalar will have the size of two or four machine or memory words, and sometimes half or a quarter of one. In these cases, it is possible for one ordinary access to be divisible, either because two (or more) instructions are needed for the access (e.g. two 16-bit load instructions to read one 32-bit integer) which may be interrupted inbetween, or because one instruction causes two (or more) memory transactions to be issued (e.g. two 16-bit memory reads for a single 32-bit integer load instruction) and another processor executing in parallel interleaves its memory transactions [writes*] with them. I'm sure there are further possibilities (on unusal architectures). > However, the examples in the Rationale, Section C.5, don't make sense > to me. One is > > Buffer: array (1..Max) of Integer; > pragma Atomic_Components(Buffer); > > in which "Atomic" is applied to each Integer component; Hopefully my explanation for pragma Atomic being applied to scalars explains this one. > and then we have > > type IO_Rec_Type is > record > ... > Reset: Boolean; > pragma Atomic(Reset); > end record; > > The Rationale explains this as follows: > > "By declaring ... Reset to be atomic, the user ensures that reads and > writes of these fields are not removed by optimization, and are > performed indivisibly." > The part about reading and writing not being > optimized away follows because pragma Atomic implies pragma Volatile, > right? Yes, I agree with this. > As for reads and writes being performed indivisibly, Reset is > one bit, so how could a read or write of it be "divisible"? Reset is not necessarily one bit. It may be a size chosen by the compiler (e.g. one word), or determined by a representation clause. Furthermore, if it is one bit in size, it may (indeed it is liekly to) cause normal accesses to it to be divisible. To effect one read access, a typical machine will need to: load the word containing the bit; mask off the rest of the word; perhaps shift the bit along. If this takes several instructions, those instructions will probably be interruptible. Ironically, applying the pragma Atomic to a Boolean object or type may actually cause the compiler to choose a word size for it (when it would have chosen 1 bit otherwise). > To confuse me even further, AARM95 > (http://www.ada-auth.org/~acats/arm-html/AA-C-6.html) says "Pragma > Atomic replaces Ada 83's pragma Shared. The name 'Shared' was > confusing, because the pragma was not used to mark variables as > shared." I'm not sure how the previous Shared pragma had anything to > do with indivisiblity or atomicity, however, so I don't see how Atomic > replaces it. Seemingly contradicting this is the Rationale, which > says "the pragma Shared was removed from the language and replaced by > the pragmas Atomic and Volatile." I'll leave others to comment on this. > Could someone PLEASE help clear things up for me? Perhaps the term > "indivisible" has some other definition that everyone in the world > except me knows about? Any explanation from someone in the know would > be very much appreciated. > > -- thanks, Adam I hope I've cleared some things up! -- Nick Roberts http://www.AdaOS.org * If they were also reads, they would actually be harmless**. ** Except possibly for memory-mapped I/O!