[cpp-threads] RE: volatile, memory models, threads

[Nick Maclaren]

"Boehm, Hans" <hans.boehm at hp.com> wrote:
>
> There seem to be very mixed opinions within our group on the subject of
> either redefining volatile or adding a different volatile-like type
> qualifier.  My impression is that the C++ committee is actually more
> favorably inclined towards that approach, but the detailed implications
> haven't been considered.

That seems to summarise the state nicely!

> If we can get reasonable syntax out of a library-based approach, I'm not
> sure there's a strong argument for touching volatile.  (Divergence from
> Java bothers me a bit, but this is in a fairly esoteric area, which we
> can probably live with.  I do think we want to avoid making the teaching
> of concurrent programming any harder than it inherently has to be.  And
> designing fundamentally inconsistent concurrency facilities into
> different languages without good reason is certainly one way to make it
> harder.)

While I agree with 90% of that, and it is obvious that any action
on atomic objects can equally well be implemented by operations
or library calls, the real issue is data layout.  My apologies for
the following, if it has already been spelled out, but I want to be
sure that we are not at cross-purposes.

Many architectures require data that may be used atomically to be
laid out in a special way - perhaps aligned more restrictively than
normal data, perhaps with extra space for a lock, perhaps by putting
it in a special segment of memory.  It is therefore essential that
all data that may be used atomically is flagged as such during its
initial definition, and that its qualification cannot be added by
implicit or explicit casting (C99/C++ already forbids removing it).

In particular, this means that volatile (for which that can happen)
is NOT adequate for implementing atomic types on such architectures,
unless the implementation degrades itself by implementing everything
as atomic.  Consider:

static struct {int pete;} alf[3];

int main (void) {
    int volatile *joe;
    joe = &alf[2].pete;
    return 0;
}

Both C99 (6.2.5/25) and C++ (3.9.3/1) require qualified types to have
the same representation and alignment, but not size, which makes all
the above possible - even if painful on an implementation that needs
to add a lock.  But it does mean that the allocation of memory must
be atomic-aware, possibly down to the detailed layout.  What I am not
sure about is whether the malloc-equivalent can get away with knowing
only the size.

My GUESS is that it needs only the size and the fact that this is an
atomic object, in which case an all-library solution is trivial, but
I cannot convince myself that I have thought of all possible problems.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679