[Armedbear-devel] Non-zero timeouts CL:SLEEP and THREADS:OBJECT-WAIT below the timer Planck limit interpolated as a nanosecond

Mark Evenson evenson at panix.com
Wed Apr 23 06:09:29 UTC 2014

On 22 Apr 2014, at 15:19, Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi Mark,
> Are you sure? According to this article:
> http://stackoverflow.com/questions/15048170/difference-between-thread-yield-and-thread-sleep#answers
> , there's no stable Yield implementation across platforms on Java. Do we really
> want to provide platform defined behaviour?

[The Java 7 documentation of java.lang.Thread.yield() says that its use provides][1]

"A hint to the scheduler that the current thread is willing to yield its current
use of a processor. The scheduler is free to ignore this hint.  Yield is a
heuristic attempt to improve relative progression between threads that would
otherwise over-utilise a CPU. Its use should be combined with detailed
profiling and benchmarking to ensure that it actually has the desired effect."

[1]: http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#yield%28%29

This clearly denotes that the semantics of a call to yield() constitute a hint to the
scheduler, not an explicit contract.  Java the language is “platform dependent”
behavior on the underlying JVM for many things, of which how yield() precisely
interacts with the scheduler is but one detail.  We don’t refuse to
allow access to underlying java.lang.Thread functions dependent on whether the
underlying JVM has green threads, or M:N mapping models to hardware threads
like some previous versions of Solaris had, now do we?

We already provide access to "platform defined behavior” all over in many
unexamined way: that is part of working on the JVM.  I don’t really see how
[r14690][] is that different, but I am certainly willing to listen to reason.

[r14690]: http://abcl.org/trac/changeset/14690

"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."

Armedbear-devel mailing list
Armedbear-devel at common-lisp.net

More information about the armedbear-devel mailing list