Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-15 16:28:13

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 03:18 PM 3/15/2001, williamkempf_at_h... wrote:
> 
>  >I haven't missed the problem.  The C++ "volatile" with platform
>  >specific memory barriers (a concept I've been considering for a 
later
>  >phase of Boost.Threads) will make "atomic_t" compliant on 
platforms
>  >that must have the poor "mutex implementation".  In practice I 
expect
>  >we'll never really use the poor implementation.
> 
> Here is a question to ask yourself.  Does the platform's native API 
provide 
> a call which correctly performs the function desired?  Does that 
function 
> work correctly when called by various C++ programs?
> 
> If the answer is yes (as it usually is on modern operating 
systems), then 
> presumably compilers have used the licence granted by the C++ 
standard's 
> 1.9 paragraph 6 to treat that function as "observable behavior".  
If they 
> didn't, you would not be able to safely call the various system 
API's from 
> C++.
> 
> So as long as a C++ program relies only on that "observable 
behavior" I'm 
> assuming we are OK.
> 
> For a system which doesn't guarantee even its own API's to work 
from C++, 
> then all bets are off.
> 
> Am I missing something?

Just a small detail.  A classic example is the "Double-Checked 
Locking Optimization" pattern.  On MP (multiple processor) machines 
the machines architecture does some optimizations that can result in 
this pattern not working.  In addition to language constructs such as 
volatile you need to use a platform specific "memory barrier" to 
insure the CPU(s) don't optimize the code in such a way as to cause 
incorrect behavior in this pattern.  The atomic_t type built on using 
a mutex may be subject to this same error (this goes beyond my 
expertise on the subject).  There was a recent thread on this subject 
on the Usenet.

The point is, however, these issues can all be addressed in a 
platform specific manner with out the need for a change to the 
interface of atomic_t.

Bill Kempf