Jeremy,
> Except that this isn't really as much about optimizations as it is about
> fairness.
Which is why I used the word "transformation" not "optimisation".
> The original JMM's guarantee about volatiles going straight to
> maing memory doesn't mean anything in this regard, because it didn't have
> any fairness guarantees either. The same transformation I described could
> probably be performed and not violate whatever specification exists.
I do not believe it could. There is a difference between a lack of
"fairness" guarantee due to a thread never being scheduled, and a
re-arrangement of the code that makes it act as if a thread was never
scheduled when in fact it may have been. I believe the intent with
"volatile" in Java, as per Ch 17, was to preclude these sorts of
transformations - to avoid caching of values, hoisting from loops etc. The
memory semantics are then an additional set of properties on top of these
basic ones.
> On the whole, we have avoided fairness issues; we have a section stating
> they are quality-of-service. This is because there has been a relative
> consensus that they are unwanted.
That's not quite the way things evolved. When it was pointed out that
certain transformations could kill liveness there was some debate as to
whether to allow the transformation in principle, but to add fairness
guarantees in some form. There was a consensus that you couldn't add
fairness guarantees without impacting the scheduling guarantees (none!) of
the JVM. We could then have chosen to disallow those transformations.
Instead it was chosen to allow them and to make fairness a QoS issue. I
don't agree with that position.
This latest change is almost an about-face on the previous stance, because
now it has been decided that this isn't a QoS issue after all and that some
fairness (albeit weak fairness) statement must be made.
My problem with the current situation is that as a programmer I know that I
do not want the volatile access hoisted from the loop, but it is far from
clear to me that the "weak fairness constraint" precludes it. My concern is
that there may be other places where I do not expect or want my code to be
rearranged, and maybe the "weak fairness constraint" does not preclude it.
When it comes to variables that can be accessed concurrently, I just want
the system to leave my code the way I wrote it. It makes my job a heck of a
lot simpler.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:03 EDT