Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.palinacquisition!news.posted.palinacquisition.POSTED!not-for-mail NNTP-Posting-Date: Thu, 31 Mar 2011 02:52:04 -0500 Date: Thu, 31 Mar 2011 00:52:03 -0700 From: Peter Duniho User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: AtomicReferenceArray writes and visibility References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: Lines: 102 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 50.46.118.188 X-Trace: sv3-HEAikQeSUrebFNQ0ULmNKMuzW/VS8zoOWtmgeYz9fnF8VuBy5zqCINqyzpxPHVPst5eVzJmTnLvG+iT!XRVzv/l57MNSUeQTaAIguwdLMR8/DeE/q/2yrppaJm7JB1XcZDwfzpUZwOsD0ZBdO5ls7yHAETd4!qY1agy78jDmYcUWrzg1wTS1xFuQUoqnVSE1RQdg7mZo= X-Complaints-To: abuse@iinet.com X-DMCA-Complaints-To: abuse@iinet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5175 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2638 On 3/30/11 10:43 PM, Volker Borchert wrote: > Hello all, > > reading on the "new" memory model and AtomicReferenceArray, it > seems that anything done before a .set() on an AtomicReferenceArray > "happens-before" anything done after a .get() on the same > AtomicReferenceArray. > > Two questions: > > 1. Am I right? Essentially, but not literally. You need to qualify your statement to specify that the action that occurs before the write (the call to set()) has to be in the same thread as the write, and the action that occurs after the read (the call to get()) has to be in the same thread as the read. Only with that requirement can you be sure that all of the following are true: • in a given thread, action x occurs before action s, the write • in a given thread, action r, the read, occurs before action y • action s is synchronized with action r, where r follows s • and thus, one can conclude that x happens-before y. If x occurred in a different thread from s or y occurred in a different thread from r, then we'd have no assurance that x happens-before s, or that r happens-before y. > 2. If so, does this hold true if the write does not actually change > the value, in other words, if the write only "refreshes" the > memory location? Yes, sort of. The memory model doesn't care whether the value changed, simply that some synchronization was done. However, note that it would not be possible for your program to know whether it was operating under that guarantee or not. The synchronization between s and r (see above) simply resolves a race condition between those two actions. If r wins the race, then the code executing y would be observing the old value, and not have any way to be assured that x had already happened. In other words, suppose I've got the following: int a = 0; bool f = true; object o = new Object(); thread 1 thread 2 ---------- ---------- a = 1; synchronized (o) { f = true; } synchronized (o) { if (f) { System.out.println(a); } } There's no way to tell the difference between that and: thread 1 thread 2 ---------- ---------- synchronized (o) { if (f) { System.out.println(a); } } a = 1; synchronized (o) { f = true; } So, sure. The memory model assures us that in the first example, the output is 1. But the program has no way to know that it's not operating in the sequence seen in the second example. The output just as easily could be 0, in spite of the synchronization of f. For that matter, even with f being written after it's read, as in the second example, a could still have been set before the read, and the output would still be 1 in that case, as in the first example, but with a different order of the write and read. The bottom line is that if the synchronized value doesn't change, the problem doesn't really have any way to know what the actual sequence of execution was. To take advantage of the rules, the variable being synchronized has to be modified in some meaningful way, such that the code can tell what's important. Note that all of this isn't unique to AtomicReferenceArray. It applies to any synchronized access to a given variable. See JLS 17.4.5 for the specifics. Pete