[concurrency-interest] Volatile / Sychronized?

First Last chancer357 at hotmail.com
Tue Dec 19 22:50:13 EST 2006

Thanks very much for the answers.

>>Question #1:
>No, this example works, as you perform a write to v, followed by a read of 
>v.  Making x volatile has no real effect on this code in isolation. The 
>paragraph you quoted is meant to prevent people from assuming that a write 
>to a volatile will act as a memory barrier; writing to a volatile variable 
>won't necessarily flush values to memory unless there is a subsequent read 
>of that same volatile variable.

Ok, so the pitfall is to assume volatile alone is enough, rather
you must use volatile along with a write and a read to that volatile
field - in that order.

I can't really think of an example of what this would like, should someone
code the mistake, unless they just removed the check of the volatile flag
completely before reading x because they thought the write was enough,
which kind of seems silly.

>>Question #2:
>The canonical example is double-checked locking:
>   class Foo {
>         private volatile Helper helper = null;
>         public Helper getHelper() {
>             if (helper == null) {
>                 synchronized(this) {
>                     if (helper == null)
>                         helper = new Helper();
>                 }
>             }
>             return helper;
>         }
>     }
>This allows the reader not to synchronize when the object has already been 
>constructed.  The synchronization is necessary for mutual exclusion; it 
>makes sure that the helper field is null when the object is constructed and 
>the field is assigned its value.

Ok, so this just makes sure there is only one object instantiation
of Helper, and makes sure there is only assignment. Nothing at
all to do with a partially completed constructor. I see.

Explicitly synchronizing a write to a volatile field seems to be silly,
to me now unless I am synchronizing some other action around
the write as in your DCL example.

>>Question #3:
>>I have seen it suggested that one scenario which the synchronized is 
>>required would be to ensure the completion of a constructor before the 
>The end of the constructor happens-before the assignment to buffer in this 
>example.  In fact, any statements that get executed in this thread before 
>the assignment to buffer happen-before the assignment to buffer -- this 
>includes calls not just the constructor, but calls to other methods and so 

Just to be clear, I can rely on the runtime and the compiler not to
reorder anything oddly. The object will be fully constructed before
the assignment to the volatile makes anything visible to other threads.

>>Question #4:
>>Is there any use for AtomicBoolean or AtomicReference if we don't care 
>>about CAS semantics?
>>In other words, if all I want is to not use the word synchronized is all I 
>>need to do add "volatile",
>>kick back and enjoy?
>It shouldn't be a problem for you to do this right now.

Is it fair to say the only reason to use Atomic* classes is for CAS

Get FREE Web site and company branded e-mail from Microsoft Office Live 

More information about the Concurrency-interest mailing list