Re: Massive performance loss from OS::sleep hack

Or more likely they'll continue to maintain a sched_yield that isn't
posix compliant. We may just want to add some sort of interface so the
jvm can tell the kernel that sched_yield should be non-compliant for
the current process.



On 9/15/07, Daniel Eischen <deischen@xxxxxxxxxxx> wrote:
On Sat, 15 Sep 2007, Kurt Miller wrote:

Hello Kris,

I recall why I added the os_sleep() call. While working on the
certification
testing one of the JCK tests was deadlocking. The test itself was faulty
in
that it created a high priority thread in a tight yield loop. Since
pthread_yield() on a single processor system will not yield to lower
priority threads, the higher priority thread effectively blocked the
lower priority thread from running and the test deadlocked.

I filed a formal appeal to have the JCK test corrected. However since the
api states:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#yield()
"Causes the currently executing thread object to temporarily pause
and allow other threads to execute."

the appeal was denied. I further argued that many publications written
by or or-authored by Sun employees state that Thread.yield() can not
be relied upon in this fashion:

[ ... ]

It's odd that Sun would take this position since the POSIX behavior
for sched_yield() is:

The sched_yield() function shall force the running thread to
relinquish the processor until it again becomes the head of its
thread list. It takes no arguments.

The "its thread list" mentioned above is the list of threads for its
given priority. POSIX has a notion of a list of threads for each
given priority; in SCHED_RR and SCHED_FIFO scheduling the higher
priority threads will always run before lower priority threads.

Sun's defined Java behavior, or their interpretation, of Thread.yield()
is not obtainable on a POSIX compliant system using sched_yield()
(or pthread_yield()). Even using scope system threads or libthr,
the kernel scheduler should run the higher priority threads before
lower priority threads.

I suspect that Sun will eventually be forced to change their
documented behavior for Thread.yield().

--
DE
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Massive performance loss from OS::sleep hack
    ... testing one of the JCK tests was deadlocking. ... It's odd that Sun would take this position since the POSIX behavior ... priority threads will always run before lower priority threads. ...
    (freebsd-performance)
  • Re: threading
    ... The scheduler will preempt execution of lower priority threads with higher ... Chris Tacke, Embedded MVP ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: threading
    ... The scheduler will preempt execution of lower priority threads with higher ... Chris Tacke, Embedded MVP ...
    (microsoft.public.dotnet.framework.compactframework)