From: "Nick Roberts" <nickroberts@callnetuk.com>
Subject: Re: Pragma Atomic
Date: Wed, 10 Jan 2001 17:53:02 -0000
Date: 2001-01-10T17:53:02+00:00 [thread overview]
Message-ID: <93i7oi$a6laq$2@ID-25716.news.dfncis.de> (raw)
In-Reply-To: 93g48c$ehk$1@nnrp1.deja.com
"Adam Beneschan" <adam@irvine.com> 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!
next prev parent reply other threads:[~2001-01-10 17:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-09 22:44 Pragma Atomic Adam Beneschan
2001-01-09 23:16 ` mark.biggar
2001-01-10 4:27 ` Robert Dewar
2001-01-10 17:53 ` Nick Roberts [this message]
2001-01-11 14:00 ` Tucker Taft
2001-01-11 15:06 ` Nick Roberts
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox