> In finishing up our writeup on fairness, I think we need to guarantee
> some semantics for Thread.yield() and Thread.sleep().
First off I'm not sure this is the right JSR for this - it doesn't seem to
fall within the scope of the JMM.
> Specifically, either operation should have the semantics that with
> some finite probability, some other eligible thread of equal or
> higher priority is allowed to execute at least one instruction.
I think the mention of priority is too strong. In a true priority preemptive
system higher priority threads will already get a chance to execute and so
yield is only a tool for introducing "fairness" within a priority level. But
Java is not a true priority preemptive system so any mention of priority in
the semantics should be removed in my view.
I think sleep does need to be included in the discussion, because although
few people would consider the possibility of an implementation that didn't
execute another runnable thread when the current thread invokes sleep, it
would be a legitimate implementation under the current JLS. But while we are
about it, it would be nice to define what sleep(0) means in Java.
The probabilistic based semantics are probably as much as we should aim for.
The termination guarantees of the two examples provide the minimum
requirements. The fact that introducing other threads breaks the termination
guarantee is not an issue - the guarantee of termination only applies to the
two thread case because that is the only case when you can know which thread
will gain the CPU when a sleep or yield occurs. Anyone who tries to use
yield to do round-robin scheduling is completely on the wrong track. This is
"fairness" in a local sense - the thread invoking sleep or yield will not
monopolise "execution" to the exclusion of all other threads. Global
fairness, as has always been the case, must be programmed into the
application logic.
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:00:36 EDT