Behaviour of wait()/notify()

Question

Until recently, I was sure that notify wakes up only waiting threads. This is proven by this program:
class X extends Thread {     // Incomplete
    final Object lock;
    X(final Object lock) { this.lock = lock;  }
    static void log(String msg){ System.out.println((System.currentTimeMillis() - start) + ", " + Thread.currentThread().getName() + ": " + msg);}
    static void sleep1(long time) {     try {Thread.sleep(time);} catch(InterruptedException ie) {log("sleeping interrupt");}}
    public void run() {
        try {
            log("waiting");
            synchronized(lock) {
                lock.wait(); // halts forever
            log("waked up");
        catch(InterruptedException ie) {
            log("interrupted");
    static final    long start = System.currentTimeMillis();
    public static void main(String[] args) {
        Object lock = new Object();
        synchronized(lock) {lock.notify();} // notify
        new X(lock).start();  // create a thread to wait for the notification
}However, the following code breaks the rule:
class GamePlayer implements Runnable {     // Incomplete
    protected GamePlayer other;
    protected boolean myturn = false;
    protected synchronized void setOther(GamePlayer p) {
        other = p;
    synchronized void giveTurn() { // called by other player
        myturn = true;
        notify();          // unblock thread
    void releaseTurn() {
        GamePlayer p;
        synchronized(this) {
            myturn = false;
            p = other;
        p.giveTurn(); // open call
    synchronized void awaitTurn() throws InterruptedException {
        while (!myturn) wait();
    void move() { /*X.log("moving");*/ }
    public void run() {
        try {
            for (;;) {
                if (Thread.currentThread().getName().compareTo("two") == 0) {
                    X.log("sleeping");
                    X.sleep1(500);
                X.log("wainting");
                awaitTurn();
                move();
                X.log("releasing");
                releaseTurn();
         catch (InterruptedException ie) {} // die
    public static void main(String[] args) {
        GamePlayer one = new GamePlayer();
        GamePlayer two = new GamePlayer();
        one.setOther(two);
        two.setOther(one);
        one.giveTurn();
        new Thread(one, "one").start();
        new Thread(two, "two").start();
}The thread "one" initially owns the monitor, it makes a move and releases the monitor notifying the thread "two". However, the second thread is still sleeping. When it awakes from the sleep, the notification is already sent but the second thread receives it! That is, thread should not be waiting for the monitor event in order to recieve the notification. I'm I missing something?

Answer 1

Can anybody explain the need for synchronized blockin releaseTurn()?
Variable "myturn" is modified by the other thread.Yes, it is modified by another thread. But there is only one active thread. SingleWriterMultiReader paradigm does not block access to a shared resource, it just guards the access by permition granting. I do see any race conditions in releaseTurn() that would need for the synchro block on "myturn", "other" fields.
You need to synchronize both reading and writing of a
shared variable to ensure that one thread sees the
change made by another. This is the other fuction of
keyword "synchronized" (besides exclusive execution
of a block).However, notification is not sent in releaseTurn, it is done in giveTurn.
One more question, there is only one possible
situation to get notification (after myturn => true).
Will the program work properly without the cycle in
awaitTurn(): if (!myturn) wait();If you remove this statement, on the first iteration
both threads will go into wait() and there will be
no-one to notify them.The first thread will not wait, because it's "myturn" is true on the first iteration. It then gives turn to second. If secons have checked "myturn" before it will be waiting and the first thread will notify it. Alteratively, secon thread will check after the first thread had set it to true and will not wait again.