Joseph Shraibman wrote:
Thread.yield() is used under two different scenarios:
+ waiting for certain condition to become true (or false), most
likely this is used in a yield loop, and current thread has
nothing to do but burning CPU cycles in a while loop.
+ be nice and let kernel/pthread know that this would be a good
point to schedule another thread to run, current thread still has
some work to do. Such yields are necessary for non-preemptive
schedulers (e.g. green thread).
In the first case, it's probably OK to sleep(1), but it makes
no sense for the second case.
Uh, sure, forcing yourself to sleep means another thread will be scheduled.
They don't really want to be kicked out of CPU. But you have to
have those yield()'s inserted into a program because otherwise
the program would not work with, say, green threads. For example,
you need to place yields in computational loops to voluntarily give
up execution so it won't occupy all CPU cycles and block other
threads. The yields are convenient points for scheduler to kick
in, but the thread has useful stuffs to do if it's kept in CPU a
little longer. When the same program is running with native threads,
it's more efficient if such yields are considered as nops, since
context switchings are expensive and scheduler is now able to switch
threads at any point. Sleep(1) is even worse in this case because
it leaves CPU idle when it can do useful work. (did I mention
sleep(1) can actually take 10ms, because of clock granularity?)
That being said, by default Sun's JDK converts Thread.yield()
directly to sched_yield() on Linux. Kernel scheduler will decide
whether or not to actually switch context.
-hui
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
