Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10854
| Date | 2011-12-18 09:21 -0800 |
|---|---|
| From | Patricia Shanahan <pats@acm.org> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: reading the JLS (17.4.5) |
| References | <slrnjerm1c.fvg.avl@gamma.logic.tuwien.ac.at> |
| Message-ID | <wOWdnRqBm-mNvHPTnZ2dnUVZ_omdnZ2d@earthlink.com> (permalink) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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