comp.lang.ada
 help / color / mirror / Atom feed
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!







  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