[concurrency-interest] question the about the JMM

Brian Goetz brian at briangoetz.com
Wed Dec 5 17:01:32 EST 2007

It is OK to reason that way -- as long as you know _exactly_ in which 
ways such reasoning is inconsistent with the actual semantics.  Which 
requires understanding all the details of the actual semantics...in 
which case it is probably easier (at least to me) to reason correctly 
about happens-before rather than caches and invalidation.

But 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.

Larry Riedel wrote:
>> reasoning in 'caches and invalidation' is not the way to
>> go with the new JMM.
> I think it should be ok to reason that way, as long as it is
> done in a way which is consistent with the actual semantics,
> which I think is viable.  It seems to me kind of like saying
> a lock is "protecting a critical section of code" rather
> than "protecting some objects".  If I say thinking the
> latter is the way to go, maybe it would not be unreasonable
> for someone to say to me "but it is the critical sections of
> code that access the objects".
> If somebody was to think like "whenever I release a lock,
> the caches get invalidated, and by the time another thread
> has acquired a lock after that, the caches will have been
> updated", where "after" is defined in terms of real world
> time, it seems to me like something close to that could
> be part of a valid model for somebody who wants to think
> in terms of one single real world time, as long as they
> are careful about which caches and locks, and which object
> values are in the caches.
> If someone thinks whenever a thread acquires/releases
> a lock, it will see the latest changes any other thread
> made to any value prior to the most recent acquire/release
> of a lock in that thread, it seems like they may just be
> misinformed, rather than using a fundamentally poor model.
> Larry
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list