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

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

Re: reading the JLS (17.4.5)

Show all headers | View raw

Patricia Shanahan <pats@acm.org> wrote:
> 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.

This is the point where I say: "phew". Up to this point, I feared 
you'd describe some legal behaviour based on that, while reads can 
happen-after writes with obvious meaning, writes happening-after
reads might still be allowed to be seen by reads... Well, I'm glad
it isn't so. I was confused enough to not be beyond doubt, though.

Why is a rule for a Java implementation phrased as a property
of/on a "set of actions"? 

> 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?

Given some (simplified) sample code:
  class Test {
     /*non-vol*/ int n1;
     volatile    int v1;

     void t1() {
       n1 = 1;
       v1 = n1; // v1 uses n1
     }

     void t2() {
       int r1=v1, r2=r1*n1; // r2 uses r1
       assert ! (r1 == 1 && r2 != 1) : "huh?";
     }
  }
Two threads T1 and T2 may at some point run t1() and t2()
respectively, then I should expect, per transitivity of
"happens-before" that if r1 == 1, then r2 would *have to*
== 1, too.  Is there a happens-before relation between
between setting n1 and reading n1 via write&read on the
volatile v1 and each intra-thread ordering?

There is a slightly similar example later in the JLS about
a final and a non-final set in a constructor, but that is
different, in that the non-final is set after the final.
I don't know for sure, if the ordering of the assignments
was relevant in that example.

Back to comp.lang.java.programmer | Previous | Next — Previous 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