Forcing a spurious-wake up in Java

This question is not about, whether spurious wakeups actually happy, because this was already discussed in full length here: Do spurious wakeups actually happen? Therefore this is also not about, why I do have to put a loop around my wait Statement. What this is about:

I would like to construct a case, where the spurious wake-up happens. What I’ve learned so far in the question linked above is this:

If a Linux process is signaled its waiting threads will each enjoy a nice, hot spurious wakeup.

So it seems this will only work a linux machine, in fact I have Ubuntu 11.04 – 64-Bit. I have written a Java program with one thread waiting for a condition, but without loop and another class on which a thread just waits and get notified by another thread. I thought launching all three threads in one JVM would force the case described above, but it seems like this is not the case.

Has anyone else another idea how to construct such a case in Java?

Forcing Garbage Collection in Java?

Please anyone can tell me if I can force garbage collection in java anyway? Even it was tricky to do. I know about System.gc(); and Runtime.gc(); but they don’t force, they suggest to do GC, but actua

How to change async method call to prevent forcing async up the call stack

If I need to call a method that in turn calls some async method internally, as a fire and forget operation, how can I prevent this call from forcing the async to need to be used up the call stack to

Forcing file deletion on Windows from Java

Is there a programatic way from java to force a file deletion on windows even if the file is locked by some process? I cannot kill the process that locks the file.

java forcing compile-time evaluation

In java, is there a general way to enforce compile-time compilation? In a programming competition I’m in we are limited by the bytecode our robot can use every round while the program is running, so i

css – forcing width of menu items to take up 100%

i have this site: www.yoursdproperty.com i need the top menu items HOME, BUYING PROPERTY, SELLING PROPERTY ETC… to take up 100% of the width of the top bar. if i add more items, i went them to size

When only caring for several algorithms relative performance, would I be better off forcing Java to never JIT compile my methods?

When comparing two different algorithm implementations (thus, not caring for their absolute, but only relative performance) am I better off forcing Java to only run interpreted code? That is, would I

Java projects forcing dependents to adopt Java versions?

Here’s a question. Suppose I have a Maven project (A) that pulls in a different Maven project (B) as a dependency. Both currently use Java 7 to compile. If Project B switches to Java 8, does it fo

Forcing type parameter to implement specific method in java generics

Is there a way to force type parameter in java generics to implement equals method? For example, I wrote this class: public class Bag<Item> implements Iterable<Item> which has contains met

How do I kill processes in Java without forcing it?

I have a Java program that runs a number of other programs. Once the user is finished they have a button to kill all processes, this should kill everything that is running but it should do it with for

Forcing a java app to become the focused window

Is it possible to write something that will auto make a java app the focused window every thirty or so seconds or does this need to be something done at the OS level?

Answers

You can’t force a spurious wakeup, but to the running thread, a spurious wakeup is indistinguishable from a regular wakeup (the source of the event is different, but the event itself is the same)

To simulate a spurious wakeup, simply call notify();

Calling interrupt() isn’t suitable, because doing so sets the interrupt flag, and after a spurious wakeup, the interrupt flag is not set

Original question you’ve refered (as far, as wikipedia article) says that spurious wakeups happens in linux implementation of pthread, as side effect of process being signalled. From your question it seems to me that you missed up “signal” (which is linux inter-process communication method) with Object.notify() (which is java internal inter-thread communication method).

If you want to observe spurious wakeup — you must run your java program and try to send it some signal.

I tried a simple test on Linux, by sending a simple Java process signals (such as QUIT, STOP, CONT, etc.). These did not seem to cause a spurious wakeup.

So (at least to me) it’s still not clear under what conditions a Linux signal will cause a spurious wakeup in Java.

AFAIK, Sun’s JVM uses “green threads”, also known as user-level threads. This means that JVM threads and kernel threads don’t really have to map 1-to-1. Therefore, unless the specification says so, I don’t see why the JVM would conform with the POSIX behavior.

So, even though the specification refers the possibility of spurious wake-ups, it should be hard build a deterministic test that causes one. Considering that the kernel threads running inside the JVM wake-up upon signal, how many green threads will you be waking up? One? Ten? None? Who knows.

“Spurious wakeup” is a hotchpotch and covers any implementation detail in that realm. Therefore it is quite hard to make out what a “real” spurious wakeup is and why another one is “unreal” – let alone on which layer this implementation detail originates. Choose any one from “kernel”, “system library (libc)”, “JVM”, “Java standart library (rt.jar)” or a custom framework built on top of this stack.

The following program shows a spurious wakeup using java.util.concurrent stuff:

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class SpuriousWakeupRWLock {
    static Lock lock = new ReentrantLock();
    static Condition condition = lock.newCondition();
    static int itemsReady;

    public static void main(String[] args) throws Exception {

        // let consumer 1 enter condition wait
        new ConsumerOne().start();
        Thread.sleep(500);

        lock.lock();
        try {
            // let consumer 2 hit the lock
            new ConsumerTwo().start();
            Thread.sleep(500);

            // make condition true and signal one (!) consumer
            System.out.println("Producer: fill queue");
            itemsReady = 1;
            condition.signal();
            Thread.sleep(500);
        }
        finally {
            // release lock
            lock.unlock();
        } 

        System.out.println("Producer: released lock");
        Thread.sleep(500);
    }

    abstract static class AbstractConsumer extends Thread {
        @Override
        public void run() {
            lock.lock();
            try {
                consume();
            } catch(Exception e){
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
        }
        abstract void consume() throws Exception;
    }

    static class ConsumerOne extends AbstractConsumer {
        @Override
        public void consume() throws InterruptedException {
            if( itemsReady <= 0 ){      // usually this is "while"
                System.out.println("One: Waiting...");
                condition.await();
                if( itemsReady <= 0 )
                    System.out.println("One: Spurious Wakeup! Condition NOT true!");
                else {
                    System.out.println("One: Wakeup! Let's work!");
                    --itemsReady;
                }
            }
        }
    }

    static class ConsumerTwo extends AbstractConsumer {
        @Override
        public void consume() {
            if( itemsReady <= 0 )
                System.out.println("Two: Got lock, but no work!");
            else {
                System.out.println("Two: Got lock and immediatly start working!");
                --itemsReady;
            }
        }
    }
}

Output :

One: Waiting...
Producer: fill queue
Producer: released lock
Two: Got lock and immediatly start working!
One: Spurious Wakeup! Condition NOT true!

The used JDK was:

java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.9) (6b20-1.9.9-0ubuntu1~10.04.2)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)

It is based on one implementation detail in java.util.concurrent: The standard Lock has one waiting queue, the Condition has another waiting queue. If the condition is signalled, the signalled thread is moved from the condition’s queue into the lock’s queue. The implementation detail: It is moved at the end of the queue. If another thread is already waiting in the lock queue and this second thread did not visit the condition variable, this thread can “steal” the signal. If the implementation would have put the first thread before the second thread, this would not have happened. This “bonus” could/would be based on the fact that the first thread has got the lock already once and that the waiting time in the condition associated with the same lock is credited to that thread.

I define this as “spurious” because

  • the condition has been signalled only once,
  • only one thread has been awoken by the condition
  • but the thread awoken by the condition found it was not true
  • the other thread was never touching the condition and is therefore “lucky but innocent”
  • a slightly other implementation would have prevented this.

The last point is demonstrated with this code using Object.wait():

public class SpuriousWakeupObject {
    static Object lock = new Object();
    static int itemsReady;

    public static void main(String[] args) throws Exception {

        // let consumer 1 enter condition wait
        new ConsumerOne().start();
        Thread.sleep(500);

        // let consumer 2 hit the lock
        synchronized (lock) {
            new ConsumerTwo().start();
            Thread.sleep(500);

            // make condition true and signal one (!) consumer
            System.out.println("Producer: fill queue");
            itemsReady = 1;
            lock.notify();

            Thread.sleep(500);
        } // release lock
        System.out.println("Producer: released lock");
        Thread.sleep(500);
    }

    abstract static class AbstractConsumer extends Thread {
        @Override
        public void run() {
            try {
                synchronized(lock){
                    consume();
                }
            } catch(Exception e){
                e.printStackTrace();
            }
        }
        abstract void consume() throws Exception;
    }

    static class ConsumerOne extends AbstractConsumer {
        @Override
        public void consume() throws InterruptedException {
            if( itemsReady <= 0 ){      // usually this is "while"
                System.out.println("One: Waiting...");
                lock.wait();
                if( itemsReady <= 0 )
                    System.out.println("One: Spurious Wakeup! Condition NOT true!");
                else {
                    System.out.println("One: Wakeup! Let's work!");
                    --itemsReady;
                }
            }
        }
    }

    static class ConsumerTwo extends AbstractConsumer {
        @Override
        public void consume() {
            if( itemsReady <= 0 )
                System.out.println("Two: Got lock, but no work!");
            else {
                System.out.println("Two: Got lock and immediatly start working!");
                --itemsReady;
            }
        }
    }
}

Output:

One: Waiting...
Producer: fill queue
Producer: released lock
One: Wakeup! Let's work!
Two: Got lock, but no work!

Here the implementation seems to do as I would expect it: The thread using the condition is awoken first.

Final note: The idea for the principle comes from Why does java.util.concurrent.ArrayBlockingQueue use ‘while’ loops instead of ‘if’ around calls to await()? , although my interpretation is different and the code is from myself.

I found a reproducer that forces spurious wakeups in Java bug 6454029. It starts up 30, 60, and then 100 pairs of waiters/notifiers and causes them to wait and notify a specified number of times. It uses standard Object.wait() and Object.notify() rather than the higher-level Lock and Condition objects. I’ve managed to use it to cause spurious wakeups to occur on my linux 64 bit machine with the argument value of 1000000 with both java 1.8.0-b132 and 1.6.0_45. Note that the original filer was complaining about Windows XP, so presumably this works on at least one flavor of windows as well.