Re: JavaMemoryModel: A new box for the Java Memory model

From: Bill Pugh (
Date: Tue Nov 09 1999 - 17:07:00 EST

The things David has proposed are generally along the lines of what I
have been proposing. A couple of details:

* The requirements having to do with final non-static fields are just part of
   a safety guarantee. For correctly synchronized code, it never needs to come
   into play.

   Consider: thread 1 has created an object that has final fields. In order
   for thread 2 to see a reference to that object, there should be
   synchronization between threads 1 and 2.

   The real point of the rule on final fields is this: How can you trust
   that a reference to an immutable object being passed to a function
   is really immutable? Either synchronize the method or make all of the
   fields of the object final.

* My proposed semantics of volatile are a little more subtle than David
   proposed, but it is still the case that almost every bad synchronization
   idiom can be fixed by making some particular field volatile.

* Allowing array elements to be final and/or volatile is going to be
   very difficult. Amoung other things, it would change the signatures
   are encoded and complicate subtyping relationships (is an array of final
   refs to Strings a subtype of an array of non-final refs to Objects)?

   I think I can make something work so that a final ref to an array will
   give us the same guarantees for the array elements that we have for the ref.

* The semantics of allowing memory barriers associated with useless locks
   to be removed is actually quite clean. You just say that rather than having
   a model of a global memory, that updates flow between threads via monitors
   and volatile variables. If thread 1 unlocks X, and then thread 2 locks X,
   then thread 2 sees all of the updates of thread 1.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT