Monitors – The Basic Idea of Java Synchronization

by

If you took operating system course in college, you might remember that monitor is an important concept of synchronization in operating systems. It is also used in Java synchronization. This post uses an analogy to explain the basic idea of “monitor”.

1. What is a Monitor?

A monitor can be considered as a building which contains a special room. The special room can be occupied by only one customer(thread) at a time. The room usually contains some data and code.

If a customer wants to occupy the special room, he has to enter the Hallway(Entry Set) to wait first. Scheduler will pick one based on some criteria(e.g. FIFO). If he is suspended for some reason, he will be sent to the wait room, and be scheduled to reenter the special room later. As it is shown in the diagram above, there are 3 rooms in this building.

In brief, a monitor is a facility which monitors the threads’ access to the special room. It ensures that only one thread can access the protected data or code.

2. How is it implemented in Java?

In the Java virtual machine, every object and class is logically associated with a monitor. To implement the mutual exclusion capability of monitors, a lock (sometimes called a mutex) is associated with each object and class. This is called a semaphore in operating systems books, mutex is a binary semaphore.

If one thread owns a lock on some data, then no others can obtain that lock until the thread that owns the lock releases it. It would be not convenient if we need to write a semaphore all the time when we do multi-threading programming. Luckily, we don’t need to since JVM does that for us automatically.

To claim a monitor region which means data not accessible by more than one thread, Java provide synchronized statements and synchronized methods. Once the code is embedded with synchronized keyword, it is a monitor region. The locks are implemented in the background automatically by JVM.

3. In Java synchronization code, which part is monitor?

We know that each object/class is associated with a Monitor. I think it is good to say that each object has a monitor, since each object could have its own critical section, and capable of monitoring the thread sequence.

To enable collaboration of different threads, Java provide wait() and notify() to suspend a thread and to wake up another thread that are waiting on the object respectively. In addition, there are 3 other versions:

wait(long timeout, int nanos)
wait(long timeout) notified by other threads or notified by timeout. 
notify(all)

Those methods can only be invoked within a synchronized statement or synchronized method. The reason is that if a method does not require mutual exclusion, there is no need to monitor or collaborate between threads, every thread can access that method freely.

Here are some synchronization code examples.

Reference:
1. Java Doc for Object
2. Thread synchronization
3. Locks and Synchronization
4. notify() vs notifyAll()

8 thoughts on “Monitors – The Basic Idea of Java Synchronization”

  1. Of course, this information could be stale, but i didn’t find other articles about new modifications in Java synchronization.

  2. I could be wrong, but if you check “Thin Locks: Featherweight Synchronization for Java” article you will see not every object and class has association with monitor. For example, most objects are created with “thin lock”, and monitor is synonymous with “fat lock”, which could be obtained by inflating “thin lock”.

  3. A mutex is NOT a binary semaphore. Semaphores can be signaled and waited on by any thread, whereas a mutex lock can only be released (unlocked) by the thread that acquired (locked) it.

Leave a Comment