[cpp-threads] Implicit Synchronization

[Boehm, Hans]

We do have the advantage in the C++ level interface that we can introduce convenient syntax that uses safer defaults.

We currently propose to have assignment translate to a store<release> and conversion to the base type to translate to a load<acquire>.  Thus double-checked locking should just work so long as the flag or pointer is atomic.

Herb and I were discussing adding non-template overloads of atomic read-modify-write operations that are equivalent to the ordered or full variant.  Thus the more naïve users should at least get the safer variants.  I think this is probably a good idea.

I'm still open as to whether assignment should actually be a store<release> followed by a fence.   That would hopefully give you the Java semantics for programs that used only volatiles.  (There's a proof required here that I don't have in hand.)  Perhaps there should be a store<ordered> that also has those semantics.

My sense is that moving completely to the (safer, more expensive) Java volatile semantics will make some people here very unhappy.  Providing all the current alternatives, but making the safer ones easier to spell, seems to be the best compromise.  (Remember that the current set of alternatives is already severely pruned from what was suggested earlier.)

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Peter Dimov
> Sent: Tuesday, July 11, 2006 8:54 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Implicit Synchronization
> 
> Doug Lea wrote:
> > Lawrence Crowl wrote:
> >> One of the things we must make sure we address is the implicit 
> >> syncronization that we expect in the data that we guard 
> with locks.  
> >> For example, with double-checked locking for sharing variable 
> >> initialization, we cannot define only the synchronization on the 
> >> locks, but also on the variable being initialized.  Likewise, for 
> >> reference-counted objects, we must know that on (atomically) 
> >> decrementing the count to zero, reading the pointer must result in 
> >> the value written.
> >> 
> > 
> > This is a very good point, that we encounter all the time 
> developing 
> > java.util.concurrent: You often need heavier barriers than you'd 
> > otherwise expect, to make sure that if some less-than-fully 
> > thread-safe object is, for example, placed in a hash table by one 
> > thread, that it is guaranteed readable by others retrieving it.
> > 
> > You can say all you want in specs that people shouldn't 
> expect this to 
> > work, but they will, and so unless you do this part, users will 
> > encounter what they claim are bugs.
> 
> Why shouldn't people expect this to work?
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>