Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.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.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 20 Dec 2011 14:12:41 -0600
Date: Tue, 20 Dec 2011 12:12:36 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: reading the JLS (17.4.5)
References: <slrnjerm1c.fvg.avl@gamma.logic.tuwien.ac.at> <jckv1o$v1v$1@dont-email.me> <slrnjf1iug.fvg.avl@gamma.logic.tuwien.ac.at> <jcqlef$5rp$1@dont-email.me>
In-Reply-To: <jcqlef$5rp$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <B5-dnV9Gn_2ncW3TnZ2dnUVZ_h6dnZ2d@earthlink.com>
Lines: 25
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 75.11.53.36
X-Trace: sv3-IeKf2YCKQVkzmFjXwUhnqUYcTcLPLfvB2U7gI87wKRQy3wUcAlAmqMLlGjdJjZhwX1X6Q7uFtV3OS8n!BnlhNkT49RJvEkbaMDHVPYDfiDSPj5F/WtxtjLidgCgMTk8ov+coaNTq0iVPW2Qy7nT+Ix4JUIgC!br5DJGFFMhQu0QE9TgpBWykfS39g1gR1sdq34AhzMTU=
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: 2470
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10911

On 12/20/2011 10:50 AM, markspace wrote:
...
> Patricia had some thoughts on reordering by hardware, but that involved
> synchronization and memory barriers, and I don't recall seeing those
> discussed in the small JLS section in question. I think this JLS section
> applies more generally than a read or write getting moved out of a
> synchronization block. I think it applies absolutely everywhere.

I just wanted to construct one specific case, and picked a fairly
arbitrary combination of operations and events. Producing the sort of
effect I was aiming for does require a happens-before relationship
between two actions in different threads.

I think "happens-before" should be thought of as short for "must appear
to happen before". As the JLS says "It should be noted that the presence
of a happens-before relationship between two actions does not
necessarily imply that they have to take place in that order in an
implementation. If the reordering produces results consistent with a
legal execution, it is not illegal."

Prohibiting a read R from seeing the result of a write W if R "must
appear to happen before" W, but may in fact have happened after W, is
quite reasonable.

Patricia