Massive performance loss from OS::sleep hack

Nick Johnson freebsd at spatula.net
Sun Sep 16 18:30:17 PDT 2007


On Sun, 16 Sep 2007, Alfred Perlstein wrote:

> > Thread.yield() could first lower the current thread's priority to
> > the next used priority and then yield, raising the priority back after 
> > the yield.  This isn't perfect, there are race conditions, the next 
> > highest priority  thread(s) could be blocked and not runnable, etc.
> > Maybe just lowering the priority to min or default priority would work
> > well enough.
[snip]
> I think your suggestion about temporarily lowering priority
> makes sense.

That sounds sane to me... if the JVM also keeps track of the fact of 
another thread's having executed, one could lower the priority of the 
thread to some minimum value, and then only raise it again once another 
thread managed to execute... it seems like that would roughly recreate the 
behaviour they're looking for.

(Although maybe just dropping it to the minimum possible priority and then 
restoring the priority the next time the thread ran would be sufficient to 
prevent the deadlock?  Perhaps an absolutely minimum priority value could 
be reserved for threads from which this yielding behaviour was needed so 
in case there were other threads that also had a low priority, they'd 
still have a higher priority than the thread being asked to yield?)

   Nick

-- 
"Courage isn't just a matter of not being frightened, you know. It's being
 afraid and doing what you have to do anyway."
   Doctor Who - Planet of the Daleks
This message has been brought to you by Nick Johnson 2.3b1 and the number 6.
http://healerNick.com/       http://morons.org/        http://spatula.net/


More information about the freebsd-java mailing list