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
> >phase of Boost.Threads) will make "atomic_t" compliant on
> >that must have the poor "mutex implementation". In practice I
> >we'll never really use the poor implementation.
> Here is a question to ask yourself. Does the platform's native API
> a call which correctly performs the function desired? Does that
> work correctly when called by various C++ programs?
> If the answer is yes (as it usually is on modern operating
> presumably compilers have used the licence granted by the C++
> 1.9 paragraph 6 to treat that function as "observable behavior".
> didn't, you would not be able to safely call the various system
> So as long as a C++ program relies only on that "observable
> assuming we are OK.
> For a system which doesn't guarantee even its own API's to work
> 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.