[cpp-threads] Counter strawman proposal :-)

[Peter Dimov]

Boehm, Hans wrote:
> Peter -
>
> It might help to pop up a level here for now.  I'm not quite sure what
> we're trying to accomplish here.

My goal was to attempt to specify a memory model that allows granular 
(hoist/sink)-(load/store) constraints and bidirectional barriers.

> I think the open issues we have are:
>
> 1) We need a correct model.  I think both of our models actually
> currently have similar problems, in that we don't handle some
> synchronization-free race-free code correctly.

I did not attempt to address this issue as I don't consider it a priority, 
or even desirable.

> 2) I'm not sure whether we agree that the semantics of programs with
> data races (on ordinary variables) should be completely undefined.
> This is what the strawman proposal says.  And I think your proposal can be
> easily adapted to say so, too.

True. I don't have an opinion here. My attempts to come up with a compelling 
example where rematerialization is a clear win (even using a two-register 
CPU) have failed miserably :-) and the machinery to deal with the incorrect 
copy propagations must already be in place because of aliasing 
opportunities.

On the other hand, now that I think about it... since the standard makes 
accessing indeterminate values undefined behavior (except for chars), the 
programmers can't take advantage of the stronger model in a portable way.

> 3) My strawman proposal isn't terribly readable, in part because it's
> probably overly abstract.  Your proposal fixed that, perhaps by making it 
> too
> specific. This is a problem if it causes confusion in our group.

Readability isn't terribly important for me, as long as the proposal is 
correct. :-)

It may become a problem if nobody is able to understand it, though.

> 4) We have some terminology differences, which might have some
> associated semantic differences.  My proposal is phrased in terms of
> acquire/release operations, not hoist/sink-barriers.  I would personally
> prefer to stick with the acquire/release terminology, since I think it's
> more widely established. There may be a more substantive difference
> here if you consider something like
>
> (initially everything 0)
> Thread1:  lock(l1); x = 17; unlock(l1); lock(l1); y = 1; unlock(l1);
> Thread2:  lock(l2); r1 = y; unlock(l2); lock(l2); r2 = x; unlock(l2);
>
> Is r1 = 1 and r2 = 0 possible?  In Java, the answer is yes, since the
> two threads operate on distinct locks, and there are thus no
> happens-before relationships between threads.

It's been my intent to allow r1 == 1 && r2 == 0 (if the accesses are 
considered atomic for the purposes of the example) and to not impose 
ordering between T1 and T2. mutex_unlock < mutex_lock only when the two 
operations share the same mutex. Similarly for the placeholder thread_begin 
and thread_end operations; pthread_create is a "release" only with respect 
to the thread being created.