 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2007Memory Consistency Errors
Hi, While reading the tutorial http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html, something caught my attention: It is said that memory consistency errors can occur even when atomicity of reading/writing access is guaranteed with volatile. However they don't develop this matter. Is there somebody that could explain me more how could this happen? Thank in advance. mei wrote On 02/13/07 14:26,: > Hi, > While reading the tutorial [quoted text clipped - 5 lines] > Is there somebody that could explain me more how could this happen? > Thank in advance. Accesses to main memory might not occur in the same order that the CPU initiated them, particularly for writes (which often go through hardware write buffers so the CPU needn't wait for them). If CPU 1 writes the Answer to location A and then writes the AnswerIsReady flag to B, CPU 2 may see the change to B before it sees the change to A, and thus get the WrongAnswer. Making either or both writes atomic doesn't help; what's needed is something called a "memory barrier."  SignatureEric.Sosman@sun.com > mei wrote On 02/13/07 14:26,: >> Hi, [quoted text clipped - 16 lines] > writes atomic doesn't help; what's needed is something > called a "memory barrier." Is that not what you get with volatile? SignatureKnute Johnson email s/nospam/knute/ >> mei wrote On 02/13/07 14:26,: >>> Hi, [quoted text clipped - 19 lines] > > Is that not what you get with volatile? Hmmm... <browses the specifications, scratches head, gets splinters under fingernails>. Perhaps it is. It seems the precise meaning of `volatile' has undergone some changes, and that the memory-ordering semantics are now tighter than they used to be. (See Lew's post on this thread for an informative quote.) mei, my answer is correct (I think) for older Java versions, but is wrong for the latest versions. I apologize for the out-of-date information. SignatureEric Sosman esosman@acm-dot-org.invalid >>> mei wrote On 02/13/07 14:26,: >>>> Hi, [quoted text clipped - 30 lines] > but is wrong for the latest versions. I apologize for the > out-of-date information. Thanks Eric. SignatureKnute Johnson email s/nospam/knute/ > Hi, > While reading the tutorial [quoted text clipped - 5 lines] > Is there somebody that could explain me more how could this happen? > Thank in advance. I looked and couldn't find the reference you mentioned. Do you have the URL of the page you saw that on? Thanks, SignatureKnute Johnson email s/nospam/knute/ mei wrote: >> Hi, >> While reading the tutorial [quoted text clipped - 5 lines] >> Is there somebody that could explain me more how could this happen? >> Thank in advance. > I looked and couldn't find the reference you mentioned. Do you have the > URL of the page you saw that on? According to <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/> "The original semantics for volatile guaranteed only that reads and writes of volatile fields would be made directly to main memory, instead of to registers or the local processor cache, ... In other words, this means that the old memory model made promises only about the visibility of the variable being read or written, and no promises about the visibility of writes to other variables. While this was easier to implement efficiently, it turned out to be less useful than initially thought. "... "The JSR 133 Expert Group decided that it would be more sensible for volatile reads and writes not to be reorderable with any other memory operations ... 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." So it seems that what used to be is now better. - Lew > mei wrote: >>> Hi, [quoted text clipped - 33 lines] > > - Lew Lew: That's an excellent article, thanks for finding that. SignatureKnute Johnson email s/nospam/knute/ Lew wrote: > Lew: > > That's an excellent article, thanks for finding that. Google is my friend. -Lew > According to > <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/> [...] > "The JSR 133 Expert Group decided that it would be more sensible for > volatile reads and writes not to be reorderable with any other memory > operations ... 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." Can anyone point me to the passages in JLS3 which imply that. My own study of the new stuff has been patchy (and reluctant), but I haven't yet seen anything to make the following wrong. (I'm not claiming it /isn't/ wrong, only asking for corroboration, or -- better -- refutation). With the above caveat. Given a non-local volatile variable: volatile int[] volatileField; It seems to me that if one thread does the following: int[] local = new array[2]; local[0] = 100; local[1] = 200; volatileField = local; then there are only so many things that another thread, subsequently reading the volatileField's contents, is guaranteed to see. I believe the following to be guaranteed: volatileField is not null. volatileField refers to an int[] array of length 2. volatileField[0] is either 0 or 100 volatileField[1] is either 0 or 200 However, I haven't yet found anything to convince me that any of the following are illegal: volatileField[0] == 0 && volatileField[1] == 0 volatileField[0] == 100 && volatileField[1] == 0 volatileField[0] == 0 && volatileField[1] == 200 volatileField[0] == 100 && volatileField[1] == 200 The wording in JLS3 seems to be quite specific about the happens before-relationship[*] as it applies to volatiles, and it only seems to refer to the value of the volatile /itself/, not to any other actions. It may be that the later stuff (causality, etc) in the JLS3 clears this up, but as far at the HB relation goes, I can't see that the visible contents of the array are fully constrained. -- chris [*] which I think would be better named: must-not-be-seen-to-happen-after. >> According to >> <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/> [quoted text clipped - 51 lines] > > [*] which I think would be better named: must-not-be-seen-to-happen-after. I think if you look at this situation as class with two int fields rather than an int[] you will see that the fields are not volatile unless declared so. So while the variable volatileField would indeed reference the correct int[] there would be no synchronization of the array elements across threads. Or at least that is what I think today :-). Then again it could all be different with arrays. SignatureKnute Johnson email s/nospam/knute/ >>> According to >>> <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/> [quoted text clipped - 70 lines] > Or at least that is what I think today :-). Then again it could all be > different with arrays. And I found some more interesting things. Look at AtomicBoolean in the docs and follow the link 'java.util.concurrent.atomic'. It has a discussion of the Atomic??? classes and especially see AtomicIntegerArray. I still think that it would require synchronization to prevent memory consistency errors however. SignatureKnute Johnson email s/nospam/knute/ Knute Johnson a écrit : >> Hi, >> While reading the tutorial [quoted text clipped - 10 lines] > > Thanks, Here it is even though it seems it is outdated: http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html "Atomic actions cannot be interleaved, so they can be used without fear of thread interference. However, this does not eliminate all need to synchronize atomic actions, because memory consistency errors are still possible." > Here it is even though it seems it is outdated: > http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html > "Atomic actions cannot be interleaved, so they can be used without fear > of thread interference. However, this does not eliminate all need to > synchronize atomic actions, because memory consistency errors are still > possible." They are talking about "happens-before" relationships. - Lew Lew a écrit : >> Here it is even though it seems it is outdated: >> http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html [quoted text clipped - 6 lines] > > - Lew Ok, you are right: As far as I understand it, what the Sun tutorial explains about the happens-before relationship matches with what is said in the IBM article. Thus the tutorial is also up-to-date. But still the tutorial claims that this new semantic of volatile is not enough to prevent from memory consistency errors. So I think my initial question is still unanswered, or am I missing something? > As far as I understand it, what the Sun tutorial > explains about the happens-before relationship matches with what is said > in the IBM article. Thus the tutorial is also up-to-date. > But still the tutorial claims that this new semantic of volatile is not > enough to prevent from memory consistency errors. So I think my initial > question is still unanswered, or am I missing something? See Chris Uppal's answer in this thread. It includes an example of what might be inconsistent. - Lew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.