[boost] Re: volatile and thread-safety

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-10-02 02:12:48

"Alexander Terekhov" <terekhov_at_[hidden]> wrote in message
news:3F7B3FD3.DC49D0DE_at_web.de...
>
> 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/.
>
> Sorry, but this is kinda "Most Famous King of Trolls" article. Really.

Hard to keep blood pressure down while responding to this one :o). But as
they say, any publicity is good publicity.

> c.l.c++.mod: (Subject: Re: volatile -- what does it mean in
> relation to member functions?)
>
> http://groups.google.com/groups?selm=3D934ECB.8CD73030%40web.de
> http://groups.google.com/groups?selm=3D99EF5F.B9D8C5B8%40web.de
> http://groups.google.com/groups?selm=3D9B7791.1780A701%40web.de

The thing is, this article has raised much negative discussion within the
threads community. People who really know threads (and have the scars to
prove it) are quite sensitive to the subject because the process is
traumatic. Indeed, you can't learn threads until they rip a leg of yours and
beat you to death with it.

The true problem is that the introduction of the article, which gives a
wrong example and explanation, is all some people have read and understood.

The real technique, which is useful and valuable, was overlooked because of
that bad first section.

The only potential problem with the technique, problem that is rather
pedantic, is that objects shared between threads should not be created as
volatile (as the article prescribes). They should be created as non-volatile
and then manipulated through volatile references. That gives 100% legitimacy
to the const_cast that later on (when the object lock is acquired) keeps in
sync the type modifier with the locked state of the object.

> >                                                            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
>
> Nope.

"Nope" like in, "Nope, I don't understand"?

> >   b. Some infrastructure similar to his LockingPtr
>
> Nope.

Idem? :o)

> >
> > Thoughts?
>
> Andrei[/CUJ] should really pull it off.

Sure. They can't take any royalties back I hope :o).

I believe there are two streaks in the article that render many people
confused.

One is that pthreads people, whenever they see volatile in an article on
threads, they become suspicious because the pthreads standard makes it clear
that volatile is not needed as long as the Posix synchronization primitives
are used. This sets the stage for misunderstandings. The second (and where
the meat can be found) is, the technique presented uses only volatile's
participation to the type system. There are no uses or assumptions of the
*semantics* of volatile at all. Indeed, if you follow through, you'll notice
that there's no access to volatile data: all data is accessed only after the
'volatile' adornment, which is there just to keep the type system in sync
with the locking state of the object, has been removed.

I'd enjoy rewriting that article if I had a chance to travel back in time.
The rewrite would change the introduction completely, and will give more
explicit warning against confusions. But it would describe the same basic
technique, which I believe is sound: the locking state of an object is
described by a modifier. Also, the "grandiose" claims would be mollified, to
rid the author of being the target of gratuitous ironic remarks down the
road.

I didn't care much about volatile's precise semantics at the time; I figured
out how it can be used to signal state, and that was all I needed. The
introduction was just, well, an introduction, and yes, it was badly written.
(Though I've seen that crappy example in a couple other places.)

Andrei