Re: Concurrent access to packed arrays

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

In article <87g0id8939.fsf@deneb.enyo.de>,
  Florian Weimer <fw@deneb.enyo.de> wrote:
> Now my question: Are there in fact platforms where this
> doesn't work? Shall I play safe and apply pragma
> Atomic_Components (and use an
> unpacked array instead of a packed one)?


This is the general issue of independence, which is examined
in detail in Norman Schulman's PhD thesis on shared variables
(NYU, advisor me :-)

Ada 83 was badly messed up here, because it required packing
of packed arrays, and required independence (the ability of
tasks to access different components independently). This
was the result of a last minute editorial change, done in
the proofs, where someone suddently decided that it was a
typographical error that excluded array elements from the
independence rules in section 9.11. Well perhaps it was a
typographical error, but I had always registered this "error"
as a fundamental necessity for correctness, and was appalled
by the change :-) There is no way to implement Ada 83 as
described in the RM in this respect.

The fix for this in Ada 95 is to guarantee independence only
for non-packed arrays, and yes, it is definitely the case
that most certainly there *ARE* platforms where an assumption
of independence for packed strings is quite wrong (generic
alpha is one example, other word addressed machines are another
example).

It is definitely erroneous to have two different tasks access
elements of the same string without synchronization. If you
are asking "can I get away with erroneous code", no one is
going to tell you yes!.

For example, one can imagine a compiler where you have a
call

    procedure K (A : String_Ptr; B : String_Ptr) is
    begin
       ... code where one task works on A and one task works
       ... on B

       (compiler legitimately assumes that A and B cannot
        point to the same string, and generates code based
        on this conclusion).

so that your code malfunctions regardless of the target.

NEVER try to outguess a compiler when it comes to erroneous
code. ALWAYS avoid erroneous code ALL the time.

The proper approach is to use an unpacked array of characters.
On most targets, this will indeed pack, so you will lose
nothing except on targets where what you were trying was
seriously wrong.

The business of Atomic_Components is irrelevant. Indeed I would
say that by definition all components of a packed array are
atomic, because the only way you could tell they were not
atomic was if you had erroneous code where some other task
tried to access a component from the same array without
proper synchronization.




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