Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #10854

Re: reading the JLS (17.4.5)

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 Sun, 18 Dec 2011 11:21:20 -0600
Date Sun, 18 Dec 2011 09:21:20 -0800
From Patricia Shanahan <pats@acm.org>
User-Agent Mozilla/5.0 (Windows NT 5.2; WOW64; 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>
In-Reply-To <slrnjerm1c.fvg.avl@gamma.logic.tuwien.ac.at>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
Message-ID <wOWdnRqBm-mNvHPTnZ2dnUVZ_omdnZ2d@earthlink.com> (permalink)
Lines 52
X-Usenet-Provider http://www.giganews.com
NNTP-Posting-Host 70.230.194.31
X-Trace sv3-5w35poKosBsyZr5frra/FXpeP2RD/0UmYPO9vkiFBtWkysRy3KVs/gOSpY1kYdiAHwmXR8Pf7J7FlGZ!PaUY1F2V1F3jcOpCtXsMyFx2w2n7314Dsf2RBpFWn4wYfM/BKaCg+39aSSS3mtGq54915TQVTkBi!6+xDLg8kHTG8ucsR3a4FjbysDl0z4iUKF1FYqGgvynHw3A==
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 3651
Xref x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10854

Show key headers only | View raw


On 12/18/2011 4:10 AM, Andreas Leitgeb wrote:
...
> How could a "read" that happens-before a particular "write" *ever*
> see the "write"'s value?
>
> Maybe, someone could explain, what that *really* means?
>

Think about a large, high-performance server, with many out-of-order
processors, many memory modules, and a complicated network with as few
choke points as possible linking them. Everything has to be done as much
in parallel as possible, with as little synchronization as possible, to
get performance. Broadcasts to all memory modules or to all processors
must be very, very rare.

Suppose processor P sees in its pipeline instruction R, a read of
location X. It does not have the cache line containing X, so it sends
out a message asking for it.

To make as much progress as possible, P goes on to another instruction,
U, in the same thread as R, but that does not need X. U is an unlock
action, such as the end of a synchronized region. P immediately
afterwards gets a message from processor Q asking to be notified when U
happens, and responds to it.

Meanwhile, Q has the cache line containing X, and the right to modify
it. Because of delays in one path through the process-memory network,
the unlock action U reaches Q before the request for the cache line
containing X. Q executes an action V such that U synchronizes-with V,
followed in the same thread by a write W that changes the value of X.

Some time later, Q gets P's request for read access to the cache line
containing X, and sends it over with the W value written in to it.

R happens-before U, because they are actions of the same thread and R
comes before U in program order. U happens-before V, because U
synchronizes-with V. V happens-before W, because they are actions in the
same thread and V comes before W in program order.

R happens-before W, because happens-before is a transitive relation, but
R sees the value of X that W wrote.

The rule you are asking about requires a Java implementation to prevent
this scenario. For example, P might be prevented from doing an action
such as U that synchronizes-with activity in other threads until it has
completed all actions, such as R, that precede it in program order.

You can think of section 17 as defining "as possible" in the first
paragraph of this article. How parallel and out-of-order can a Java
implementation afford to be? What ordering can a Java programmer depend on?

Patricia

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

reading the JLS (17.4.5) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-18 12:10 +0000
  Re: reading the JLS (17.4.5) markspace <-@.> - 2011-12-18 06:57 -0800
    Re: reading the JLS (17.4.5) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-20 17:54 +0000
      Re: reading the JLS (17.4.5) markspace <-@.> - 2011-12-20 10:50 -0800
        Re: reading the JLS (17.4.5) Patricia Shanahan <pats@acm.org> - 2011-12-20 12:12 -0800
          Re: reading the JLS (17.4.5) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-21 08:54 +0000
            Re: reading the JLS (17.4.5) Patricia Shanahan <pats@acm.org> - 2011-12-21 10:56 -0800
              Re: reading the JLS (17.4.5) markspace <-@.> - 2011-12-21 12:02 -0800
  Re: reading the JLS (17.4.5) Patricia Shanahan <pats@acm.org> - 2011-12-18 09:21 -0800
    Re: reading the JLS (17.4.5) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-20 18:35 +0000
      Re: reading the JLS (17.4.5) Lew <lewbloch@gmail.com> - 2011-12-20 19:08 -0800
        Re: reading the JLS (17.4.5) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-21 08:37 +0000
          Re: reading the JLS (17.4.5) Patricia Shanahan <pats@acm.org> - 2011-12-21 10:46 -0800
          Re: reading the JLS (17.4.5) markspace <-@.> - 2011-12-21 12:09 -0800

csiph-web