[concurrency-interest] question the about the JMM
online at stolsvik.com
Thu Dec 6 20:13:04 EST 2007
Larry Riedel wrote:
>> [...] your next paragraph illustrates exactly what's wrong
>> with this mental model, and that is, there is almost
>> always that hidden assumption of sequential consistency.
>> "Before" and "after" simply have no meaning under the JMM
>> except as defined by happens-before.
> I am inclined to expect any intuitive model based on
> the JMM, with a local clock and "happens-before", will
> be homomorphic to a graph for a model based on a global
> clock and local caches (using a typical cache coherence
> protocol), with meaningful and well-defined "before" and
> "after". But I would rather not try to prove it. (-:
I think the problem might be that one can end up with ideas that "*all*
cache will be flushed to main memory upon *any* synch exit", and "*all*
cache will be invalidated upon *any* synch entry", and that this means
that as long as all threads in the VM are doing some synching or some
access on volatiles, all shared variables will sooner or later be
transferred between all threads.
This is not the case, however: threads must establish a happens-before
edge between a *shared* object, or read/write on a *shared* volatile
variable for the "transfer" to occur. But as long as this holds, then at
least I agree that the cache logic mentioned above hold (this because
the logic where "happens-before are transitive": everything written
anywhere BEFORE the edge on the one thread will be visible AFTER the
edge on the other thread).
The crucial point that the "happens-before" logic conveys is that the
two threads in question must synch on some *common* object/volatile
variable - the "transfer" won't happen on just any random synch.
Lets say we have four threads, where two and two of these threads are
communicating properly with lots of synchs and volatile variables.
However, the two groups also share a common (non-volatile) variable or
object - but the two groups *never* synchs on that, or any other, common
object, nor read-write on any shared volatile variable.
Then, the two groups might still see fully different values for the
shared (non-volatile) variables and objects. The simple cache logic
discussed above would at least in my head not allow this to happen, but
the happens-before model will allow it just fine: there is never
established any happens-before edge between the two groups of threads,
and hence they aren't required to communicate/"transfer" the values of
those shared variables.
More information about the Concurrency-interest