Re: [boost] RFC: Multithreading design constraints

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-06-08 07:33:15

From: David Abrahams <abrahams_at_[hidden]>
> From: "John Maddock" <John_Maddock_at_[hidden]>
> > The problem is that unless the compiler knows that a lock is in some way
> > "special", it can not know that the lock has an effect on observable
> > behaviour - my point was to try and show that we can "trick" a compiler
> > that knows nothing about threads into behaving the right way by defining
> > the lock methods as being externals - even now we are relying on the
> > compiler not performing some kind of global analysis.
> 
> Excuse me, but isn't that what "volatile" is supposed to be for?

I fear John may be right here.  Volatile may prevent a variable
from being put in a register, or an apparently useless operation
being optimized away, but it can't prevent the compiler from, say,
incrementing another variable, supposedly controlled by a lock,
from after the lock to before it.

However, if the lock is acquired via an OS call, and the compiler
is supposed to do multithreading on that OS, then the compiler
had better not do the wrong thing.  And if the hardware might do
the wrong thing the compiler should strive to prevent it.  But
that means that the OS call had better be visible to the compiler.
and not hidden inside another, non-inlined function.