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

Re: reading the JLS (17.4.5)

From	markspace <-@.>
Newsgroups	comp.lang.java.programmer
Subject	Re: reading the JLS (17.4.5)
Date	2011-12-21 12:02 -0800
Organization	A noiseless patient Spider
Message-ID	<jcte0i$5pb$1@dont-email.me> (permalink)
References	(2 earlier) <slrnjf1iug.fvg.avl@gamma.logic.tuwien.ac.at> <jcqlef$5rp$1@dont-email.me> <B5-dnV9Gn_2ncW3TnZ2dnUVZ_h6dnZ2d@earthlink.com> <slrnjf37mr.fvg.avl@gamma.logic.tuwien.ac.at> <BP-dnedoectFtm_TnZ2dnUVZ_i2dnZ2d@earthlink.com>

Show all headers | View raw

On 12/21/2011 10:56 AM, Patricia Shanahan wrote:
> On 12/21/2011 12:54 AM, Andreas Leitgeb wrote:
>>
>> T1: hb(A,B) - not necessarily observed so by T2
>> T1,T2: hb(B,C)
>>
>> How would T2 "know" about hb(A,C), if it doesn't know hb(A,B) ?
>>
>
> T2 does not necessarily "know", but must see the appropriate results
> e.g. from its reads. Making that happen is the Java implementation's
> problem. How it happens varies depending on the system.

I think Andreas is asking "If a transitive relationship exists, how does 
T2 'know' that?"

The JLS doesn't require a reading thread like T2 to be aware of any 
other thread's entire set of write actions.  It's just that once 
synchronized, those write actions are available to be observed, and the 
order they are observed doesn't matter.

Let's say T1 and T2 are both accessing a circular queue, and A, B and C 
are the head, tail and count variables.  T1 does some operation and 
updates A, B and C.  Then T2 accesses the queue, observes C to be 0, and 
decides it doesn't want to preform any further updates on an empty 
queue.  It could, and would be able to observe A and B safely, but it 
just chose not to based on its own program logic.  This is an example 
where T2 doesn't "know" about A or B, but only observes C.  The point 
however is that A and B are visible to T2 and could be observed safely, 
even if T2 did not elect to observe them.

I guess another way of saying this is that the compiler "knows" about A, 
B and C and makes sure they are visible to T2, even if T2 doesn't use 
them explicitly.

> In other situations, it may be necessary to use special instructions,
> such as the SPARC membar, to ensure that prior memory operations are
> globally visible.

Most of the Java synchronization is guaranteed to make all writes 
visible to another thread, even those writes that don't explicitly 
participate in the synchronization action (i.e. the variable or object 
lock).  Thus they work a lot like the membar opcode, flushing all writes 
to whomever might want to observe them.  No one has to observe anything, 
but the write flush occurs just the same.

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