Hans Boehm replies to my message thus:
> > From: Jan-Willem Maessen [mailto:jmaessen@MIT.EDU]
> ...
> > ------------------------------------------------------------
> > RECOGNIZING THAT AN OBJECT WON'T CHANGE
> ...
> > * If we only read an object after initialization, then subsequent
> > accesses need not perform memory fences on MonitorExit, and could be
> > collapsed to eliminate locking entirely.
>
> I'm confused. What happens to the mutual exclusion part of the lock
> operation? That can still be significant, at least if the lock is sometimes
> held around something other than a getter method.
Ah, I should've explained. If a mutual exclusion operation has no
associated memory fence behavior, it doesn't exclude anything! This
is because the memory operations in the locked region can now "get
out"---the fence behavior is needed to keep them in. This is what I
mean by "collapsing" lock regions. When all memory operations have
escaped, we have Lock/Unlock as a pair, and that's effectively a noop
[again: no memory fence behavior! This is important!].
Note of course that this is a compiler-level or semantics-level view.
Most current architectures have some constraints on memory ordering
even in the absence of fences (except RMO on Sparc, and Alpha, where
the actual behavior of the chip is apparently rather more strongly
ordered than the spec).
-Jan
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT