Massive performance loss from OS::sleep hack

[Alfred Perlstein]

* Nick Johnson <freebsd at spatula.net> [070916 18:30] wrote:
> 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?)

You second suggestion makes more sense as I would guess that the intent
is to lower the priority until the next quantum.

The second part of your second suggestion is not 100% needed (although
it may be helpful) as the scheduler will appopriately run another
thread and they will then contend at that lower level.

-- 
- Alfred Perlstein