Is wait(1) in a non-blocking while(true)-loop more efficient than using wait() and notify()?

Question

Does a while(true) Java loop together with wait(1) use more or less resources than a blocking loop with wait() and notify()?

And do the CPU cores have some special (hardware) implementations to allow wait(1)? If yes, are there any limitations while working with such non-blocking loops?

An example:

while(true){
    wait(1);
    //do the job here...
}

(Just a note: Without the wait(1) a core would go radical 100% in a while(true) loop...)

Answer 1

As to the original question of why while (true); takes up more CPU than while (true) { wait(1); }, consider: a modern CPU can perform billions of instructions per second. With the wait(1) loop, assuming it is perfect and waits exactly one millisecond each time, you're limiting the CPU to one thousand instructions per second. Without it, there's no limit and it can run the tight loop billions of times per second instead.

As to the new question of which is more efficient, the while (true) { wait(1); } approach vs. wait() and being notify()ed...

Well let's say you're waiting on a condition. Option one:

while (true) {
    wait(1);
    if (condition()) {
        break;
    }
}

vs.

wait();

and elsewhere:

//code which causes condition() to be true
notify();

Say it takes 10 seconds for condition to be true. In the first approach, you call wait(1) 10,000 times and check condition() 10,000 times. In the second approach, you call wait() once and notify() once.

Answer 2

Is this a trick question?

When you put a "wait()" into a loop, it releases the synchronization variable, allowing some other thread to go forward and eventually notify back to this thread that it can continue. The thread won't proceed, and won't use any cpu cycles, until it gets that notify. And that's why wait/notify must be called from within sync'd blocks or methods (not clear if you are doing that here).

By contrast, a "while ... true" is an infinite loop which is going to use every cpu cycle you give it, until the end condition is met.

I recommend a good book on Java threads and synchronization, like http://www.amazon.com/Multithreaded-Programming-Java-Technology-Lewis/dp/0130170070

Answer 3

It does use more resources, and in general is not a good design. You are far better off waiting properly as even if you don't get better performance in one specific test on one specific hardware you will get better performance in other suggestions.

This will become especially important if you have a lot of these threads running as the overhead is per thread.

Answer 4

Basically, Claudiu is right: CPU are very fast indeed.

But there is also another factor to consider: Actually wait(1) is always needed in non-blocking threads to allow other threads to continue. Because if there is no wait at all, the OS can't allocate resources to any other thread and they will starvate. On the other side, wait(1) could in reality cause a much longer wait depending how the OS allocates the resources. But that's up to the OS.

When programming, there are always 2 factors to consider:

1. the amount of cache/RAM, and

2. the time needed for a thread/process.

Therefore it's all about the amount of resources used PER TIME: MB/s (or in general: Bytes/s). You can't only make the right decisions based on the allocated resources as many programmers intend to do. It's even possible be that above non-blocking floop uses a lot less resources than a blocking one, because there is no synchronisation overhead. So never forget the time dimension.

Conclusion: Faster, non-blocking programs (can) use less resources.