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)
> >the machines architecture does some optimizations that can result
> >this pattern not working. In addition to language constructs
> >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
> >incorrect behavior in this pattern. The atomic_t type built on
> >a mutex may be subject to this same error (this goes beyond my
> >expertise on the subject). There was a recent thread on this
> >on the Usenet.
> So if I understand you correctly, on some platforms the hoops you
> jump through are multi-step sequences of platform specific
> tricky, but doesn't the logic still hold? You can make it work as
> you follow the platform's rules.
> >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
> exotic ones where users expect to have to do a lot of hand
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk