Java concurrency JDK 1.6: is busy waiting better than signaling? Valid Java #51

Item 51 of Joshua Bloch's "effective Java" does not depend on the thread scheduler, nor does it unnecessarily retain threads in the running state Reference text:

Then continue to display the busy waiting micro benchmark and the correct use signal In the book, busy waiting performs 17 round trips per second, while the waiting / notification version performs 23000 round trips per second

However, when I tried the same benchmark on JDK 1.6, I saw the opposite - the busy wait is 760K round trip / s, while the wait / notification version is 53.3k round trip / S - that is, the wait / notification time should be ~ 1400 faster, but the result is about 13 times slower?

I know that busy waiting is not good, and the signal is still better - the CPU utilization of the busy waiting version is about 50%, while the dwell rate of the waiting / notification version is about 30% – but is there anything to explain the numbers?

If it helps, I run jdk1 on win 7 X64 (core i5) 6 (32 bits)

Update: source is as follows To run a busy workbench, change the base class of pingpongqueue to busyworkqueue import Java util. LinkedList; import java. util. List;

abstract class SignalWorkQueue { 
    private final List queue = new LinkedList(); 
    private boolean stopped = false; 

    protected SignalWorkQueue() { new WorkerThread().start(); } 

    public final void enqueue(Object workItem) { 
        synchronized (queue) { 
            queue.add(workItem); 
            queue.notify(); 
        } 
    } 

    public final void stop()  { 
        synchronized (queue) { 
            stopped = true; 
            queue.notify(); 
        } 
    } 
    protected abstract void processItem(Object workItem) 
        throws InterruptedException; 
    private class WorkerThread extends Thread { 
        public void run() { 
            while (true) {  // Main loop 
                Object workItem = null; 
                synchronized (queue) { 
                    try { 
                        while (queue.isEmpty() && !stopped) 
                            queue.wait(); 
                    } catch (InterruptedException e) { 
                        return; 
                    } 
                    if (stopped) 
                        return; 
                    workItem = queue.remove(0); 
                } 
                try { 
                    processItem(workItem); // No lock held 
                } catch (InterruptedException e) { 
                    return; 
                } 
            } 
        } 
    } 
}

// HORRIBLE PROGRAM - uses busy-wait instead of Object.wait! 
abstract class BusyWorkQueue {
    private final List queue = new LinkedList();
    private boolean stopped = false;

    protected BusyWorkQueue() {
        new WorkerThread().start();
    }

    public final void enqueue(Object workItem) {
        synchronized (queue) {
            queue.add(workItem);
        }
    }

    public final void stop() {
        synchronized (queue) {
            stopped = true;
        }
    }

    protected abstract void processItem(Object workItem)
            throws InterruptedException;

    private class WorkerThread extends Thread {
        public void run() {
            final Object QUEUE_IS_EMPTY = new Object();
            while (true) { // Main loop
                Object workItem = QUEUE_IS_EMPTY;
                synchronized (queue) {
                    if (stopped)
                        return;
                    if (!queue.isEmpty())
                        workItem = queue.remove(0);
                }

                if (workItem != QUEUE_IS_EMPTY) {
                    try {
                        processItem(workItem);
                    } catch (InterruptedException e) {
                        return;
                    }
                }
            }
        }
    }
}

class PingPongQueue extends SignalWorkQueue {
    volatile int count = 0;

    protected void processItem(final Object sender) {
        count++;
        SignalWorkQueue recipient = (SignalWorkQueue) sender;
        recipient.enqueue(this);
    }
}

public class WaitQueuePerf {
    public static void main(String[] args) {
        PingPongQueue q1 = new PingPongQueue();
        PingPongQueue q2 = new PingPongQueue();
        q1.enqueue(q2); // Kick-start the system

        // Give the system 10 seconds to warm up
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
        }

        // Measure the number of round trips in 10 seconds
        int count = q1.count;
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
        }
        System.out.println(q1.count - count);

        q1.stop();
        q2.stop();
    }
}

Solution

In your test, the queue keeps getting new items, so there is very little busy waiting

If the queue gets a new item every 1ms, you can see that busy waiting will take most of the time to burn the CPU It slows down the rest of the application

So it depends If you are busy waiting for user input, it must be wrong; Busy waiting in lockless data structures like atomic integer is certainly good