One point that Sarita didn't mention in support of the
weaker synchronization semantics is that it is the more
conservative choice. That is, if we choose the weaker
semantics and later discover that it's trivial to give
the stronger semantics, and that there is sufficient
use of the stronger semantics to justify the change,
it isn't so hard to change: only the JVMs have to be
modified, and anyway, we've determined it isn't so hard
to deliver the extra guarantees. If, on the other hand,
we choose the stronger semantics, and it turns out that
it is very expensive to implement in some systems (such
as software DSM, for example), so that we want to scale
back to the weaker semantics, that change may break a
lot of user code--the programmers may not even realize
that they were depending on the stronger semantics--they
may just have been using the faulty "memory barrier"
kind of reasoning Sarita mentioned, and it turned out
to be okay, at least for the cases they tested.
Of course, we should pick whichever one we think is better,
but in the absence of clear evidence one way or the other,
I believe we should go with the weaker semantics.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:01 EDT