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,1a4f1da89a53b5ea,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-01-09 14:50:21 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!newsfeed.mesh.ad.jp!nntp1.njy.teleglobe.net!teleglobe.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Pragma Atomic
Date: Tue, 09 Jan 2001 22:44:28 GMT
Organization: Deja.com
Message-ID: <93g48c$ehk$1@nnrp1.deja.com>
NNTP-Posting-Host: 63.206.153.98
X-Article-Creation-Date: Tue Jan 09 22:44:28 2001 GMT
X-Http-User-Agent: Mozilla/4.05 [en] (X11; I; Linux 2.0.34 i686)
X-Http-Proxy: 1.0 x67.deja.com:80 (Squid/1.1.22) for client 63.206.153.98
X-MyDeja-Info: XMYDJUIDabeneschan
Xref: supernews.google.com comp.lang.ada:3841
Date: 2001-01-09T22:44:28+00:00
List-Id: <comp.lang.ada>

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.  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.

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; 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?  As for reads and writes being performed indivisibly, Reset is
one bit, so how could a read or write of it be "divisible"?

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."

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



Sent via Deja.com
http://www.deja.com/