tag:blogger.com,1999:blog-8405107760807432973.post3008391668363779215..comments2024-01-04T09:55:32.459-08:00Comments on Java Concurrency (&c): Atomicity, Visibility and OrderingJeremy Mansonhttp://www.blogger.com/profile/04241094734813086257noreply@blogger.comBlogger52125tag:blogger.com,1999:blog-8405107760807432973.post-88138260933658567182019-02-11T11:10:57.237-08:002019-02-11T11:10:57.237-08:00@Anonymous - Poor choice of words on my part. By ...@Anonymous - Poor choice of words on my part. By "them" I meant "a" and "b". Fixed this in the text.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-14559347899979653722019-02-11T11:06:05.856-08:002019-02-11T11:06:05.856-08:00In the Ordering section you said "In this cas...In the Ordering section you said "In this case, you can throw a lock around threadOne or threadTwo, or you can declare them both to be volatile, and get the ordering you want."<br />What do you mean? Declare the methods volatile? Why do that?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-38494481925833319492016-06-11T11:55:48.744-07:002016-06-11T11:55:48.744-07:00Nine years later, I have no idea. I've delete...Nine years later, I have no idea. I've deleted the offending sentence.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-77348884038387736262016-06-06T04:33:59.066-07:002016-06-06T04:33:59.066-07:00"check the box for details"
Which box?"check the box for details"<br /><br />Which box?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-10037818507511342732015-09-18T04:32:28.754-07:002015-09-18T04:32:28.754-07:00Thanks for writing such good and informative artic...Thanks for writing such good and informative article.Angelhttps://www.blogger.com/profile/06425086656751807336noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-45207752440234458862015-07-18T09:43:31.683-07:002015-07-18T09:43:31.683-07:00If you don't want to share data with another t...If you don't want to share data with another thread, then a ThreadLocal is a perfectly reasonable thing to use. If you <b>do</b> want to share data with another thread, then you have to use some form of explicit communication between threads, whether by locking, or use of volatile variables, or another well-documented mechanism.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-37108266194619694732015-07-15T05:02:00.873-07:002015-07-15T05:02:00.873-07:00Hi Jeremy, Thank for a great post...
I often thin...Hi Jeremy, Thank for a great post... <br />I often think why would I add synchronization or lock mechanism inside the run implementation, which makes other thread to wait. Is there any other way I can address this "Atomicity" and "visibility" issue by using ThreadLocal or thread context.Premhttps://www.blogger.com/profile/16500974422197247234noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-11555191463005066602015-01-02T20:29:30.335-08:002015-01-02T20:29:30.335-08:00@anonymous - Because you need synchronization on b...@anonymous - Because you need synchronization on both the reader and writer sides. More information about it is available in my post about DCL<br /><br />http://jeremymanson.blogspot.com/2008/05/double-checked-locking.htmlJeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-85851360551387834102015-01-02T16:01:37.444-08:002015-01-02T16:01:37.444-08:00Hey Jeremy, This is a great post .... Was wonderin...Hey Jeremy, This is a great post .... Was wondering if we can discuss as to why VOLATILE is needed for Double checked singleton pattern ? When Thread2 acquires the lock after Thread1 has created the instance (for ex: instance = new SingletonClass()) and existed the synchronized block, wont this line sync all data with the main memory for the Thread2 to see when it enters the synchronized block. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-36682560052027636882014-07-12T12:46:10.941-07:002014-07-12T12:46:10.941-07:00@anonymous: it is possible, but not very likely in...@anonymous: it is possible, but not very likely in practice. The more likely possibility is that one of them will return false and the other will return true, because it will be interrupted by the other thread between setting the value and checking the assertion - that would almost certainly happen in a real application.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-64353916149196549102014-07-06T19:27:57.892-07:002014-07-06T19:27:57.892-07:00Hi Jeremy, I have a question about the code below....Hi Jeremy, I have a question about the code below.<br /><br />class MyClass{<br /><br /> private int val;<br /><br /> int update(int upd){<br /> this.val = upd;<br /> return val<br /> }<br />}<br /><br />If I then create <b>obj</b>, an object of type <b>MyClass</b> and let it be shared by two threads <b>t1</b> and <b>t2</b>, whose codes are as follows:<br /><br /><b>t1</b>:<br />aAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-64104071134494194632013-11-29T11:27:49.805-08:002013-11-29T11:27:49.805-08:00@TRANSFORMATION: No, that would not work. In that...@TRANSFORMATION: No, that would not work. In that case, you are just accessing balance without holding the lock at all, which is a no-no.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-86737103577425774952013-11-25T14:20:07.647-08:002013-11-25T14:20:07.647-08:00Awesome Post Jeremy !!! Thanks,
Would this code f...Awesome Post Jeremy !!! Thanks,<br /><br />Would this code fix the atomicity problem you described..<br /><br />class BrokenBankAccount {<br /> private int balance = 10;<br /><br /> synchronized int getBalance() {<br /> return balance;<br /> }<br /><br /> synchronized void setBalance(int x) <br /> throws IllegalStateException {<br /> balance = x;<br /> if (balance < 0) {<br />Wood Peckerhttps://www.blogger.com/profile/01262351387958539651noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-25180733988714098692013-09-22T19:32:29.060-07:002013-09-22T19:32:29.060-07:00Thanks a ton JeremyThanks a ton JeremyAnonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-85348551955293411582013-09-22T18:04:20.711-07:002013-09-22T18:04:20.711-07:00@sankar - Doug Lea runs a concurrency-interest mai...@sankar - Doug Lea runs a concurrency-interest mailing list, and they often deal with memory model questions.<br /><br />For question 1, if r3 is true, then r1 and r2 will also be true.<br /><br />For question 2, if there is a volatile write, and another thread sees the result of that write, then it will see all of the actions that happened before that write. If you are asking whether the Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-58061529767989005342013-09-20T21:31:43.443-07:002013-09-20T21:31:43.443-07:00Sorry, I am taking your precious time Jeremy :-)
...Sorry, I am taking your precious time Jeremy :-)<br /><br />But where else to go?<br /><br />One question: Which all independent statement may not be reordered? I meant to say other than write to volatile are there any other such statements? What about Thread.start() or Thread.join()?<br /><br />Thanks in advance..Anonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-51223164885598291892013-09-20T18:55:39.897-07:002013-09-20T18:55:39.897-07:00Jeremy there is one more question regarding "...Jeremy there is one more question regarding "ordering", i.e. the third example. I just add a third variable c and only make this variable as volatile.<br /><br />Question 1: I guess threadTwo() will return true. Then (in this scenario) can we assume that we could make only c as volatile, rather than all three?<br /><br />class BadlyOrdered {<br /> boolean a = false;<br /> boolean b =Anonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-57000801098552477012013-09-15T02:40:40.007-07:002013-09-15T02:40:40.007-07:00Thanks Jeremy.
Thanks Jeremy.<br /><br />Anonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-11891937035405826442013-09-14T21:02:42.354-07:002013-09-14T21:02:42.354-07:00@Sankar - I urge you not to think about these thin...@Sankar - I urge you not to think about these things in terms of caches and main memories. <br /><br />The first reason is that you would have to think about the individual processor and the guarantees it makes; those models are very, very complicated, and the number of different processor features (caches, write buffers, out-of-order execution...) that come into this are very large.<br /><br />Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-91370794732806316472013-09-14T18:59:23.887-07:002013-09-14T18:59:23.887-07:00Thanks Jeremy for replying my queries .
Then can...Thanks Jeremy for replying my queries . <br /><br />Then can I suppose that read and <br />write to a "non-volatile" variable is mostly local to the thread.<br />And when the local cache of the thread is empty then only it reads and writes to the variable in memory?<br /> <br />And it is then only, that other thread sees this if "this other thread" also has empty local cache Anonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-47543663421070684422013-09-14T11:58:42.734-07:002013-09-14T11:58:42.734-07:00If I have understood your post, Line 1 can never h...<br /><i>If I have understood your post, Line 1 can never happen at the same instance of time for both the threads. One has to follow other.<br />I guess write operation is "atomic".</i><br /><br />No, they can happen at the same time. It is just that other threads won't see them half-done.<br />Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-75409223416766045582013-09-14T11:55:24.070-07:002013-09-14T11:55:24.070-07:00Q 1> Can I conclude that "atomic" ope...Q 1> Can I conclude that "atomic" operations can never be concurrent? I meant to say that whenever one "atomic" operation is taking place by a "particular" thread, all the other threads can not access the variables being accessed/involved (read from or written to) in that "atomic" operation until the operation is complete?<br /><br />Not exactly. The Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-68337403893836045902013-09-13T06:33:21.392-07:002013-09-13T06:33:21.392-07:00Also another question.
Say there are two processor...Also another question.<br />Say there are two processors and as per Java 7 threading model (I am yet to explore it though) two different threads are engaging two processors.<br />Both of them have invoked the same method (which is not synchronized)of the same object.<br /><br />Say the method is as below<br /><br />class TwoThreads{<br /><br />int i = 0;<br /><br />public method access(int a, intAnonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-16791129924006974432013-09-13T00:07:38.371-07:002013-09-13T00:07:38.371-07:00Hi Jeremy,
Your posts are just awesome. I do not ...Hi Jeremy,<br /><br />Your posts are just awesome. I do not know why I found your blog web site so late.<br /><br />Kindly rectify my understanding, if I am wrong somewhere.<br /><b><br /><br />Q 1> Can I conclude that "atomic" operations can never be concurrent? I meant to say that whenever one "atomic" operation is taking place by a "particular" thread, all the Anonymoushttps://www.blogger.com/profile/10158664374989763242noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-72823983806789830102011-09-15T07:54:21.998-07:002011-09-15T07:54:21.998-07:00@Dimitris - yes, that's right - you need to sy...@Dimitris - yes, that's right - you need to synchronize the whole function, or it isn't atomic.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.com