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

[David Abrahams]

Nick Maclaren <nmm1 at cus.cam.ac.uk> writes:

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

Which of the two approaches above is indicated by "that approach" is
ambiguous, so I'm a bit more confused than youare.

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

It is not obvious to me that it would be "equally good" syntactically.

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

Forbids removing what qualification?  We don't have such qualification
in C++ today AFAIK.

And why is it essential that qualification can't be explicitly cast
away?  You can cast everything /else/ away in C++.

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

Really?  You mean Foo const and Foo need not have the same 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.

If you mean dynamic allocation, I don't see the relevance.  AFAICT,
all it needs is maximal alignment, which malloc already has.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com