[cpp-threads] sequential consistency for race-free programs

[Peter Dimov]

Hans Boehm wrote:
> Peter -
>
> In Bill's example, no shared variables are written by either thread.
> It's hard to tell people that they need to lock when there is no
> concurrent write.

Let's get back to the simple rule:

>> The "data-race-free" rule, as taught to programmers, is simple: an
>> ordinary variable that is shared between threads shall never be
>> accessed without a lock.

Note that this is a local rule. You review the code:

>>>>> Thread 1:
>>>>> r1 = x
>>>>> if (r1) y = 1

and you can immediately tell that it violates it. The shared variable x is 
being read without a lock. The shared variable y is being written without a 
lock. The code is broken (according to the rule). You don't need to 
enumerate all possible candidate executions to reach this conclusion, or 
know what the other threads are doing. The code for the other threads may 
even not have been written yet.

I maintain that adhering to this rule is the only reasonable way for an 
ordinary programmer to write correct MT code.

I, personally, would never attempt to write this kind of data-race-free code 
even if it's technically legal to do so. From my perspective, trying to 
legalize this example has significant cost and brings no benefit.

The reason that taking advantage of this is hard to unworkable is that it 
requires a global analysis of the program. Proving that anything beyond a 
toy example is data-race-free seems insanely hard. Convincing a compiler 
author that his optimizations break conforming code would be even harder. 
Therefore, from a programmer's perspective, it would be reasonable to avoid 
such code or outlaw it via a coding standard.

> Think of x and y as both being named something synonymous with
> "application_is_single_threaded".  In that case, this code looks
> obviously safe.  In my opinion, making it undefined is clearly
> unacceptable.
>
> The intent of the pthread spec is also pretty clearly to allow things
> like this.  Thus in addition to being completely inconsistent with
> the Java spec, we'd be breaking Pthread code that was clearly
> intended to be legal.

We wouldn't be _breaking_ it. We won't _guarantee_ that it will work. 
Nothing guarantees its correctness today, so the status of the code doesn't 
change.