Re: reading the JLS (17.4.5)
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