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

David Holmes davidcholmes at aapt.net.au
Mon Feb 7 04:28:14 EST 2011

You need factory to be volatile too so that the two variables maintain their
respective ordering. Otherwise the write to the factory can move before the
write to the flag:

    this.factory = new NuclearFactory();
    this.isNuclearFactory = true;

and now thread B can get a NuclearFactory but see isNuclearFactory before it
was set to true.

There has been a bit of discussion on this recently. The use a volatile flag
ensures data is visible when needed, but doesn't prevent it being visible
earlier. In this example you need strict ordering, or atomicity, to make
sure that a NuclearFactory is only ever seen when isNuclearfactory is set.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yan
> Cheng CHEOK
> Sent: Monday, 7 February 2011 6:25 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Using a volatile variable as a "guard"
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list