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: markspace <-@.>
Newsgroups: comp.lang.java.programmer
Subject: Re: Volatile happens before question
Date: Tue, 17 Jan 2012 15:27:14 -0800
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <jf504l$m9b$1@dont-email.me>
References: <09848313-2372-4c23-8f52-fa84c612c100@u32g2000yqe.googlegroups.com> <jf471e$nn7$1@dont-email.me> <jf47t7$t7q$1@dont-email.me> <jf48qb$1fb$1@dont-email.me> <jf4amd$ebb$1@dont-email.me> <jf4dip$203$1@dont-email.me> <15jRq.2104$d%2.1226@newsfe07.iad> <jf4fd8$der$1@dont-email.me> <DEjRq.5131$Xa1.4052@newsfe15.iad> <jf4khn$fqt$1@dont-email.me> <zLudnc9ZU7DQYYjSnZ2dnUVZ_rKdnZ2d@earthlink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 Jan 2012 23:27:17 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="XjIWM99mD7Ijfdu600oVPA"; logging-data="22827"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Vnh3VyjmOOCMk4Rmb6ApqR8SKuo0EBhc="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
In-Reply-To: <zLudnc9ZU7DQYYjSnZ2dnUVZ_rKdnZ2d@earthlink.com>
Cancel-Lock: sha1:kuNwpCOhY0pSv4PORUEjbs9rdKg=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11434

On 1/17/2012 2:55 PM, Patricia Shanahan wrote:
> On 1/17/2012 12:09 PM, markspace wrote:
>> On 1/17/2012 11:06 AM, Daniel Pitts wrote:
> ...
>>> If b=1, that means a MUST be true.
>>
>> No, if b = 1, it could just be a random value made up by the CPU.
>
> That is one of the few behaviors that is specifically excluded. "Each
> read sees a write to the same variable in the execution.",
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.7


Well, I know Java can't exclude "made up values" because it happens in 
hardware.  Java has no choice but to execute on hardware.

The section you are referring to is 17.4.7 Well Formed Executions, and 
starts thusly: "We only consider well-formed executions."  In a well 
formed execution, I believe you are right, the program only sees writes 
that another thread actually made.

However a well formed execution also requires "4. The execution is 
happens-before consistent" and I believe that's what's being violated 
here.  Once you start reading variables with out proper synchronization, 
the concept of well formed executions are no longer valid and all of 
those 5 points go out the window.

This is what Brian Goetz means when he says "Programs with data races 
have no useful defined semantics."  Data races mean your code is no 
longer well formed.  Nice things like "you don't see made up values" 
don't work.  Things are just a mess.

Check that Vimeo link I posted, esp. the part about "out of thin air" 
values.  It's hard to get your head around but important, I think, to 
understand what happens when executions are not well-formed.  It 
provides good incentive to make sure your code really is synchronized in 
all cases.