Multithreading Java and Interviews Part 2: Mutex, the Java Monitor Model

In the previous chapter, we learned about the following:

Also 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 noticed that each object in Java has the methods "wait" or "notify". Those keywords are used for synchronization. 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.  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. 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 threads 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. 

10 Acts

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.