[boost] Re: volatile and thread-safety

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-01 17:52:35

"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:un0ck68r9.fsf_at_boost-consulting.com...
>>
>> 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
>>
>> Thoughts?
>>
> This article was _much_ discussed on usenet.
>
> Not everybody agreed with the original article, e.g. David Butenhof in
>
> http://tinyurl.com/pd3g.
> (Subject: Re: volatile, was: memory visibility between threads)

Mistakes about the meaning of volatile and grandiose claims about
preventing all race conditions aside, I was referring to Andrei's
clever hijacking of that dimension of the type system to help ensure
synchronization.  Butenhof seems to agree that it's valuable at least:

   "Though I think your method falls far short of your promises to
    detect all race conditions at compile time (unless applying such a
    limited and unusual definition of "race" that the term becomes
    essentially meaningless), it does have value. What you've done is,
    in some ways, one step beyond the Java "synchronized" keyword. It
    provides not only syntax to require that access be synchronized,
    but your type magic allows the compiler to determine whether, in
    the current scope, the data is already synchronized. (This might
    allow avoiding the Java dependency on expensive recursive
    mutexes. Though I'm not entirely convinced your method would
    survive a complicated application with multilevel lock
    hierarchies, I'm not entirely convinced it wouldn't, either.)"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com