[concurrency-interest] Using a volatile variable as a "guard"

Joe Bowbeer joe.bowbeer at gmail.com
Mon Feb 7 06:20:03 EST 2011


Sorry.  Never mind.  Reordering...

(My score for answering volatile questions on this list is now below 50%.)

On Mon, Feb 7, 2011 at 3:04 AM, Joe Bowbeer wrote:

> I forgot to mention a critical assumption in my analysis:
>
> The NuclearFactory's state is "atomic" (well, of course!)
>
> That is, NuclearFactory is a thread-safe immutable object.  Then the
> volatile flag is sufficient to guarantee that if method B sees
> isNuclearFactory=true then it will eventually see the NuclearFactory
> constructed by method A.
>
> If NuclearFactory construction is not atomic (immutable) then all bets are
> off regarding its safe operation by your sample code.
>
> Joe
>
> On Mon, Feb 7, 2011 at 12:57 AM, Joe Bowbeer wrote:
>
> You got it.
>>
>> For the specifics, see 8.3.1.4 and Ch. 17 in the Java Language Spec.
>>
>> http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930
>>
>> In practice, it would be clearer to declare factory to be volatile and to
>> replace isNuclearFactory by a getType() method in the Factory class.
>>
>> Joe
>>
>> On Mon, Feb 7, 2011 at 12:24 AM, Yan Cheng CHEOK wrote:
>>
>> Hello all,
>>>
>>> I came across the article "Java theory and practice: Fixing the Java
>>> Memory Model, Part 2", by Brian Goetz.
>>>
>>> I hope I understand section "New guarantees for volatile" correctly.
>>>
>>> I try to use a similar technique as Brian Goetz's. My objective is :
>>>
>>> A) Never execute factory's operate member function, if it is a
>>> NuclearFactory.
>>>
>>> Hence, I try to turn on volatile guard variable isNuclearFactor, before I
>>> attempt to construct nuclear factory. This is different from Brian Goetz's.
>>> Brian Goetz only write to volatile variable, after he had finished
>>> constructed configOptions.
>>>
>>> I feel the following code should work, based on the information picked
>>> from Brian Goetz's article.
>>>
>>> ""Under the new memory model, when thread A writes to a volatile variable
>>> V, and thread B reads from V, any variable values that were visible to A at
>>> the time that V was written are guaranteed now to be visible to B""
>>>
>>> when thread A writes to volatile isNuclearFactory, and thread B reads
>>> from isNuclearFactory, factory was visible to A as FoodFactory at the time
>>> that isNuclearFactory was written. Hence, factory are guranteed now to be
>>> visible to B as FoodFactory too.
>>>
>>>
>>> I hope I am getting this correctly. Or, do I need to mark factory as
>>> volatile too?
>>>
>>>
>>> void fun_by_thread_A() {
>>>    this.isNuclearFactory = true;
>>>    this.factory = new NuclearFactory();
>>> }
>>>
>>> void fun_by_thread_B() {
>>>    Factory _factory = this.factory;
>>>    if (this.isNuclearFactory) {
>>>        // Do not operate nuclear factory!!!
>>>        return;
>>>    }
>>>    // If out-of-order execution happens, _factory might
>>>    // be NuclearFactory instance.
>>>    _factory.operate();
>>> }
>>>
>>> Factory factory = new FoodFactory();
>>> volatile boolean isNuclearFactory = false;
>>>
>>> Thanks and Regards
>>> Yan Cheng CHEOK
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110207/507bfb3c/attachment-0001.html>


More information about the Concurrency-interest mailing list