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

## Busy wait solution using `Lock` 
In the previous lesson, we solved the consumer producer problem using the <code class="clazz">synchronized</code> keyword, which is equivalent of a monitor in Java. Let's see how the implementation would look like, if we were restricted to using a mutex. There's no direct equivalent of a theoretical mutex in Java as each object has an implicit monitor associated with it. For this question, we'll use an object of the <code class="clazz">Lock</code> class and pretend it doesn't expose the <code class="mthd">wait()</code> and <code class="mthd">notify()</code> methods and only provides mutual exclusion similar to a theoretical mutex. Without the ability to wait or signal the implication is, a blocked thread will constantly poll in a loop for a predicate/condition to become true before making progress. This is an example of a busy-wait solution.

Let's start with the <code class="mthd">enqueue()</code> method. If the current <code class="mthd">size of the queue == capacity</code> then we know we need to block the caller of the method until the queue has space for a new item. Since a mutex only allows locking, we give up the mutex at this point. The logic is shown below.

```java
 lock.lock();
 while (size == capacity) {
 // Release the mutex to give other threads
 lock.unlock();
 // Reacquire the mutex before checking the
 // condition
 lock.lock();
 }

 if (tail == capacity) {
 tail = 0;
 }

 array[tail] = item;
 size++;
 tail++;
 lock.unlock();
```


The most important point to realize in the above code is the weird-looking while loop construct, where we release the lock and then immediately attempt to reacquire it. Convince yourself that whenever we test the while loop condition <code class="mthd">size == capacity</code>, we do so while holding the mutex! Also, it may not be immediately obvious but a different thread can acquire the mutex just when a thread releases the mutex and attempts to reacquire it within the while loop. Lastly, we modify the <code class="mthd">array</code> variable only when holding the mutex.

We also need to manage the <code class="mthd">tail</code> as the queue grows. Once it reaches the end of our backing array, we reset it to zero. Realize that since we only proceed to add an item when <code class="mthd">size of queue &lt; maxSize </code> we are guaranteed that <code class="mthd">tail</code> will never overwrite an existing item.

Now let us see the code for the <code class="mthd">dequeue()</code> method which is analogous to the <code class="mthd">enqueue()</code> one.

```java
 T item = null;

 lock.lock();
 while (size == 0) {
 lock.unlock();
 lock.lock();
 }

 if (head == capacity) {
 head = 0;
 }

 item = array[head];
 array[head] = null;
 head++;
 size--;

 lock.unlock();
 return item;
```

Again note that we always test for the condition <code class="mthd">size == 0</code> when holding the lock. Additionally, all shared state is manipulated in mutual exclusion. Additionally, we reset <code class="mthd">head</code> of the queue back to zero in case it's pointing past the end of the array. We need to decrement the <code class="mthd">size</code> variable too since the queue will now have one less item. The complete code appears in the widget below. It also runs a simulation of several producers and consumers that constantly write and retrieve from an instance of the blocking queue, for one second.

# Busy wait solution using `Lock` 
In the previous lesson, we solved the consumer producer problem using the <code class="clazz">synchronized</code> keyword, which is equivalent of a monitor in Java. Let's see how the implementation would look like, if we were restricted to using a mutex. There's no direct equivalent of a theoretical mutex in Java as each object has an implicit monitor associated with it. For this question, we'll use an object of the <code class="clazz">Lock</code> class and pretend it doesn't expose the <code class="mthd">wait()</code> and <code class="mthd">notify()</code> methods and only provides mutual exclusion similar to a theoretical mutex. Without the ability to wait or signal the implication is, a blocked thread will constantly poll in a loop for a predicate/condition to become true before making progress. This is an example of a busy-wait solution.

Let's start with the <code class="mthd">enqueue()</code> method. If the current <code class="mthd">size of the queue == capacity</code> then we know we need to block the caller of the method until the queue has space for a new item. Since a mutex only allows locking, we give up the mutex at this point. The logic is shown below.

```java
 lock.lock();
 while (size == capacity) {
 // Release the mutex to give other threads
 lock.unlock();
 // Reacquire the mutex before checking the
 // condition
 lock.lock();
 }

 if (tail == capacity) {
 tail = 0;
 }

 array[tail] = item;
 size++;
 tail++;
 lock.unlock();
```


The most important point to realize in the above code is the weird-looking while loop construct, where we release the lock and then immediately attempt to reacquire it. Convince yourself that whenever we test the while loop condition <code class="mthd">size == capacity</code>, we do so while holding the mutex! Also, it may not be immediately obvious but a different thread can acquire the mutex just when a thread releases the mutex and attempts to reacquire it within the while loop. Lastly, we modify the <code class="mthd">array</code> variable only when holding the mutex.

We also need to manage the <code class="mthd">tail</code> as the queue grows. Once it reaches the end of our backing array, we reset it to zero. Realize that since we only proceed to add an item when <code class="mthd">size of queue &lt; maxSize </code> we are guaranteed that <code class="mthd">tail</code> will never overwrite an existing item.

Now let us see the code for the <code class="mthd">dequeue()</code> method which is analogous to the <code class="mthd">enqueue()</code> one.

```java
 T item = null;

 lock.lock();
 while (size == 0) {
 lock.unlock();
 lock.lock();
 }

 if (head == capacity) {
 head = 0;
 }

 item = array[head];
 array[head] = null;
 head++;
 size--;

 lock.unlock();
 return item;
```

Again note that we always test for the condition <code class="mthd">size == 0</code> when holding the lock. Additionally, all shared state is manipulated in mutual exclusion. Additionally, we reset <code class="mthd">head</code> of the queue back to zero in case it's pointing past the end of the array. We need to decrement the <code class="mthd">size</code> variable too since the queue will now have one less item. The complete code appears in the widget below. It also runs a simulation of several producers and consumers that constantly write and retrieve from an instance of the blocking queue, for one second.

# Busy wait solution using `Lock` 
In the previous lesson, we solved the consumer producer problem using the <code>synchronized</code> keyword, which is equivalent of a monitor in Java. Let's see how the implementation would look like, if we were restricted to using a mutex. There's no direct equivalent of a theoretical mutex in Java as each object has an implicit monitor associated with it. For this question, we'll use an object of the <code>Lock</code> class and pretend it doesn't expose the <code>wait()</code> and <code>notify()</code> methods and only provides mutual exclusion similar to a theoretical mutex. Without the ability to wait or signal the implication is, a blocked thread will constantly poll in a loop for a predicate/condition to become true before making progress. This is an example of a busy-wait solution.

Let's start with the <code>enqueue()</code> method. If the current <code>size of the queue == capacity</code> then we know we need to block the caller of the method until the queue has space for a new item. Since a mutex only allows locking, we give up the mutex at this point. The logic is shown below.

```java
 lock.lock();
 while (size == capacity) {
 // Release the mutex to give other threads
 lock.unlock();
 // Reacquire the mutex before checking the
 // condition
 lock.lock();
 }

 if (tail == capacity) {
 tail = 0;
 }

 array[tail] = item;
 size++;
 tail++;
 lock.unlock();
```


The most important point to realize in the above code is the weird-looking while loop construct, where we release the lock and then immediately attempt to reacquire it. Convince yourself that whenever we test the while loop condition <code>size == capacity</code>, we do so while holding the mutex! Also, it may not be immediately obvious but a different thread can acquire the mutex just when a thread releases the mutex and attempts to reacquire it within the while loop. Lastly, we modify the <code>array</code> variable only when holding the mutex.

We also need to manage the <code>tail</code> as the queue grows. Once it reaches the end of our backing array, we reset it to zero. Realize that since we only proceed to add an item when <code>size of queue &lt; maxSize </code> we are guaranteed that <code>tail</code> will never overwrite an existing item.

Now let us see the code for the <code>dequeue()</code> method which is analogous to the <code>enqueue()</code> one.

```java
 T item = null;

 lock.lock();
 while (size == 0) {
 lock.unlock();
 lock.lock();
 }

 if (head == capacity) {
 head = 0;
 }

 item = array[head];
 array[head] = null;
 head++;
 size--;

 lock.unlock();
 return item;
```

Again note that we always test for the condition <code>size == 0</code> when holding the lock. Additionally, all shared state is manipulated in mutual exclusion. Additionally, we reset <code>head</code> of the queue back to zero in case it's pointing past the end of the array. We need to decrement the <code>size</code> variable too since the queue will now have one less item. The complete code appears in the widget below. It also runs a simulation of several producers and consumers that constantly write and retrieve from an instance of the blocking queue, for one second.

This lesson explains how to solve the producer-consumer problem using a mutex.

The Basics

Multithreading in Java

Java's Memory Model

Interview Practice Problems

Bonus Questions

Beyond the Interview

Java Concurrency Reference

Revision & Quizzes

... continued

Busy wait solution using `Lock`

... continued

Busy wait solution using Lock

Busy wait solution using `Lock`