Prev: Enum Idiom Question
Next: Suggession for your website
From: Robert Klemme on 1 Jun 2010 17:49
On 01.06.2010 22:46, Daniel Pitts wrote:
> 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/>

I found Doug Lea's "Concurrent Programming in Java" very good. Plus, he
created large parts of java.util.concurrent.* - from the source so to say.

http://g.oswego.edu/

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Arne Vajhøj on 1 Jun 2010 19:26
On 01-06-2010 11:48, Patricia Shanahan wrote:
> 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.

As usual bug => sync problem but no bug => ?.

Arne
From: Stanimir Stamenkov on 2 Jun 2010 02:53
Tue, 01 Jun 2010 19:31:02 +0200, /Robert Klemme/:
> On 31.05.2010 23:17, Stanimir Stamenkov wrote:
>> 30 May 2010 22:15:14 GMT, /Stefan Ram/:
>>
>>> 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.
>> (...)
>> 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.

I was merely pointing out Thread.yield() is not effectively a
no-operation and there are use cases for it, but surely not for
synchronization. I don't think we disagree.

--
Stanimir
From: Ian Shef on 3 Jun 2010 17:13
Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote in
news:ZkeNn.21080$7d5.5303(a)newsfe17.iad:

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

I don't have the book in front of me, but if I recall correctly:

The book tells you to avoid yield(). It has no testable semantics, and
may be implemented as a NO-OP.

Instead, use sleep(...). However, don't use sleep(0), use sleep(1).

I am at work, my book is at home. Maybe someone with immediate access to the
book can comment?



From: Peter Duniho on 3 Jun 2010 23:05
Ian Shef wrote:
> Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote in
> news:ZkeNn.21080$7d5.5303(a)newsfe17.iad:
>
> <snip>
>> I strong suggest reading Java Concurrency In Practice.
>> <http://virtualinfinity.net/wordpress/technical-book-recommendations/java
>> -concurrency-in-practice/>
>>
>>
>
> I don't have the book in front of me, but if I recall correctly:
>
> The book tells you to avoid yield(). It has no testable semantics, and
> may be implemented as a NO-OP.
>
> Instead, use sleep(...). However, don't use sleep(0), use sleep(1).
>
> I am at work, my book is at home. Maybe someone with immediate access to the
> book can comment?

I don't have the book, and can't comment on the specifics of yield(),
though your description sounds reasonable to me.

On the topic of sleep(), on Windows the difference between a sleep of 0
ms and a sleep of 1 ms is that a 0 ms sleep yields only to threads of
the same priority (higher priority threads will have pre-empted
already), while 1 ms sleep will yield to any runnable thread.

Perhaps Java has a similar thread scheduler (and inasmuch as it may just
delegate thread scheduling to the OS, though it doesn't have to, it
would of course inherit that behavior when running Java on Windows).

Pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Enum Idiom Question
Next: Suggession for your website