Re: Help with Atomic_Components and whole array assignment

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

In article
<95Nd6.343422$U46.10481049@news1.sttls1.wa.home.com>,
  "DuckE" <nospam_steved94@home.com> wrote:
> I find the difference in interpretation of AARM C.6(20)
> interesting.

Remember that the AARM is not an official document, and not
part of the official standard, so you can use it to try to
understand the motivation behind the standard, but it never
adds anything.


> My interpretation of this statement is: if my program
> contains two separate assigments to two distinct variables
> for which pragma atomic applies, these assignments will be
> performed as two distinct operations.  Since the two
> assignments appear as separate assignments in the code, if
> the performed these assignments are combined as single
> operation, an update is being performed that my program did
> not specify.

First, this statement is not part of the standard, so you
cannot use it in interpreting what conformance means.

But just for the moment, suppose this statement *were* part
of the standard.

Any *semantic* rule in the standard is always an "as-if" rule.
This is fundamental to the nature of semantic specification.
This means that if two possible translations have the same
semantic effect, then they are equivalent.

So I ask you the same question I asked Tuck, namely please
provide the program that will (at least conceptually) show
that the translation you claim is incorrect is semantically
non-equivalent to separate stores.

The trouble is that the semantic domain of the RM is not
at the right level of abstraction to talk about machine
instructions.

THat's why it is often better and more precise to make
requirements of this kind into implementation advice.

In this particular case, the issue of whether to make
this a requirement or IA did not arise, since it is not
stated as a requirement in any case, and (at least speaking
for myself as a reviewier) I had no idea that the design
team intended this requirement. I thought of pragma Atomic
basically as a renaming of the (confusingly named) pragma
Shared in Ada 83, and it was certainly presented this way.

> Since there is obviously some confusion over this issue
> perhaps the AARM should be revised?

That's irrelevant, since the AARM is not an official document.
The only way to resolve confusion on this issue is to send a
comment following the RM procedures, and have the ARG address
the issue.

I would think that the appropriate approach would be to
introduce implementation advice, something to the effect

Implementation Advice
---------------------

A load or store of an atomic object should, where possible,
be implemented by a single load or store instruction which
accesses exactly the bits of the object and no others. The
implementation should document those instances in which
it is not possible to follow this advice.

-----------
The reason this should be IA is that in IA, we are allowed
to talk about things like load and store instructions, and
we can intepret a statement like this in a helpful pragmatic
manner, whereas if it appeared as a formal requirement, it
would be meaningless (since it contains many undefined terms,
and would be susecptible to the as-if semanitc interpretation
which we specifically do NOT want in this case).

I think it is quite reasonable to consider adding some
IA of this kind. I suspect that most implementations can
follow this easily enough -- what is missing is documentation
of when it is not possible.


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