My concern is that if final and volatile are made too liberal then
they become heavier (i.e., lead to more expected barriers and slower
performance) than normal usages of synchronization in some usage
contexts, at least on some machines.
On the other hand, liberal rules make it much easier for people to fix
problems with memory errors. I agree that this is an important
concern. For example, under Bill's criterion F1, the only required fix
to String is to add a "final" qualifier, and maybe adjust some
constructor code. Similarly, V3-V6 magically make every double-check
idiom work reliably if you add a "volatile" qualifier in the right
place.
This is the decision I said I didn't want to have to make.
I should also have said that in the absence of alternatives, the
decision seems inevitable: We surely need to pick Easy over Fast.
If I had thought harder about this, I probably would have not proposed
special classes that make liberal versions harder to express, but
maybe instead special classes that make weaker forms even possible to
express. Unfortunately though, I don't know how to even phrase some
of these things as classes. For example, in contradiction to V4,
suppose I want to grab a volatile ref field and hold it in a local to
avoid multiple barriers while using it to access multiple fields? In
the absence of ways to express these things, do I just live with the
fact that I cannot do them?
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT