> -----Original Message-----
> From: Jan-Willem Maessen [mailto:jmaessen@MIT.EDU]
> Sent: Tuesday, October 03, 2000 9:13 AM
> To: javaMemoryModel@cs.umd.edu
> Subject: RE: JavaMemoryModel: init methods
>
>
> I've been catching up on the discussion here, and wanted to inject a
> couple of observations.
>
> ------------------------------------------------------------
> RECOGNIZING THAT AN OBJECT WON'T CHANGE
>
...
> I wonder if we can perhaps extend this notion a bit. I have no idea
> how to formalize this in our own framework offhand, but what if we
> reset the "last holder" of a lock only if we performed a write while
> the lock was being held? Then we'd have the following rules:
>
> * As always, the first access of a shared object in any thread must
> perform a memory fence, or we do not even see meaningful contents
> for the object.
>
> * 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.
...
> MONOTONICITY WITHOUT LOCKING
>
...
> Note that to keep the cache in a hash table, we must guarantee that
> table updates are atomic. This is doable without locks, but messy, as
> hash table updates require both key and datum to be updated.
[Minor point, and a bit beside the original point:]
I'm not sure it matters much whether it's an array or a hash table. Both
the key and datum would reside in a single object, and the reference to that
object can be replaced atomically. As you say, the cached data has to be
final. (This is the canonical example of something that's much easier and
cheaper in a garbage collected system. In a non-garbage-collected system
it's hard to avoid synchronizing the readers, since someeone has to actually
deallocate the old cache entry after everyone is done reading it.)
Hans
-------------------------------
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