tag:blogger.com,1999:blog-8405107760807432973.comments2024-01-04T09:55:32.459-08:00Java Concurrency (&c)Jeremy Mansonhttp://www.blogger.com/profile/04241094734813086257noreply@blogger.comBlogger1103125tag:blogger.com,1999:blog-8405107760807432973.post-47287844449819636712023-06-15T13:49:20.425-07:002023-06-15T13:49:20.425-07:00Common mistake - there is no volatile write in set...Common mistake - there is no volatile write in set(). There's a volatile read of the array variable, followed by a normal write of 1 to element 0. So, there is no happens-before relationship between the set and the get.<br /><br />If you want arrays whose elements can be read and written atomically, use AtomicXArrays from java.util.concurrent.atomic.<br /><br />HB relationships are often Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-47474542502173130822023-06-13T07:37:47.160-07:002023-06-13T07:37:47.160-07:00volatile int[] array = new int[] {0};
public synch...volatile int[] array = new int[] {0};<br />public synchronized void set() {<br /> array[0] = 1;<br />}<br />public int get() {<br /> return array[0];<br />}<br /><br />Is it possible for the "get" thread to read 0 after the "set" thread has finished? <br />I am trying to understand whether happens before relationship means just a flush to the main memory and reordering Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-58726908963681573342023-06-13T06:30:25.047-07:002023-06-13T06:30:25.047-07:00@anonymous: sure, but how can you tell whether the...@anonymous: sure, but how can you tell whether the <b>arr = arr</b> line has executed? arr will have the same value either way.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-79990027580480405412023-06-13T05:35:09.117-07:002023-06-13T05:35:09.117-07:00Writer thread:
arr[0] = 1;
arr = arr;
Reader thre...Writer thread:<br />arr[0] = 1;<br />arr = arr;<br /><br />Reader thread:<br />int one = arr[0];<br /><br />Let’s assume that a read always goes after arr = arr; has been executed.<br />arr = arr; happens before (happens before relationship) arr (reading arr reference) from the reader thread. Therefore arr[0] = 1; is also visible from the reader thread and one == 1. Am I right with my reasoning?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-45844408519372650522022-11-12T18:10:07.980-08:002022-11-12T18:10:07.980-08:00Thank you very much.
The proof is in Section 9.2.1...Thank you very much.<br />The proof is in <a href="https://web.archive.org/web/20221006153211/https://rsim.cs.uiuc.edu/Pubs/popl05.pdf" rel="nofollow">Section 9.2.1 Correctly synchronized programs exhibit only sequentially consistent behaviors of the paper</a>.Naknoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-5605232513149998202022-11-11T08:33:53.744-08:002022-11-11T08:33:53.744-08:00It has been a while, but I believe it's in the...It has been a while, but I believe it's in the 2005 POPL paper on the subject.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-79138233501279266252022-11-11T04:20:15.614-08:002022-11-11T04:20:15.614-08:00"This definition has the lovely property of b...<i>"This definition has the lovely property of being reasonably intuitive and also guaranteeing SC for DRF programs"</i><br /><br />Is there a proof of that for a general case?<br /><br />I can see that it works for the examples in this post, but it isn't obvious to me how the causality algorithm guarantees SC-DRF for a general case.Naknoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-49792519257441692812022-09-01T22:26:09.309-07:002022-09-01T22:26:09.309-07:00@zhaoxi you can't call JNI functions - or many...@zhaoxi you can't call JNI functions - or many other functions - in signal handlers. Signal handlers triggered by a SIGPROF can execute asynchronously - that is, at any time in the execution of a program. So, every function you call in a signal handler has to be able to be called no matter what the main program is doing. We call that property "async safety" or "reentrant&Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-78700770899369742282022-08-30T02:26:00.935-07:002022-08-30T02:26:00.935-07:00Hi Jeremy, I'm still waiting for your explanat...Hi Jeremy, I'm still waiting for your explanation of why things like printf and JNI/JVMTI invocations crash VM...<br /><br />I've developed a profiler with asyncGetCallTrace which is triggered by SIGPROF just like yours. But I implemented some JNI function like FindClass and GetStaticMethodID in signal handler. It turns out that the target program crashed once the profiler attached. What Zhaoxihttps://www.blogger.com/profile/03673217838748765165noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-81236439211295292972021-11-05T19:49:37.270-07:002021-11-05T19:49:37.270-07:00Cool, understood now. Thanks so much!Cool, understood now. Thanks so much!yychttps://www.blogger.com/profile/01699762369204618098noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-876438306124808202021-11-01T17:21:21.400-07:002021-11-01T17:21:21.400-07:00@yyc - What it's "enough" for really...@yyc - What it's "enough" for really depends on what you expect it to do. Depending on what processItem() does and what the thread stopping it does, it may or may not be enough.<br /><br />Again, I recommend that you not use this pattern unless you are pretty confident you understand the way concurrency works in Java, because it's easy to get it wrong.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-71583218421119927432021-11-01T06:03:47.839-07:002021-11-01T06:03:47.839-07:00Hi Jeremy, thanks so much for your detailed explan...Hi Jeremy, thanks so much for your detailed explanation.<br /><br />Sorry I guess I confuse you. I understand that volatile i++ isn't atomic operation. What I don't undestand is whether volatile i++ is enough with only one single thread writing to it.<br /><br />Now you confirm it's enough. I guess such pattern is mostly used as a switch variable like below example:<br /><br />public yychttps://www.blogger.com/profile/01699762369204618098noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-76466257041524281472021-10-31T21:57:27.166-07:002021-10-31T21:57:27.166-07:00@yyc - As far as I can see, neither of those answe...@yyc - As far as I can see, neither of those answers implies that the operation v++ will be performed atomically. It won't. If you want atomic increment to a single variable, you can use the java.util.concurrent.atomic package.<br /><br />One of the answers suggests that it's okay to use i++ to indicate progress if you only have a single thread writing to it. That's pretty Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-83682307507358057562021-10-31T08:46:35.998-07:002021-10-31T08:46:35.998-07:00Hi Jeremy,
Thanks for the post but I still have q...Hi Jeremy,<br /><br />Thanks for the post but I still have question regarding to this question and accepted the answer here: https://stackoverflow.com/questions/32562822/how-does-the-volatile-count-operation-be-made-thread-safe, which claims that "The only time multiple threads are okay to write to a volatile variable without any extra synchronization is if the writes are idempotent (that isyychttps://www.blogger.com/profile/01699762369204618098noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-45829360612994746142021-07-12T21:11:44.109-07:002021-07-12T21:11:44.109-07:00@anonymous Because all writes of normal variables ...@anonymous Because all writes of normal variables that happen before a write of a volatile are deemed also to have happened before a read of that value from that volatile, even if it is in another thread. The write and subsequent read create an ordering between the two. Those are the rules, and Java implementations have to find ways to follow them.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-15219685681470043172021-07-10T08:56:43.172-07:002021-07-10T08:56:43.172-07:00Hi Jeremy,
I understand that Thread2 sees the chan...Hi Jeremy,<br />I understand that Thread2 sees the change of the variable ready. But why does it also see the change of variable answer, although it isnt volatile.Anonymoushttps://www.blogger.com/profile/12247348366125378720noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-29964974008238239642021-03-07T10:47:16.587-08:002021-03-07T10:47:16.587-08:00Thank you for the presentation! I just want to men...Thank you for the presentation! I just want to mention that the video is now available through the following YouTube link: <a href="https://www.youtube.com/watch?v=1FX4zco0ziY" rel="nofollow">Advanced Topics in Programming Languages: The Java Memory Model</a>Shinhyung Yanghttps://www.blogger.com/profile/01639271104689974466noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-39344422878145161492020-06-04T06:51:50.344-07:002020-06-04T06:51:50.344-07:00Garbage collection is the most important topic to ...Garbage collection is the most important topic to make a clean Abhishekhttp://www.androidcoding.in/noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-13881531428594701982020-05-23T04:21:19.007-07:002020-05-23T04:21:19.007-07:00Good one Jeremy. Thanks for your article.Good one Jeremy. Thanks for your article.Suresh Dasarihttps://www.tutlane.com/noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-2132622696441509122020-03-24T19:53:47.506-07:002020-03-24T19:53:47.506-07:00(1). a final reference guarantees that not only it...<i>(1). a final reference guarantees that not only it refers to the correct object (i.e, points to the correct address allocated for the object), but also the referred object is correctly initialized like volatile?</i><br /><br />Nope, just that the final fields of the referred object are fully initialized.<br /><br /><i>(2). for any variable v (including normal, final and volatile ones), a Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-43173199351624402152020-03-24T19:47:16.091-07:002020-03-24T19:47:16.091-07:00Not really. Final field guarantees are about ensur...Not really. Final field guarantees are about ensuring you won't see a partially constructed view of the object, not about ensuring you will see the most up to date reference.<br /><br />For example, there used to be a string implementation with an offset, length, and array field. You could have code like this:<br /><br /><br />String s1 = "/usr/tmp"; <br />String s2 = s1.substring(Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-64905942976963669832020-03-24T03:55:30.906-07:002020-03-24T03:55:30.906-07:00If we still need some synchronization to ensure sa...If we still need some synchronization to ensure safe publication of the reference to the ImmutableHashMap instance, Is the semantics of final about correct initialization redundant indeed? Anonymoushttps://www.blogger.com/profile/07403990732452416005noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-12393540795204199952020-03-23T21:43:27.217-07:002020-03-23T21:43:27.217-07:00Thanks for this blog. I want to verify some of my ...Thanks for this blog. I want to verify some of my understandings:<br />(1). a final reference guarantees that not only it refers to the correct object (i.e, points to the correct address allocated for the object), but also the referred object is correctly initialized like volatile? <br />(2). for any variable v (including normal, final and volatile ones), a thread t will access main memory the Anonymoushttps://www.blogger.com/profile/07403990732452416005noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-55157883814632725202020-03-21T20:19:49.981-07:002020-03-21T20:19:49.981-07:00@Unknown: Nope. Even if the model allowed for it,...@Unknown: Nope. Even if the model allowed for it, I'm not sure how it would make sense - the reader thread couldn't detect that the writer thread has performed its write?<br /><br />2) You can reorder any operations, as long as the results of the execution are still legal. In practice, it's more common to see elimination of operations that looks like reordering. For example, if youJeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-32578400810578712512020-03-18T21:05:33.073-07:002020-03-18T21:05:33.073-07:00Could you explain more about this aspect of immuta...<i>Could you explain more about this aspect of immutability? Thanks.</i><br /><br />I did a series of posts on immutability in 2008:<br /><br />https://jeremymanson.blogspot.com/2008/04/immutability-in-java.html<br />https://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html<br />https://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html<br /><br />LMK if you don&#Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.com