[concurrency-interest] question the about the JMM
alarmnummer at gmail.com
Wed Dec 5 17:31:21 EST 2007
one of the problems with the difference between reasoning in cache
invalidation and happens before relations, is that with the former the
following sounds very plausible: a release of lock X (that causes a
cache invalidation) and an acquire of lock Y (that causes a cache
update) is a usable mechanism to make all changes from one thread
visible in another.
The new JMM clearly states that this isn't the case (only if they are
the same lock). So reasoning with cache invalidation could lead to
wrong assumptions. I also reasoned about caches in the beginning (and
in some cases it still slips my mind), but I was discouraged to do so.
After some time reasoning about happens before rules is a lot easier
than reasoning about cache invalidations.
On Dec 5, 2007 10:37 PM, Larry Riedel <larryr at saturn.sdsu.edu> 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.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest