The only guide you’ll need on concurrency & multithreading for senior engineers. Pressure test your skills with real-world practice problems from top companies.

Concurrency in Java is one of the most complex and advanced topics brought up during senior engineering interviews. Knowledge of concurrency and multithreading can put interviewees at a considerable advantage. This course lays the foundations of advanced concurrency and multithreading and explains concepts such as Monitors and Deferred Callbacks in depth. It also builds simple and complete solutions to popular concurrency problems that can be asked about in interviews like the Reader-Writer Problem and the Dining Philosopher Problem. While prior knowledge of concurrency is not required to follow through with this course, familiarity with the very basics of concurrency would be helpful.

Java Multithreading for Senior Engineering Interviews

Continuing our discussion from the previous section on locking and signaling mechanisms, we'll now pore over an advanced concept the **monitor**. It is exposed as a concurrency construct by some programming language frameworks including Java.

# When Mutual Exclusion isn't Enough
Concisely, a monitor is a mutex and then some. Monitors are generally language level constructs whereas mutex and semaphore are lower-level or OS provided constructs.

To understand monitors, let's first see the problem they solve. Usually, in multi-threaded applications, a thread needs to wait for some program predicate to be true before it can proceed forward. Think about a producer/consumer application. If the producer hasn't produced anything the consumer can't consume anything, so the consumer must **_wait on_** a predicate that lets the consumer know that something has indeed been produced. What could be a crude way of accomplishing this? The consumer could repeatedly check in a loop for the predicate to be set to true. The pattern would resemble the pseudocode below:

```
void busyWaitFunction() {
  // acquire mutex
  while (predicate is false){
    // release mutex
   // acquire mutex
}
  // do something useful
 // release mutex
}
```

Within the while loop we'll first release the mutex giving other threads a chance to acquire it and set the loop predicate to true. And before we check the loop predicate again, we make sure we have acquired the mutex again. This works but is an example of **_"spin waiting"_** which wastes a lot of CPU cycles. Next, let's see how condition variables solve the spin-waiting issue.



# Condition Variables
Mutex provides mutual exclusion, however, at times mutual exclusion is not enough. We want to test for a predicate with a mutually exclusive lock so that no other thread can change the predicate when we test for it but if we find the predicate to be false, we'd want to wait on a condition variable till the predicate's value is changed. This thus is the solution to spin waiting.

Conceptually, each condition variable exposes two methods `wait()` and `signal()`.
The `wait()` method when called on the condition variable will cause the associated mutex to be atomically released, and the calling thread would be placed in a **wait queue**. There could already be other threads in the **wait queue** that previously invoked `wait()` on the condition variable. Since the mutex is now released, it gives other threads a chance to change the predicate that will eventually let the thread that was just placed in the wait queue to make progress. As an example, say we have a consumer thread that checks for the size of the buffer, finds it empty and invokes `wait()` on a condition variable. The predicate in this example would be **_the size of the buffer_**.

Now imagine a producer places an item in the buffer. The predicate, the size of the buffer, just changed and the producer wants to let the consumer threads know that there is an item to be consumed. This producer thread would then invoke `signal()` on the condition variable. The `signal()` method when called on a condition variable causes one of the threads that has been placed in the **wait queue** to get ready for execution. Note we didn't say the woken up thread starts executing, it just gets ready - and that could mean being placed in the ready queue. It is only after the producer thread which calls the `signal()` method has released the associated mutex that the thread in the ready queue starts executing. The thread in the ready queue must wait to acquire the mutex associated with the condition variable before it can start executing.

Lets see how this all translates into code.

```
  voidefficientWaitingFunction() 
{
  mutex.acquire() 
  while (predicate == false) {
    condVar.wait()
  }
 // Do something useful
  mutex.release()
}

void changePredicate(){
  mutex.acquire()
  set predicate = true
  condVar.signal()
  mutex.release()
}
```


Let's dry run the above code. Say **thread A** executes `efficientWaitingFunction()`first and finds the loop predicate is false and enters the loop. Next **thread A** executes the statement `condVar.wait()` and is be placed in a wait queue. At the same time **thread A** gives up the mutex. Now **thread B** comes along and executes `changePredicate()` method. Since the mutex was given up by **thread A**, **thread B** is be able to acquire it and set the predicate to true. Next it signals the condition variable `condVar.signal()`. This step places **thread A** into the ready queue but **thread A** doesn't start executing until **thread B** has released the mutex.
Note that the order of signaling the condition variable and releasing the mutex can be interchanged, but generally, the preference is to signal first and then release the mutex. However, the ordering might have ramifications on thread scheduling depending on the threading implementation.






Learn what a monitor is and how it is different than a mutex. Monitors are advanced concurrency constructs and specific to languages frameworks.

The Basics

Multithreading in Java

Java's Memory Model

Interview Practice Problems

Bonus Questions

Beyond the Interview

Java Concurrency Reference

Revision & Quizzes

Mutex vs Monitor

When Mutual Exclusion isn’t Enough