Multithreading Java and Interviews Part 2: Mutex, the Java Monitor Model
The second installment to Multithreading and interviews. Here, read an introduction to the basics of Java Multithreading with Mutex, the Java Monitor Model.
Join the DZone community and get the full member experience.Join For Free
In the previous chapter, we learned about the following:
In the previous article, we faced a problem with a shared variable that shouldn't be shared or at least one that we have to define the order for updating this variable.
Java Monitor Model: Both Great and Terrible
Java provides many ways to order access to shared data between threads; here, we start from the most primitive but pretty popular (in legacy projects) way to do it. Java Monitor Model is a model that decides how threads communicate with each other and provides synchronization keywords.
Synchronization Keywords: Synchronize, Wait, and Notify
You might have already mentioned that each object in java has the methods wait or notify. Those keywords are used for synchronization. Every Java Object has the wait/notify/etc words. The reason for this is that each object in Java can be used as a synchronization object, also known as Mutex.
Hidden Java Monitor
Java Monitor Model is like a phantom that orchestrates the threading order. So, let's take a look into this next example below:
You can see that inside the method doPrintSequentially we perform print function surrounded by synchronized(MUTEX) construction. By wrapping code with that Mutex, we give access to that area only 1 thread at a time.
Revealing the Hidden Synchronization Part
We can't say how precisely Java handles synchronization but, generally, it replaces synchronization keywords by a special condition that checks that the current Mutex is taken by some thread, so if we rewrite the previous code, it might look like this:
Basically, it puts all thread in a blocking state until running one release mutex by completing the synchronization part or changing its state to "WAITING".
Java Monitor Rules
- Mutex belongs only to one thread at a time in a synchronized area (or many areas).
- Once threads leave the synchronized area it releases the Mutex.
- The thread can call the wait function and set itself into a WAITING state and it will release mutex automatically.
- Thread(s) with WAITING state can change its state to BLOCKING by received notification from another thread but with the same mutex.
- The thread can notify other WAITING thread(s) but this doesn't release the mutex automatically.
- All threads with BLOCKING state will acquire mutex once it's released but in random order (not LIFO OR FIFO order).
Blocking Thread Safe Queue Implementation
Threads to Run: John and Peter Threads
This Thread Safe Queue will be executed by 2 threads, John and Peter. John will try to get data from the queue and will be blocked because it's empty. The Peter thread will start 1 second later and push a new record in the queue and notify the blocked John thread.
Now, Let's Describe the Process of Getting and Pushing Data in a Thread Safe Queue or Drama in 10 Acts
So, in this example, we described the communication between 2 threads using the keywords synchronize, wait, and notify. But, what if we start more than 1 getter thread? Well, in that case, the situation will be more complex. We will need to use the notify all synchronization feature in the next installment.
Opinions expressed by DZone contributors are their own.