[cpp-threads] pthreads (was: RE: C++ Connections proposal)

[Boehm, Hans]

> -----Original Message-----
> From:  Peter Dimov
> I personally have no need for the stricter 
> sequentally consistent 
> semantics that make the example
> 
>     if (x == 1) ++y;
> 
>     if (y == 1) ++x;
> 
> well-defined (IIUC), but I'm not qualified to propose a more 
> relaxed memory 
> model.
To amplify:
Yes, we are proposing to make that well-defined, as it is in Java.
My impression, based on one of the few email conversations I've had
with David Butenhof, was that that was probably the intent of the
original Pthreads standard, but they had no way of saying that.

There was substantial discussion of this in the Java context.  I
don't think anything else is viable. Consider the slight variant:

Thread 1: if (the_world_is_ending) fire_all_missiles=true;

Thread 2: if (fire_all_missiles) the_world_is_ending=true;

It would be a bit surprising to discover that this provoked the
end of the world for no reason, because the compiler speculated
the stores.

Note that this is not the same as giving the initial loads of x and y
acquire semantics of some sort.  We are just guaranteeing that if
there is no race in the original code, the compiler won't introduce
one.  Hence there is no way to distinguish a load with acquire
semantics from a plain load.  Hence I think the compiler cost in
this case is essentially zero; no compiler in its right mind would
perform the problematic transformation anyway, I think.

As far as I can tell, there are two places where this hurts in
real compilers:

- Speculative register promotion is mostly out.

- It's unsafe to move code above potentially nonterminating loops.
And it's often very hard for the compiler to prove that loops terminate.

But there may be others.  I don't have enough confidence yet that we've
understood all the consequences of this proposal.
> 
> I am more interested in the library part of the threading 
> iceberg. If my 
> understanding is correct, the sequentally consistent model makes all 
> "correct" pthreads programs well-defined as a side effect, so 
> <pthread.h> 
> (or <cpthread>) becomes a viable alternative for C++ 
> programmers. So in 
> effect pthreads the library interface _is_ being saved by the 
> proposed 
> memory model. 
> 
That's certainly the intent.  I think this issue is essentially
independent of the library piece.  I think some restatement of the
pthread standard will eventually become necessary, but so far I think
we're largely building the language infrastructure to make things
like pthreads (and win32 threads and Boost threads and OpenMP ...)
rigorously correct.

Note again though that we are not really proposing sequential
consistency
as a memory model.  Sequential consistency is used only to define when
there is a data race.  For programs with data races, all bets are off.
This is vastly different from sequential consistency when it comes to
the implementation.

Happens-before consistency in Java is strictly stronger than what we are
proposing here.

Hans