$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-10-02 02:12:47
"Stefan Seefeld" <seefeld_at_[hidden]> wrote in message
news:802ff81e9701627728005236508f3f433f7b3e5b_at_Orthosoft.ca...
> David Abrahams wrote:
> > I had heard Andrei did something like this a while ago, but I missed
> > the details until just now, when I stumbled across the article at
> > http://www.cuj.com/documents/s=7998/cujcexp1902alexandr/. I was a
> > little disappointed at first because I always imagined something much
> > more sophisticated, but the simplicity of Andrei's technique is also
> > its beauty. I wonder if it makes sense for us to implement:
> >
> > a. A coding guideline in which threadsafe member functions are
> > volatile
> >
> > b. Some infrastructure similar to his LockingPtr
>
> I remember the article, and I also remember long and heated discussions
> in comp.lang.c++[.moderated] and comp.programming.threads. Many
> arguments were brought forward concerning the relation between
> the volatile keyword and all the different memory types a computer
> (more precisely: a CPU) may or may not possess.
>
> Andrei is only talking about registers, but not about CPU caches (L1,
> L2), or about memory barriers. IIRC, people in the end agreed that
> using volatile is by no means a guarantee for thread-safe access to
> memory, at least not in multi-processor architectures.
That was the general agreement. People also agreed that that wasn't at all
the point of the article, either.
Andrei