Re: Help with Atomic_Components and whole array assignment

[Robert Dewar <robert_dewar@my-deja.com>]

In article <3A76E3B9.BD806841@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> I don't agree with Robert's reading of this.  It seems very
> clear that you cannot combine multiple updates of separate
> atomic objects into a single write.

I disagree with Tuck. Please provide a test program where it
would be theoretically possible to determine that combining
writes had a semantic effect.

> One of the whole points of atomic
> is to make each write separate and indivisible.

Indivisible, yes. Separate no. You may have intended to say
this, and you may have thought it, but I don't see that the
RM says, or even implies this.

> It was designed specifically to address issues relating to
> "active" memory, where breaking the write down into multiple
> writes, or combining multiple writes into a single write,
> would confuse the device.

This is a total surprise to me, and certainly there is nothing
in the RM that would reveal this hidden design intent. For
example, an implementation which locks the bus and then does
a whole sequence of writes for an atomic variable, and then
unlocks the bus, CLEARLY meets the semantics of the RM.

This is a case of the designer reading more into what's there
than what was written. My own view is that it is almost
impossible to achieve the design goal that Tuck quotes, except
on an implementation advice basis. I had no idea that the
design team had this view of pragma Atomic (because nothing
they ever wrote in the RM implied this viewpoint).

Note that the detailed list in AARM C.6(20) of disallowed
transformations has no hint at all of the "separate" part of
Tuck's claim, and conspicuously does not list combining writes
as an improper transformation.

Tuck, having something in your mind is not good enough if you
do not write it down :-)

> In general, that means each read/update is a separate
> instruction.

No, there is absolutely NO implication of this

> Which particular instruction is not specified, though of
> course in most cases it will be a load or a store.

> I don't agree with the advice of slipping into machine code
> to accomplish all of these kinds of things, if atomic can do
> the job.

But it can't! In particular, suppose you have four atomic
byte variables next to one another. It is perfectly fine to
do a word load followed by a shift and mask, but likely this
would play havoc with memory mapped I/O.


> I would agree that with the original code, which used an
> aggregate assignment, there is no requirement to perform that
> as separate byte assignments.  However, if the code is
> written as a sequence (or a loop) of separate assignments,
> and the objects are atomic, it is a bug (in my view) if the
> compiler combines these assignments  into a single
> assignment.

You repeat this, but the RM does not support this view point.

> Similarly, reordering such assignments
> would be a bug, since it would change the external effect of
> the program in an impermissible way.

No, this is not similar at all. Everyone agrees that reordering
is not permitted, because you can see external effects not
corresponding to the canonical order. The RM is quite explicit
in this case, and indeed AARM C.6(20.c) gives an explicit
example of this not being allowed, but the AARM does not list
combining.

Too bad you did not list the combining case in the AARM Tuck,
then we would at least have known what was in your mind, and
could have discussed the point that the RM wording does not
happen to capture this intent (and as I say, I think it would
be almost impossible to capture this intent).

For all the examples in AARM C.6(20), you can devise simple
pure Ada tests that can conceptually malfunction because of
a task switch at a bad point (it may be tricky to actually
do the run that fails, since it depends on very precise
timing). But for the combining case, you cannot devise a
pure Ada test that even conceptually fails.

The idea that pragma Atomic solves this problem is an old
confusion, going way back to Ada 83 days, I thought we had
put that to rest in Ada 95, because we never discussed the
idea that Atomic *did* solve this problem. I am somewhat
amazed to see the claim that it was addressed :-)



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