2

I've got some code that looks like the following:

while (this.conditionIsNotYetMet){
    if (timeout()) break;
    // Don't do anything, just wait till the condition is 
    // filled by a different thread or timeout occurs.
}
performSomeCode(); // this code relies on the condition having been met

The code works - eventually the other thread fills the condition, and the code executes.

I'm curious as to whether or not it would be a good idea to throw in a Thread.yield() - it seems to be correct either way, and at this stage I can't feel a performance difference - but I'm concerned that in the future it might make a difference, e.g. on a different platform.

i.e. code would become

while (this.conditionIsNotYetMet){
    if (timeout()) break;
    Thread.yield(); // <----  CHANGE IS HERE!!!!
    // Don't do anything, just wait till the condition is 
    // filled by a different thread or timeout occurs.
}
performSomeCode(); // this code relies on the condition having been met

I'm aware that there's probably a much more formal way to achieve this pattern using locks or AsynchronousTasks, but this solution works well at the moment and is clear enough, so why change?

Alex
  • 18,332
  • 10
  • 49
  • 53

3 Answers3

1

yield() is useful in the cases where you are seeing stagnation on other threads. In other words, you have a very active thread that's somehow always taking priority over some other thread that never really gets to do anything. Calling yield() from your active thread forces it to give change to another running thread.

If your program is as simple as your example, you probably do not need to call yield, plus depending on how timeout() is implemented (if it has a Thread.sleep() or Object.wait() inside) it will also implicitly result a context switch just like yield would.

So, you do not need to write it, but you're probably getting the effects of it already anyway.

PS: As Extreme Coders points out, you probably want to use a wait-notify pattern, here's an example

Community
  • 1
  • 1
Miquel
  • 15,405
  • 8
  • 54
  • 87
  • 4
    If you call yield() repeatedly it will do nothing 99%+ of the time. – Peter Lawrey Apr 25 '13 at 06:32
  • Ok, I've had a look at the example you've linked... I'm a little confused about how to use the lock (not the condition) in my situation. I don't have a shared resource that I'm guarding here, I simply want one thread to wait for a condition (caused by another thread) to occur before continuing. Where should I call lock.lock()? – Alex May 02 '13 at 02:18
  • Sorry about the confusion, I was actually pointing you towards the first code snippet in the answer from Jared Russel. That one does not use lock, but wait/notify – Miquel May 02 '13 at 10:03
1

No, you should almost never use yield() at all, and definitely not for waiting on a condition to become true. You should instead look into a "real" concurrency control mechanism like a Condition (which causes the thread to sleep until awoken by another thread) or a CountDownLatch (which causes the thread to sleep until a certain number of signals have happened).

Steven Schlansker
  • 37,580
  • 14
  • 81
  • 100
0

Calling yield() is just a hint to the OS and unless there is a thread waiting it is likely to do nothing. If you want to give the CPU a break you can call Thread.sleep(10); for 10 ms, or shorter if you like.

BTW Given you are waiting for a timeout you could call

Thread.sleep(timeUntilTimeoutInMilliSeconds);
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I guess I'm not really concerned about chewing CPU, just that I don't want my while loop to slow down the other threads... So it sounds like you're saying that yield is appropriate for this? – Alex Apr 25 '13 at 07:19
  • It is appropriate if you don't have free CPUs, if you have free CPUs, it won't make any difference (or hurt) – Peter Lawrey Apr 25 '13 at 07:31
  • 1
    Well, the tight loop may still hurt your other thread, in that the CPU will get hotter & the CPU's frequency will then decrease across all threads. (And indirectly, it may result in a small amount of glacial ice melt) ;-) – Luke Usherwood Oct 21 '20 at 11:01