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

[Nick Maclaren]

Doug Lea <dl at cs.oswego.edu> wrote:
> 
> Sorry for not being clear about the context. I believe that the current
> discussion by Nick et al surrounds whether we can use ANY kind of qualifier. If
> we can't then we surely can't use volatile, or __async_volatile or atomic etc.
> If we can use one of these, then the details can be put back up for negotiation.
> But given the discussions about qualifiers etc, it doesn't seem to me
> that we can revive this proposal. The main problem is that
> we only care about and can give semantics for simple scalar types.
> We don't know what to make of the others, and other
> parts of the C and C++ specs don't seem to give us room to
> do anything reasonable.

Yes and no.  I think that there is a little more.  The issue with
whether we can use qualifiers is not just whether the standard's
wording permits it or could be tweaked, but how pervasive the
assumption is that qualifiers do not affect ANY aspect of size,
representation or alignment.  And your conclusion may well be right,
on the latter grounds if not the former.

I am pretty sure that it would impact almost no clean programs or
compilers, but there may be a hell of a lot of important, unclean
ones out there.  The case of struct alignment and the X Windowing
System and clones springs to mind - yes, C had to be changed (and
I mean had to) to permit a particular unclean programming practice.

Yes, rocking the qualifier boat may well be too risky, no matter
what the legalistic reading of the standard's wording says.


The second is orthogonal, and is what should be specified in the
standard, whether it is done in the main language, in a template
class or whatever:

    a) Just a very basic set of facilities that can be implemented
on most (75%?, 95%?) of current and likely architectures.

    b) A more general model that could include all POD types,
provided that they were created for atomic use.

    c) A fully general model that could be extended to arbitrary
object types.

What I was trying to suggest (propose is too strong a word) is that
the target should be (a) as required facilities and (b) as permitted
ones.  I.e. the specification should be such that implementations
could choose to do anything between (a) and (b).  Programmers should
use (a) for portability, but experience with (b) could give guidance
for how the facility could be extended in a future version of C++.

And I was saying that the wording should be such that implementors
should NOT need to get the hardware or operating system changed to
implement anything in that range.  Experience from the past is that
kills any hope of decent implementations - where the hardware and
operating systems ARE changed for such reasons, they usually get it
badly wrong :-(


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