[cpp-threads] Re: A hopefully clearer document on POSIX threads

[Doug Lea]

Nick Maclaren wrote:
> 
> 
> Well, that example may not be a big deal, but the generic problem is.
> One of my users had a problem that I deduced had to be that effect.
> I can assure you that explaining it was not easy.
> 
> 

The underlying programming-level issue is that if you want to
rely on a property that is maintained jointly by multiple threads,
then it is unwise to assume it. Instead you should check it, and usually
to retry reads if it does not hold. Even if the hardware can guarantee
transitivity, there are almost always other reasons that the
property might not hold, so the extra guarantee ends up not buying
you anything in practice.

In many ways, this is the same idea as the "always place
condition waits in a loop" programming rule -- it might not always
strictly be required, but assuming it is results in more reliable programs.
(Not merely because it provides more implementation freedom for the runtime,
but because, most likely, you forgot about some case where a notification
does not imply the property you rely on.)

The main impact is on specs. It is challenging to spec this out
in common models that describe effects as reorderings of a global order.

-Doug