Doug Lea wrote:
>>Essentially, it gives us three guarantees:
>>* if there exists some thread that is able to make progress, some
>>thread will make progress (eventually.)
>>* compilers cannot, in general, hoist volatile reads out of potentially
>>infinite loops
>>* compilers cannot, in general, reorder synchronization actions and
>>externally visible actions
>
> Which I hope no one objects to, since they seem to be essential
> guarantees programmers need.
>
Doug,
I don't object to these guarantees, but I don't think it's
obvious that the JMM has to make them, at least not the
first one. Of course we want to make some progress guarantee
to rule out "null" JVMs that simply don't execute any actions.
But other aspects of Java may already force progress, and even
if not, it may make sense to separate the progress guarantees
out entirely from the JMM. That might make it easier to
understand, and also, to revise either the JMM (the safety
aspects) or the progress guarantees in the future.
That said, it's okay with me to put some weak progress
guarantee in the JMM. Stating that guarantee precisely is
tricky--you need to say what exactly constitutes "progress",
and when we can say that a thread "is able to make progress".
The two most common ways in the distributed systems theory
community are "wait-free" and "lock-free". But the property
that Bill is advocating here is, appropriately, much weaker.
It is not even nonblocking (since Java uses locks). The
difference is that the execution of any external action by a
thread is considered to progress. I think the formulation I
gave--in any infinite execution in which no thread executes
infinitely many external actions, every thread either
terminates or executes infinitely many internal actions--
captures the intuition more straightforwardly than the
introduction of a new kind of action with some esoteric
interpretation. Indeed, I'm not entirely sure I understand
if I've interpreted Bill and Jeremy's notion of "catatonia"
or "thread divergent" actions properly, but I haven't seem
from them an example that distinguishes my interpretation
from theirs.
Victor
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT