Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Question whether a problem with race conditions exists in this case Date: Wed, 14 Dec 2011 18:05:01 -0500 Organization: A noiseless patient Spider Lines: 38 Message-ID: References: <8bbbbee3-adcc-4f28-aff5-2e230b047401@u6g2000vbg.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 14 Dec 2011 23:05:05 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="HSlJAUb3pGXi3i7ZL/HoAw"; logging-data="5169"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EipHWje0tXwmgyFEgGQam" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Cancel-Lock: sha1:97N8V75ra+g8J+ctZoRSdmBpUVo= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10756 On 12/14/2011 4:57 PM, Saxo wrote: > On Dec 14, 10:26 pm, Eric Sosman wrote: >> [...] >> What's the larger problem you're trying to solve? > > Well, I'm basically thinking about how to implement a database commit. > I don't use a database. Instead, the data is on the heap in a simple > list. When the commit is done, all the new values in all the nodes in > my list become visible at once (by changing useNewValue as explained) > to any thread calling get(). This way I get around changing the values > in a big big synchronized block which would cause quite some lock > contention. You'll still have the problem that threads T1 and T2 could get() different values from the same Node, and both be working with those conflicting values at the same time. An "instantaneous" change will not avoid the issue -- so either (a) it better not be an issue, or (b) you need The Mother Of All Locks around the whole shebang ... Also, the problem ordinarily addressed by a "commit" mechanism is somewhat different: You want to make changes to Nodes N1 and N2, and you want to make sure an observer sees either the two old values or the two new values, but never a mixture. Again, "instantaneous" change won't solve the problem, not even in the simple case of just one mutator and one observer: Observer: Fetch the N1 value, then ... Mutator: CHANGE THE WORLD INSTANTANEOUSLY Observer: ... fetch the N2 value For the observer's view of N1 and N2 to be consistent, it's not enough that each get() be guarded against interference; you need the pair of get()'s guarded as a unit. Very likely, you also need the changes to N1 and N2 guarded as a unit. -- Eric Sosman esosman@ieee-dot-org.invalid