Prev: Enum Idiom Question
Next: Suggession for your website
From: Stanimir Stamenkov on 31 May 2010 17:17
30 May 2010 22:15:14 GMT, /Stefan Ram/:
> Eric Sosman<esosman(a)ieee-dot-org.invalid> writes:
>
>> Thread.yield() is better than Thread.sleep() because it "notices"
>> the change of state sooner.
>
> Some years ago in de.comp.lang.java, some people told me,
> Thread.yield() was effectively a no-operation, so one should
> never use it.

I've recently experimented with implementing (Java 1.4 compatible)
asynchronous I/O for copying files using two threads just to see if
it could be any better than FileChannel.transferTo(). I've
basically tried to read into a buffer in one thread, next write it
out in another, while the reading thread fills in a second buffer to
be written next.

Because I've not put much effort into it and I've not done my
synchronization quite right the whole thing basically ended in
reading the whole input while writing quite small (non-consecutive)
part of it. Using Thread.yield() in the reading thread after
reading a block of input made the operation complete normally for me
because it gave chance to the writing thread perform some
preconditions for the synchronization I was relying to.

However, as Eric Sosman has pointed out in another reply,
Thread.yield() is not a way to achieve synchronization because if
there are more (most probably unrelated) threads, it is not
guaranteed which one of them will be run after pausing the current
thread. But it does work (is not a NOP) and I think it could be
used as minor hint for fine-tuning heavy background processes and
the like.

--
Stanimir
From: Owen Jacobson on 31 May 2010 23:39
On 2010-05-30 14:25:24 -0400, Marcin Rodzik said:

> 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.
>
> MR

It all eventually makes its way down to the OS's scheduler, which hands
out timeslices to processes and threads.

..sleep(n) says "I'm done with my timeslice, and please don't give me
another one for at least n milliseconds." The OS doesn't even try to
schedule the sleeping thread until requested time has passed.

..yield() says "I'm done with my timeslice, but I still have work to
do." The OS is free to immediately give the thread another timeslice,
or to give some other thread or process the CPU the yielding thread
just gave up.

..wait() says "I'm done with my timeslice. Don't give me another
timeslice until someone calls notify()." As with sleep, the OS won't
even try to schedule your task unless someone calls notify (or one of a
few other wakeup scenarios occurs).

Threads also lose the remainder of their timeslice when they perform
blocking IO and under a few other circumstances. If a thread works
through the entire timeslice, the OS forcibly takes control roughly as
if .yield() had been called, so that other processes can run.

You rarely need yield, but if you have a compute-heavy app with logical
task boundaries, inserting a yield *might* improve system
responsiveness (at the expense of time -- context switches, even just
to the OS and back, aren't free). Measure and test against goals you
care about, as always.

-o

From: Patricia Shanahan on 1 Jun 2010 11:48
Joshua Cranmer wrote:
....
> 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.
>

I have considered another use for yield. During testing of shared memory
code, it might be useful to scatter a few yield calls at random
locations. If the synchronization is correct, they will make no
functional difference. If there is a bug, they may allow an otherwise
rare context switch to bring it out.

Patricia
From: Robert Klemme on 1 Jun 2010 13:31
On 31.05.2010 23:17, Stanimir Stamenkov wrote:
> 30 May 2010 22:15:14 GMT, /Stefan Ram/:
>> Eric Sosman<esosman(a)ieee-dot-org.invalid> writes:
>>
>>> Thread.yield() is better than Thread.sleep() because it "notices"
>>> the change of state sooner.
>>
>> Some years ago in de.comp.lang.java, some people told me,
>> Thread.yield() was effectively a no-operation, so one should
>> never use it.
>
> I've recently experimented with implementing (Java 1.4 compatible)
> asynchronous I/O for copying files using two threads just to see if it
> could be any better than FileChannel.transferTo(). I've basically tried
> to read into a buffer in one thread, next write it out in another, while
> the reading thread fills in a second buffer to be written next.
>
> Because I've not put much effort into it and I've not done my
> synchronization quite right the whole thing basically ended in reading
> the whole input while writing quite small (non-consecutive) part of it.
> Using Thread.yield() in the reading thread after reading a block of
> input made the operation complete normally for me because it gave chance
> to the writing thread perform some preconditions for the synchronization
> I was relying to.
>
> However, as Eric Sosman has pointed out in another reply, Thread.yield()
> is not a way to achieve synchronization because if there are more (most
> probably unrelated) threads, it is not guaranteed which one of them will
> be run after pausing the current thread. But it does work (is not a NOP)
> and I think it could be used as minor hint for fine-tuning heavy
> background processes and the like.

What you describe is merely a workaround since you said yourself that
you did the synchronization improperly. I'd rather do a proper
implementation which does not need such hacks. My 0.02EUR.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Daniel Pitts on 1 Jun 2010 16:46
On 6/1/2010 10:31 AM, Robert Klemme wrote:
> On 31.05.2010 23:17, Stanimir Stamenkov wrote:
>> 30 May 2010 22:15:14 GMT, /Stefan Ram/:
>>> Eric Sosman<esosman(a)ieee-dot-org.invalid> writes:
>>>
>>>> Thread.yield() is better than Thread.sleep() because it "notices"
>>>> the change of state sooner.
>>>
>>> Some years ago in de.comp.lang.java, some people told me,
>>> Thread.yield() was effectively a no-operation, so one should
>>> never use it.
>>
>> I've recently experimented with implementing (Java 1.4 compatible)
>> asynchronous I/O for copying files using two threads just to see if it
>> could be any better than FileChannel.transferTo(). I've basically tried
>> to read into a buffer in one thread, next write it out in another, while
>> the reading thread fills in a second buffer to be written next.
>>
>> Because I've not put much effort into it and I've not done my
>> synchronization quite right the whole thing basically ended in reading
>> the whole input while writing quite small (non-consecutive) part of it.
>> Using Thread.yield() in the reading thread after reading a block of
>> input made the operation complete normally for me because it gave chance
>> to the writing thread perform some preconditions for the synchronization
>> I was relying to.
>>
>> However, as Eric Sosman has pointed out in another reply, Thread.yield()
>> is not a way to achieve synchronization because if there are more (most
>> probably unrelated) threads, it is not guaranteed which one of them will
>> be run after pausing the current thread. But it does work (is not a NOP)
>> and I think it could be used as minor hint for fine-tuning heavy
>> background processes and the like.
>
> What you describe is merely a workaround since you said yourself that
> you did the synchronization improperly. I'd rather do a proper
> implementation which does not need such hacks. My 0.02EUR.
>
> Kind regards
Also, yield() does nothing for the "happens-before" relationship of any
two threads. In other words, there may still be memory barriers and
other synchronization issues not prevent by yield().

I strong suggest reading Java Concurrency In Practice.
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Enum Idiom Question
Next: Suggession for your website