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.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT