为什么在同步块外部调用notifyAll（）时引发IllegalMonitorStateException？

Question

Currently I'm reading the chapter Guarded Blocks of the online Java Concurrency tutorial. As an exercise I created a class to see in practice the proper use of wait() and notifyAll() methods. Yet, there is something in my own code which I'm not able to understand and I would appreciate if you could kindly give me a hand.

Environment:

OS: Fedora Core 17 X86_64
JDK: 1.8.0_05 (64 Bit)

Test case specification:

• Define a class that creates and starts 4 threads,
• The run() method of each thread is in fact an infinite loop and will stop when the user does CTRL+C,
• Each of these threads has to print one letter among {A, B, C, D},
• No matter which one among the four created threads is the current running thread, the alphabetic order of the letters must be respected comparing to the last printed letter.
• Start by printing the letter 'A'

The output which is expected is therefore something like this on the terminal:

A
B
C
D
A
B
C
D
A
B
C
D
...

test case implementation:

/*
My solution is based on a shared lock among threads.
This object has one attribute: a letter, indicating 
the letter that must be printed on the user terminal.
*/
class SharedLock
{
    private char letter;

    public SharedLock(char letter)
    {
        this.letter = letter;
    }

    /*
        Every thread which is owner of the shared lock's
        monitor call this method to retrieve the letter 
        that must be printed according to the alphabetic order.
    */
    public synchronized char getLetter()
    {
        return this.letter;
    }

    /*
        Every thread which is the owner of the shared lock's 
        monitor and besides has just printed its letter, before 
        releasing the ownership of the shared lock's monitor,
        calls this method in order to set the next 
        letter (according to the alphabetic order) to 
        be printed by the next owner of the shared 
        lock's monitor
    */
    public synchronized void setLetter(char letter)
    {
        this.letter = letter;
    }
}


/*
As said earlier each thread has a letter attribute.
So if I create 4 threads, there will be one thread 
for each letter, one which prints only 'A', another 
which prints only 'B', and so on.

Besides each thread's constructor takes as second 
parameter: the shared lock object (described above).

If the letter attribute of a thread which is the owner 
of the shared lock's monitor, is the same as 
the shared lock's letter attribute, then the thread can
print its letter because it respects the alphabetic order
otherwise it has to wait.
*/
class LetterPrinter implements Runnable
{
    private char letter;
    private SharedLock lock;

    public LetterPrinter(char letter, SharedLock lock)
    {
        this.letter = letter;
        this.lock = lock;
    }

    public void run()
    {
        while(true)
        {
            // Here the current thread tries to become the owner of
            // the shared lock's monitor
            synchronized(this.lock)
            {
                /*
                    Test whether the letter attribute of this 
                    thread must be printed. This will happen
                    only if the letter of the shared lock and
                    the thread's letter attribute are the same.
                */
                while(this.lock.getLetter() != this.letter)
                {
                    try
                    {
                        // The letters are different so in order to respect 
                        // the alphabetic order this thread has to wait
                        this.lock.wait();
                    }
                    catch(InterruptedException e)
                    {
                        e.printStackTrace();
                    }
                }
            }

            // printing the letter
            System.out.format("%s: %s%n", 
                Thread.currentThread().getName(), this.letter);

            // preparing for the next letter print according to the 
            // alphabetic order
            switch (this.letter)
            {
                case 'A': this.lock.setLetter('B'); break;
                case 'B': this.lock.setLetter('C'); break;
                case 'C': this.lock.setLetter('D'); break;
                case 'D': this.lock.setLetter('A'); break;
            }

            // And finally releasing the ownership of 
            // the shared lock's monitor
            synchronized(this.lock)
            {
                this.lock.notifyAll();
            }
        }
    }
}

public class MyTestClass
{
    public static void main(String[] args) 
    {
        // creating the shared lock object which is initialized
        // by the letter 'A'. This was the problem specification 
        // we wish to start by 'A'
        SharedLock lock = new SharedLock('A');

        // Creates the four threads with their distinct letter and 
        // their shared lock
        Thread thread1 = new Thread(new LetterPrinter('A', lock));
        Thread thread2 = new Thread(new LetterPrinter('B', lock));
        Thread thread3 = new Thread(new LetterPrinter('C', lock));
        Thread thread4 = new Thread(new LetterPrinter('D', lock));

        // And starting all of the four created threads above.
        thread1.start();
        thread2.start();
        thread3.start();
        thread4.start();
    }
}

This program actually produces the desired output and seems to me to do the job correctly (please correct me if I'm wrong). Yet if you look at the run() method above you will see that at the end the notify() call has also been placed in a synchronized block.

Just to see what happens, I eliminated the synchronized block and I just wrote the notify() alone for releasing the ownership of the lock's monitor and I got

Exception in thread "Thread-0" java.lang.IllegalMonitorStateException
        at java.lang.Object.notifyAll(Native Method)
        at LetterPrinter.run(MyTestClass.java:105)
        at java.lang.Thread.run(Thread.java:745)

According to the documentation of IllegalMonitorStateException :

public class IllegalMonitorStateException extends RuntimeException

Thrown to indicate that a thread has attempted to wait on an object's monitor or to notify other threads waiting on an object's monitor without owning the specified monitor.

Which is exactly my question. Why?

why notify call, when the ownership of the shared lock is being released by the current owner, must also be placed within a synchronized block?

According to the documentation of notify() and notifyAll() :

A thread becomes the owner of the object's monitor in one of three ways:

• By executing a synchronized instance method of that object.
• By executing the body of a synchronized statement that synchronizes on the object.
• For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

And the second one that is, a synchronized statement on the lock is what I do. Therefore every thread which is not the good one (according to the alphabetic order) waits. So when the notify() on the lock is executed, this can be run only by a thread which is the owner of its monitor and no other thread can try to run this as all others are waiting.

So I don't understand why putting the notify() call at the end of the run() method outside a synchronized block, raises the IllegalMonitorStateException exception?

I'm rather beginner in concurrency. Clearly it seems that there is something about the execution of the statements and the OS scheduler which I misunderstand.

Could someone kindly make some clarification?

Answer 1

The answer is in one of the javadocs you quoted:

Thrown to indicate that a thread has attempted to wait on an object's monitor or to notify other threads waiting on an object's monitor without owning the specified monitor.

You have to synchronize on a monitor before waiting on it or notifying a/the thread(s) waiting on it, and that waiting/notifying has to be done inside the synchronized block. As soon as you exit the synchronized block, you no longer own the monitor.

As for the reason you need to own the monitor before waiting/notifying, it's to prevent race conditions, since monitors are usually used for communication between threads. Ensuring only one thread has access to a monitor at a time ensures that all other threads will see "changes" to it.

Also, minor quibble: In your test case, you release the lock before printing, and regain it after printing.

This seems to have worked in your case, perhaps because it seems only one thread is woken up at a time, but if another thread wakes up by itself (called a spurious wakeup ), you could very well get letters out of order. I don't expect it to be a common thing though.

Another way this could go wrong is if it just happens that one thread starts, gets past the lock, gets halted before printing, another thread comes in, prints, etc.

What you want to do is keep the lock throughout the entire method, so you're guaranteed to have only one thread printing at a time.

Answer 2

Not a complete answer, just adding to what user3580294 already said:

Synchronization does more than just prevent two threads from entering the same critical section at the same time. It also guarantees synchronization of the per cpu memory caches on a multiprocessor machine. The java language spec makes this guarantee; If thread A updates a field (ie, an instance variable or a class variable) and then releases a lock, and then thread B acquires the same lock, then thread B will be guaranteed to see the new value that thread A wrote to the field. Without synchronization, there is no guarantee if or when one thread will see new values in fields that were updated by other threads.

Presumeably, if thread A is going to notify an object, it's because thread A changed something that thread B is waiting for. But if thread A did not unlock a lock and thread B did not lock the same lock, then when thread B wakes up, it will not necessarily see what thread A changed.

The language and libraries are designed to not let you make that mistake.