I vote that we leave the spec for sleep and yield alone. At the moment it
is implementable on all the platforms I'm aware of. If you want to change
it then it ceases to be the province of this JSR and moves to some set of
others eg pthreads. The central problem is that a JVM is seldom built in
isolation but sits on some pre-existing semantics delivered by the OS. Now
in some cases those semantics can be modified but when it comes to
threading that becomes tricky. In most cases the JVM threading is simply a
thin veneer on top of some underlying threads package eg pthreads. Thus
Thread.yield() quickly turns into pthread_yield() which does precisely what
it wants to do and that is generally platform dependent. I think that the
best that we can do in this JSR is to look for some form of words which
ensures that Thread.yield() MUST be given the OPPORTUNITY to yield to other
thraeds. At least that would prevent javac from removing calls to
Thread.yield. It would not however prevent a JIT, knowing it was building
code for a platform on which Thread.yield was a no-op, from removing the
call. I think it's unrealistic to assume that any code built to rely on
the semantics of Thread.yield will be universally portable any more than it
would be if a loop in that code were designed such that it required a
teraflop processor in order to meet some timing constraint. At some point
code ceases to be universally portable due to timing or scheduling
constraints. Surely the solution is to pre-req some particular realtime OS
in addition to Java. Trying to change the Java spec such that it is only
implementable on a 'realtime' OS doesn't seem the correct solution.
Martin Trotter
-------------------------------
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