Re: [boost] RFC: Multithreading design constraints

From: Beman Dawes (beman_at_[hidden])
Date: 2000-06-08 08:57:40

At 06:33 AM 6/8/00 -0600, Greg Colvin wrote:

>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.

I assume the behavior under discussion is that described in 1.9
Program Execution paragraph 6 plus footnote 6:

"The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions/6."

Footnote 6: "An implementation can offer additional library I/O
functions as an extension. Implementations that do so should treat
calls to those functions as ‘‘observable behavior’’ as well."

Note the words "library I/O functions" rather than functions in
general.  Also that there isn't any wording about this applying only
within a translation unit.

Can we assume a compiler (which may be multi-platform, like
Metrowerks or egcs) treats operating system function calls like
"library I/O functions"?  That seems risky.  Volatile seems a safer
way to force sequence, at least based on that one sentence in the
standard.

--Beman