tag:blogger.com,1999:blog-8405107760807432973.post2351268873622685547..comments2024-01-04T09:55:32.459-08:00Comments on Java Concurrency (&c): Loop Invariant Code Motion and the Java Memory ModelJeremy Mansonhttp://www.blogger.com/profile/04241094734813086257noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-8405107760807432973.post-50765490394121364002009-04-22T00:14:00.000-07:002009-04-22T00:14:00.000-07:00@bank kus - LoadLoad barriers on x86 are a no-op b...@bank kus - LoadLoad barriers on x86 are a no-op because the memory consistency barriers make them unnecessary, not because that level of consistency is unavailable. Specifically, every two instructions on x86 behave as if there is an intervening LoadLoad barrier. The JSR-133 cookbook is right - basically, no explicit coherence operations are needed for volatile reads, and a StoreLoad is neededJeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-56464952870315568112009-04-18T22:20:00.000-07:002009-04-18T22:20:00.000-07:00Perhaps you ve answered this in some other blog bu...Perhaps you ve answered this in some other blog but I m trying to figure out what barriers are involved with volatile load/stores:<br /><br />T0:<br />store(volatile_var, 1)<br />load(volatile_var)<br />.....<br />....<br />load(volatile_var)<br /><br />T1:<br />store(volatile_var, 30)<br /><br />Assuming the way the interleaving goes as follows: T1's last store happens before T0's last load, I Unknownhttps://www.blogger.com/profile/13146717826433502399noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-12401639286550343792008-11-10T04:41:00.000-08:002008-11-10T04:41:00.000-08:00Well said.Well said.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-44220153333112125582008-04-11T09:17:00.000-07:002008-04-11T09:17:00.000-07:00Thanks. Had this doubt lingering in my mind for so...Thanks. Had this doubt lingering in my mind for sometime.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-74159963549480006512008-04-11T02:36:00.000-07:002008-04-11T02:36:00.000-07:00That is correct.ps: if the variables are local and...That is correct.<BR/><BR/>ps: if the variables are local and not instance variables, other threads are not able to see the variables. So your example is not going to lead to reordering/visibility problems.pveentjerhttps://www.blogger.com/profile/17847641595368096163noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-69292166468684253292008-04-11T02:28:00.000-07:002008-04-11T02:28:00.000-07:00So what this means istry { int a = 0; int b = 1;...So what this means is<BR/><BR/>try {<BR/> int a = 0;<BR/> int b = 1;<BR/>} catch(Exception e) {<BR/>}<BR/><BR/>The compiler is free to reorder the above.<BR/><BR/>There are chances that one thread might see the above as <BR/>int a = 0; int b = 1;<BR/><BR/>whereas another might see it as<BR/>int b = 1; int a = 0;Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-11815923530577572512008-04-11T02:18:00.000-07:002008-04-11T02:18:00.000-07:00Thank you guys.Thank you guys.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-38123399618775245232008-04-10T22:57:00.000-07:002008-04-10T22:57:00.000-07:00Mostly what Peter said. If you have:class Foo { ...Mostly what Peter said. If you have:<BR/><BR/>class Foo {<BR/> Object o = new Object();<BR/> void Thread1() {<BR/> o = null;<BR/> }<BR/> void Thread2() {<BR/> if (o == null) return;<BR/> try {<BR/> int x = o.hashCode();<BR/> } catch (NullPointerException e) {<BR/> }<BR/> }<BR/>}<BR/><BR/>You still have to catch the NPE if Thread1 sets o to null after the if statement Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-69893131209094454242008-04-10T13:38:00.000-07:002008-04-10T13:38:00.000-07:00If instructions can't cause exceptions like a simp...If instructions can't cause exceptions like a simple assignment, I don't see the problem of moving these instructions from above to inside and vice versa, as long it doesn't violate the within-thread as-if-serial semantics of the code.pveentjerhttps://www.blogger.com/profile/17847641595368096163noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-83081664472506661052008-04-10T12:19:00.000-07:002008-04-10T12:19:00.000-07:00Hey Jeremy,JMM ensures that code within a synchron...Hey Jeremy,<BR/><BR/>JMM ensures that code within a synchronized block will not be reordered but is it true for code within a try block also?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-82019818520845149522008-02-10T11:59:00.000-08:002008-02-10T11:59:00.000-08:00Peter -- this is absolutely true. The real proble...Peter -- this is absolutely true. The real problem here from the point of view of Java semantics is the lack of a happens-before relationship, which I am sure is defined in another blog entry somewhere.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-13425252140284632472008-02-10T10:09:00.000-08:002008-02-10T10:09:00.000-08:00Hi Jeremy,Next to the reordering problem the code ...Hi Jeremy,<BR/><BR/>Next to the reordering problem the code is also subject to visibility problems (when a normal variable is used instead of a volatile one). The 'victim' thread doesn't need to see the most recently written value, and therefore could keep seeing the initial value which effectively changes the loop to an infinitive one. <BR/><BR/>ps: I add this comment to make this post more pveentjerhttps://www.blogger.com/profile/17847641595368096163noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-5819193590038304102007-03-27T20:23:00.000-07:002007-03-27T20:23:00.000-07:00This is the same code, more or less, so the exact ...This is the same code, more or less, so the exact same argument applies. The stop variable is loop-invariant, so it can be hoisted out of the loop.<BR/><BR/>The take away message here is that if you are going to communicate values between threads, you <B>have</B> to use some explicit form of communication, whether it be in the form of a synchronized block, a volatile field modifier, or somethingJeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-38320819360294849462007-03-27T19:49:00.000-07:002007-03-27T19:49:00.000-07:00Jeremy,One question - consider the following (chan...Jeremy,<BR/><BR/>One question - consider the following (changed) snippet:<BR/><BR/>public void run() {<BR/> while (true) {<BR/> if (stop) {<BR/> return;<BR/> }<BR/> oneStep();<BR/> try { Thread.sleep(100); } …;<BR/> }<BR/>}<BR/><BR/>I agree that using stop as volatile even in this situation wouldn't hurt but I'd like to ask anyway: would this work even if stop is not volatile Felipe Couryhttps://www.blogger.com/profile/17312733589972777822noreply@blogger.com