RE: Thread.yield() hangs win98 [was Re: Houston, we have threads...]

["Boehm, Hans" <hans_boehm at hp dot com>]

Given a choice, I would argue against implementing Thread.yield() as a noop.
But if client code is written corectly, it's probably not a disaster to do
so.

I think it's fairly common to wait for a change in some global volatile
variable with code along the following lines:

i = 0;
while (variable doesn't have the value I want) {
  wait_exponential(++i);
}

where wait_exponential waits for time roughly exponential in its argument,
ideally by spinning for small arguments, calling Thread.yield() for medium
arguments, and calling Thread.sleep() for large arguments.  (I suspect it's
also fairly common, but wrong, to do this without eventually calling
Thread.sleep().)  I've done this a lot, though not usually in Java code.
(There's code along these lines in the hash synchronization implementation.)

Theoretically, you should perhaps never do this, and always call something
like Object.wait() instead.  But in reality there are often reasons to wait
in a loop like the above, including the fact that most implementations of
other thread wait primitives immediately force a context switch, which can
be a performance disaster on a multiprocessor.

If you make Thread.yield() a noop, the above will probably perform worse,
especially since the minimum sleep interval on something like Linux/X86 is
typically really 20msecs.

Hans

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Friday, December 14, 2001 7:35 AM
> To: Adam Megacz
> Cc: java@gcc.gnu.org
> Subject: Re: Thread.yield() hangs win98 [was Re: Houston, we have
> threads...]
> 
> 
> 
> 
> On 14 Dec 2001, Adam Megacz wrote:
> > BTW, win32 Thread.yield() is really messed up -- Sleep(0) and
> > SwitchToThread() both cause win98 to "become busy" -- an OS-level
> > hang... I've disabled it (yield == noop) for now.
> 
> That might be the best thing anyway.  Thread.yield() doesn't 
> have to do
> anything, and I suspect it exists mainly for non-premptive 
> thread systems.
> 
> Jeff
>