CODEWITHSUNDEEP
javamultithreading
the_kaba
the_kaba

Reputation: 1567

Why prefer wait/notify to while cycle?

I have some misunderstanding with advantages of wait/notify. As i understand processor core will do nothing helpful in both cases so what's the reason tro write complex wait/notify block codes instead of just waiting in cycle? I'm clear that wait/notify will not steal processor time in case when two threads are executed on only one core.

Upvotes: 0

Views: 412

Answers (3)

Giulio Franco
Giulio Franco

Reputation: 3230

In general, your application is not the only one running on the CPU. Using non-spinning waiting is, first of all, an act of courtesy towards the other processes/threads which are competing for the CPU in order to do some useful job. The CPU scheduler cannot know a-priori if your thread is going to do something useful or just spin on a false flag. So, it can't tune itself based on that, unless you tell it you don't want to be run, because there's nothing for you to do.

Indeed, busy-waiting is faster than getting the thread to sleep, and that's why usually the wait() method is implemented in a hybrid way. It first spins for a while, and then it actually goes to sleep.

Besides, it's not just waiting in a loop. You still need to synchronize access to the resources you're spinning on. Otherwise, you'll fall victim of race conditions.

If you feel the need of a simpler interface, you might also consider using CyclicBarrier, CountDownLatch or a SynchronousQueue.

Upvotes: 1

Madhusudana Reddy Sunnapu
Madhusudana Reddy Sunnapu

Reputation: 8247

I think you answered your question almost by saying

I'm clear that wait/notify will not steal processor time in case.

Only thing I would add is, this true irrespective of one core or multi-core. wait/notify wont keep the cpu in a busy-wait situation compared to while loop or periodic check.

what's the reason not to run core but wait? There's no helpful work in any case and you're unable to use core when it's in waiting state.

I think you are looking at it from a single application perspective where there is only one application with one thread is running. Think of it from a real world application (like web/app servers or standalone) where there are many threads running and competing for cpu cycles - you can see the advantage of wait/notify. You would definitely not want even a single thread to just do a busy-wait and burn the cpu cycles.

Even if it a single application/thread running on the system there are always OS process running and its related processes that keep competing for the CPU cycles. You don't want them to starve them because the application is doing a while busy-wait.

Quoting from Gordon's comment

waiting in cycle as you suggest you are constantly checking whether the thing you are waiting for has finished, which is wasteful and if you use sleeps you are just guessing with timing, whereas with wait/notify you sit idle until the process that you are waiting on tells you it is finished.

Upvotes: 1

tucuxi
tucuxi

Reputation: 17945

"Waiting in a cycle" is most commonly referred to as a "busy loop" or "busy wait":

 while ( ! condition()) {
     // do nothing
 }
 workThatDependsOnConditionBeingTrue();

This is very disrespectful of other threads or processes that may need CPU time (it takes 100% time from that core if it can). So there is another variant:

 while ( ! condition()) {
     sleepForShortInterval();
     // do nothing
 }
 workThatDependsOnConditionBeingTrue();

The small sleep in this variant will drop CPU usage dramatically, even if it is ~100ms long, which should not be noticeable unless your application is real-time.

Note that there will generally be a delay between when the condition actually becomes true and when sleepForShortInterval() ends. If, to be more polite to others, you sleep longer -- the delay will increase. This is generally unacceptable in real-time scenarios.

The nice way to do this, assuming that whatever condition() is checking is being changed from another thread, is to have the other thread wake you up when it finishes whatever you are waiting for. Cleaner code, no wasted CPU, and no delays.

Of course, it's quicker to implement a busy wait, and it may justified for quick'n'dirty situations.

Beware that, in a multithreaded scenario where condition() can be changed to false as well as true, you will need to protect your code between the while and the workThatDependsOnConditionBeingTrue() to avoid other threads changing its value in this precise point of time (this is called a race codition, and is very hard to debug after the fact).

Upvotes: 2

Related Questions