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

√iktor Klang viktor.klang at gmail.com
Mon Feb 7 04:34:51 EST 2011


On Mon, Feb 7, 2011 at 10:28 AM, David Holmes <davidcholmes at aapt.net.au>wrote:

> 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.
>
>
Or avoid mutable state when possible and make the factory volatile and the
nuclear property final.



> 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
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions <http://www.scalablesolutions.se>
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110207/0ffce793/attachment-0001.html>


More information about the Concurrency-interest mailing list