Prev: Enum Idiom Question
Next: Suggession for your website
From: Joshua Cranmer on 30 May 2010 17:14
On 05/30/2010 02:25 PM, Marcin Rodzik wrote:
> On May 29, 9:42 pm, Eric Sosman<esos...(a)ieee-dot-org.invalid> wrote:
>> Thread.sleep()
>> Thread.yield()
>> Both techniques are *vastly* inferior to wait().
>
> So whay does yield() exist? Is there any case in which it can be
> preferred?
> Anyway, thanks, I really appreciate your answers.

wait and notify are the Java equivalent to Posix condition
variables--they cause the thread to not run until some condition is met.

Sleep, on the other hand, can be used when you need the thread to not
run for a short while. Yield means to let another thread run if it can
run. The idea is that you might be doing a computationally expensive,
but necessarily synchronous task: every once in a while, you want to
explicitly tell someone else to run.

Sleep is occasionally useful for some timing stuff, and it can be used
in some circumstances to "suggest" certain thread orderings in examples.

Yield is probably much more rarely used, since thread scheduling is
typically rather fair. I can imagine using it before doing something
that would cause a disk cache to be thrashed, or perhaps to tell the
scheduler that it's better to wait for a bit before resuming execution
in heavy usage situations.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
From: Eric Sosman on 30 May 2010 18:06
On 5/30/2010 2:25 PM, Marcin Rodzik wrote:
> On May 29, 9:42 pm, Eric Sosman<esos...(a)ieee-dot-org.invalid> wrote:
>> Thread.sleep()
>> Thread.yield()
>> Both techniques are *vastly* inferior to wait().
>
> So whay does yield() exist? Is there any case in which it can be
> preferred?

I can't think of a reason to use yield(), unless you happen to
be writing Java for one specific platform and you know a lot about
how that platform schedules threads. That is, I cannot think of a
way to use yield() and get the same effect on multiple platforms.

On the surface, it *sounds* simple: yield() "causes the
currently executing thread object to temporarily pause and allow
other threads to execute." But how long is "temporarily," and
which "other threads" are eligible to execute? On many systems,
if thread T1 has higher priority than T2 and calls yield(), the
scheduler will take T1 off the CPU and put it right back on again,
since it's the highest-priority runnable thread. At best, you can
hope that all threads with priority equal to T1's will get a chance
to run before T1 gets the CPU again, but even that's not guaranteed.
Low-priority T2 is not likely to get any increase in CPU time because
of a yield() by high-priority T1.

Even if you create T1 and T2 with equal priority (from Java's
point of view), it may turn out that Java's thread priorities do not
map exactly to those of the underlying platform. Many systems, for
example, keep track of a thread's execution history and adjust a
low-level "scheduling priority" to try to improve overall system
throughput. The default scheduling classes in Solaris, for example,
try to raise the priorities of I/O-bound threads and lower those of
CPU-bound threads. Putting the I/O-bound thread first allows it to
start its next I/O sooner so it can be in progress while the CPU-
bound thread executes. In the face of this kind of dynamic priority
adjustment, it becomes difficult to predict whether T1 or T2 has the
higher "effective" priority.

In short, I can't think of a portable reason to use yield() --
maybe somebody smarter than I am knows of one, but I don't. As to
why it exists, I don't really know but I surmise the Java designers
decided to incorporate most of the POSIX Pthreads facilities, and
Pthreads has yield() analogs (with similar drawbacks). We should
consider ourselves lucky, I guess, that they decided to omit the
horrendous Pthreads cancellation mechanisms!

The newsgroup comp.programming.threads is a good place for thread
questions. Some of the people who wrote the Pthreads standards hang
out there, and may be able to tell you why Pthreads' equivalents of
yield() exist. Lots of those people know Java, too.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: Bent C Dalager on 30 May 2010 18:36
On 2010-05-30, Marcin Rodzik <marteno_rodia(a)o2.pl> wrote:
> On May 29, 9:42�pm, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote:
>> � � �Thread.sleep()
>> � � �Thread.yield()
>> Both techniques are *vastly* inferior to wait().
>
> So whay does yield() exist? Is there any case in which it can be
> preferred?

It might be a fossil from an epoch best forgotten, when the JVM used
green threads on some platforms.

Cheers,
Bent D
--
Bent Dalager - bcd(a)pvv.org - http://www.pvv.org/~bcd
powered by emacs
From: Robert Klemme on 31 May 2010 12:53
On 31.05.2010 00:06, Eric Sosman wrote:
> On 5/30/2010 2:25 PM, Marcin Rodzik wrote:
>> On May 29, 9:42 pm, Eric Sosman<esos...(a)ieee-dot-org.invalid> wrote:
>>> Thread.sleep()
>>> Thread.yield()
>>> Both techniques are *vastly* inferior to wait().
>>
>> So whay does yield() exist? Is there any case in which it can be
>> preferred?
>
> I can't think of a reason to use yield(), unless you happen to
> be writing Java for one specific platform and you know a lot about
> how that platform schedules threads. That is, I cannot think of a
> way to use yield() and get the same effect on multiple platforms.

> In short, I can't think of a portable reason to use yield() --
> maybe somebody smarter than I am knows of one, but I don't. As to
> why it exists, I don't really know but I surmise the Java designers
> decided to incorporate most of the POSIX Pthreads facilities, and
> Pthreads has yield() analogs (with similar drawbacks).

That sounds like a good explanation. I would have offered the guess
that maybe some Java mobile platforms need Thread.yield(). I can't
think of another modern platform that would require Thread.yield().

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: markspace on 31 May 2010 14:27
Robert Klemme wrote:

> On 31.05.2010 00:06, Eric Sosman wrote:
>> In short, I can't think of a portable reason to use yield() --

> That sounds like a good explanation. I would have offered the guess
> that maybe some Java mobile platforms need Thread.yield(). I can't
> think of another modern platform that would require Thread.yield().


I think Brent likely nailed it. yeild() is legacy code that's there
because someday it might get you out of a jam, and because old time
programmers expect to see it. Java monitors are always preferable, and
if you have Java 1.6 then its concurrency utilities are preferable to
rolling your own classes.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Enum Idiom Question
Next: Suggession for your website