As we all are aware, in Java programming language each object in Java is associated with a monitor, which a thread can lock or unlock.
Every object, in addition to having an associated monitor, has an
associated wait set. When an object is first created, its wait set is empty. Elementary
actions that add threads to and remove threads from wait sets are
atomic. Wait sets are manipulated solely through the methods
Object.wait, Object.notify(Notification Action), and Object.notifyAll(Notification Action).
Only one thread at a time may hold a lock on a monitor (i.e at any point only one thread can enter into critical area
which is decided by Java Scheduler based on some criteria (e.g.
FIFO)). Any other threads attempting to lock that monitor are blocked
until they can obtain a lock on that monitor (i.e remaining threads
wait in the Wait Set block of the monitor. If the current thread is
suspended for some reason, then the thread is moved back to the wait
-set area and later rescheduled to acquire the critical area).
As explained in my blog about Object’s House Keeping information
(Java Primitives vs Wrapper : Which one to use) every java object contains lock information.
If any thread want to access instance variables of that object; then
thread must “own” the object’s lock (set some flag in lock memory area).
This is the critical area or lock memory area which holds the lock
related information.
Now after the brief insight into Java object monitor, Let’s visit the
definition of Monitors and Locks :
In concurrent programming, a monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become false. Monitors also have a mechanism for signaling other threads that their condition has been met. A monitor consists of a mutex (lock) object and condition variables. A condition variable essentially is a container of threads that are waiting for a certain condition. Monitors provide a mechanism for threads to temporarily give up exclusive access in order to wait for some condition to be met, before regaining exclusive access and resuming their task.
What is a
Lock ? From the official documentation of Locks and Synchronization(https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html):
- Synchronization is built around an internal entity known as the intrinsic lock or monitor lock.
- Every object has an intrinsic lock associated with it. By convention, a thread has to acquire the object’s monitor lock before accessing them, and then release the monitor lock when it’s done with them. A thread is said to own the lock between the time it has acquired the lock and released the lock. As long as a thread owns a monitor lock, no other thread can acquire the same lock. The other thread will block when it attempts to acquire the lock.
- When a thread releases the lock, a happens-before relationship is established between that action and any subsequent acquisition of the same lock.
- All implicit monitors implement the reentrant characteristics. Reentrant means that locks are bound to the current thread. A thread can safely acquire the same lock multiple times without running into deadlocks.
In Java, this is done with the synchronized keyword, or with
wait and notify.
So a monitor and a lock can not be compared for differences, rather they are complimentary to each other. Every object in Java is associated with a monitor
which a thread can lock or unlock.
Further Reading & Viewing :
- https://howtodoinjava.com/java/multi-threading/multithreading-difference-between-lock-and-monitor/
- Chapter 17 : Threads & Locks (https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html)
- https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html
-
Douglas Schmidt has explained Java Built-in monitors beautifully on his youtube
channel(embedded link below)
What am I missing here ? Let me know in comments section and I'll add
in!
