Using 'final' with local variables
in [Java Help]
|
Prev: inheriting a main method
Next: Adding int to a float
From: Scott A. Hightower on 16 Sep 2009 11:59 "Roedy Green" <see_website(a)mindprod.com.invalid> wrote in message news:3tv1b5l2lf0ua9n0gem0urvc6p1mc8cceh(a)4ax.com... > On Tue, 15 Sep 2009 06:16:06 -0700, markspace <nospam(a)nowhere.com> > wrote, quoted or indirectly quoted someone who said : > >> volatile boolean done = false; >> >> while(!done) >> processData(); >> >>"done" will be hoist out of the loop with out the volatile modifier, > > > A local variable is by definition local to a single thread. They can't > be volatile since no other thread can see them. Each thread running a > method has its own stack and hence its own copy of each local > variable. That is one of the beauties of local vs instance variables. > True--if this snippet were wholly contained within a method body. There is no indication where the variable is declared.
From: Dave Searles on 17 Sep 2009 02:46 Scott A. Hightower wrote: > "Roedy Green" <see_website(a)mindprod.com.invalid> wrote in message > news:3tv1b5l2lf0ua9n0gem0urvc6p1mc8cceh(a)4ax.com... >> On Tue, 15 Sep 2009 06:16:06 -0700, markspace <nospam(a)nowhere.com> >> wrote, quoted or indirectly quoted someone who said : >> >>> volatile boolean done = false; >>> >>> while(!done) >>> processData(); >>> >>> "done" will be hoist out of the loop with out the volatile modifier, >> >> A local variable is by definition local to a single thread. They can't >> be volatile since no other thread can see them. Each thread running a >> method has its own stack and hence its own copy of each local >> variable. That is one of the beauties of local vs instance variables. >> > > True--if this snippet were wholly contained within a method body. There is > no indication where the variable is declared. Here is the original context: > rossum wrote: >> >> I am talking about local variables, not member variables. > > I was just re-reading in Java Concurrency in Practice that some modifiers are important, because the JIT/javac will hoist variables out of loops: > > volatile boolean done = false; > > while(!done) > processData(); The discussion is clearly about local variables.
From: Scott A. Hightower on 17 Sep 2009 13:01 "Dave Searles" <searles(a)hoombah.nurt.bt.uk> wrote in message news:h8sm0k$lp1$1(a)news.eternal-september.org... > Scott A. Hightower wrote: >> "Roedy Green" <see_website(a)mindprod.com.invalid> wrote in message >> news:3tv1b5l2lf0ua9n0gem0urvc6p1mc8cceh(a)4ax.com... >>> On Tue, 15 Sep 2009 06:16:06 -0700, markspace <nospam(a)nowhere.com> >>> wrote, quoted or indirectly quoted someone who said : >>> >>>> volatile boolean done = false; >>>> >>>> while(!done) >>>> processData(); >>>> >>>> "done" will be hoist out of the loop with out the volatile modifier, >>> >>> A local variable is by definition local to a single thread. They can't >>> be volatile since no other thread can see them. Each thread running a >>> method has its own stack and hence its own copy of each local >>> variable. That is one of the beauties of local vs instance variables. >>> >> >> True--if this snippet were wholly contained within a method body. There >> is no indication where the variable is declared. > > Here is the original context: > >> rossum wrote: >>> >>> I am talking about local variables, not member variables. >> Begin partial text from markspace post. >> I was just re-reading in Java Concurrency in Practice that some modifiers >> are important, because the JIT/javac will hoist variables out of loops: >> >> volatile boolean done = false; >> >> while(!done) >> processData(); End partial text from markspace post. > > The discussion is clearly about local variables. No argument there. However, this sub-thread is about a snippet and commentary provided by markspace (not the OP) to illustrate that some modifiers are important. Somehow, the text of his post is incomplete at this point. His post might be irrelevant, since the thread is about local variables and specifically about the final modifier, but the example does not contain the final modifier, does not shed any light on its effect and in its proper context cannot depend upon a local variable. I'll leave that to someone else to decide whether it is worth further comment. Yes, if the variable is local, the loop will never exit normally. For the newcomers who do read this newsgroup, consult your concurrent programming text and you will probably find that same snippet.
From: Arne Vajhøj on 17 Sep 2009 21:51 Dave Searles wrote: > Scott A. Hightower wrote: >> "Roedy Green" <see_website(a)mindprod.com.invalid> wrote in message >> news:3tv1b5l2lf0ua9n0gem0urvc6p1mc8cceh(a)4ax.com... >>> On Tue, 15 Sep 2009 06:16:06 -0700, markspace <nospam(a)nowhere.com> >>> wrote, quoted or indirectly quoted someone who said : >>> >>>> volatile boolean done = false; >>>> >>>> while(!done) >>>> processData(); >>>> >>>> "done" will be hoist out of the loop with out the volatile modifier, >>> >>> A local variable is by definition local to a single thread. They can't >>> be volatile since no other thread can see them. Each thread running a >>> method has its own stack and hence its own copy of each local >>> variable. That is one of the beauties of local vs instance variables. >>> >> >> True--if this snippet were wholly contained within a method body. >> There is no indication where the variable is declared. > > Here is the original context: > >> rossum wrote: >>> >>> I am talking about local variables, not member variables. >> >> I was just re-reading in Java Concurrency in Practice that some >> modifiers are important, because the JIT/javac will hoist variables >> out of loops: >> >> volatile boolean done = false; >> >> while(!done) >> processData(); > > The discussion is clearly about local variables. It is clearly not - at least not if it is Java and given the group and the code snippets I think we can assume it is Java. Java does not allow volatile keyword on local variables. Arne
From: Arne Vajhøj on 17 Sep 2009 21:52
Dave Searles wrote: > markspace wrote: >> rossum wrote: >>> >>> I am talking about local variables, not member variables. >> >> I was just re-reading in Java Concurrency in Practice that some >> modifiers are important, because the JIT/javac will hoist variables >> out of loops: >> >> volatile boolean done = false; >> >> while(!done) >> processData(); >> >> "done" will be hoist out of the loop with out the volatile modifier, >> resulting in an infinite loop. > > Since that loop cannot set "done" the loop is infinite anyway (barring > an uncaught exception or System.exit() call beneath processData() > somewhere). Nothing is preventing processData from setting done to true. Arne |