From: williamkempf_at_[hidden]
Date: 2001-03-15 19:27:52
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:28 PM 3/15/2001, williamkempf_at_h... wrote:
>
> >> 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.
>
> So if I understand you correctly, on some platforms the hoops you
have to
> jump through are multi-step sequences of platform specific
features. Very
> tricky, but doesn't the logic still hold? You can make it work as
long as
> you follow the platform's rules.
Yes.
> >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.
>
> Yes, understood.
>
> Just out of curiosity, what platforms are we talking about? Are
they
> exotic ones where users expect to have to do a lot of hand
tailoring?
They didn't sound exotic, but I don't recall which platforms were
mentioned explicitly. Search the Usenet for double-checked locking
and memory barriers and you'll probably find the thread I recall
which will do much better at illustrating this stuff than I can do.
Bill Kempf