Hans wrote...
> I think the official Thread.yield() spec curently states:
>
> Causes the currently executing thread object to temporarily pause and allow
> other threads to execute.
>
> ...
>
> My intuition is that the current spec has roughly the right level of
> ambiguity, and it would be nice to avoid changing it.
Some people think that it is just barely ambiguous enough.
Quick background: In the days before most JVMs preempted, people used
to superstitiously liberally sprinkle yields in their code, hoping to
improve liveness. (I think the famous Volanomark code was guilty of
this). Preemptive JVMs, especially on multiprocessors, ought to just
ignore this. They can do so since the spec doesn't say WHEN the
thread will pause. If it does so at some future timeslice, they can
still claim to meet spec.
Conversely though, because nearly all current J2SE JVMs are
pre-emptive, I suspect that most people have stopped using yield in
this way, or at all, which means that they may well encounter liveness
problems when running on JVMs that don't pre-empt (I suspect that some
J2ME JVMs don't?). This isn't a spec problem, but this fact won't make
these people any happier.
Also of note, the Real-Time Java spec (http://www.rtj.org) strengthens
the definition of yield to say:
Page 9:
A thread that performs a yield will be given access to the processor
after waiting threads of the same execution eligibility.
Page 18:
A thread that performs a yield() will be given access to the processor
after wait-ing threads of the same priority.
page 41:
A thread that performs a yield() goes to the tail of the runnable
queue for its priorityLevel .
(Oddly, none of this appears in the javadoc-style spec for
RealTimeThread.yield or in the javadoc for the reference
implementation classes.)
-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:37 EDT