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

[Hans Boehm]

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.

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.

I think that (1) is absolutely essential, at least when applied to
programs with ordinary variables and locks.  Everything else is very
difficult to explain.  When you throw things like unordered atomics and
even tryLock() into the mix, I think things become less clear and more
negotiable.

Hans

On Thu, 14 Jul 2005, Peter Dimov wrote:

> Boehm, Hans wrote:
> > I'm trying to make another pass over the strawman proposal.  Thinking
> > about this, I think I've ended up with somewhat contradictory goals.
> > My wish-list:
> >
> > 1) Data-race-free programs (based on the sequentially-consistent
> > interpretation) have sequentially consistent semantics, at least if
> > they use "ordinary" synchronization primitives. [...]
>
> > Now reconsider Bill's example:
> >
> >>> Initially x = y = 0
> >>>
> >>> Thread 1:
> >>> r1 = x
> >>> if (r1) y = 1
> >>>
> >>> Thread 2:
> >>> r2 = y
> >>> if (r2) x = 1
>
> Why is it important to make the example above well-defined? Even with
> important-sounding variable names as "launch_all_missiles", it still seems
> terribly contrived to me.
>
> 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. This example violates the rule. Why should it be defined? Is it even
> possible for a non-expert to write correct data-race-free code that doesn't
> adhere to the rule? I'm inclined to answer "no".
>
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decadentplace.org.uk
>