Re: Pragma Atomic

[mark.biggar@trustedsyslabs.com]

In article <93g48c$ehk$1@nnrp1.deja.com>,
  Adam Beneschan <adam@irvine.com> wrote:
> 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.

That's a correct interpretation.

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

Not necessarilly, consider reading a 32 bit scalar on a computer
with a 16 bit memory bus, or more likely reading a 64 bit float on
a 32 bit computer.  Also memory cache line boundries can also
effect this.

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

Now consider an ada implementation with 32 bit intergers where the
machine has a single instruction to move multiple bytes that is
interuptable.  The pragma may well mean that you can't use that
instruction to move data into and out of Buffer, but must use a
loop around a gurenteed atomic move instruction..

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

First that is no gurentee that Reset is really only one bit, unless
the record also has a pragma pack or a rep spec, Reset may well
be alocated 32 bits for effecienty reasons.

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

No you have it right, you just didn't considered all the possible
implemtations out there.

--
Mark Biggar
mark.biggar@trustedsyslabs.com


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