The ultimate guide to Ruby concurrency interviews. Developed by FAANG engineers, this course covers Monitors, Deferred Callbacks and problem-solving strategies for Reader-Writer and Dining Philosopher Problems.

Concurrency in Ruby 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 basics of Ruby would be helpful.

Ruby Concurrency for Senior Engineering Interviews

<div class="card">
# Deadlock and Liveness

<div class="ans">
Logical follies committed in multithreaded code, while trying to avoid race conditions and guarding critical sections, can lead to a host of subtle and hard to find bugs and side-effects. Some of these incorrect usage patterns have their specific names and are discussed below.

## Deadlock
Deadlocks occur when two or more threads aren't able to make any progress because the resource required by the first thread is held by the second and the resource required by the second thread is held by the first.

## Liveness
The ability of a program or an application to execute in a timely manner
is called liveness. If a program experiences a deadlock, then it's not
exhibiting liveness.

## Live-Lock
A live-lock occurs when two threads continuously react in response to the actions by the other thread without making any real progress. The best analogy is to think of two persons trying to cross each other in a hallway. John moves to the left to let Arun pass, and Arun moves to his right to let John pass. Both block each other now. John sees he's blocking Arun again and moves to his right, and Arun moves to his left, seeing he's blocking John. They never cross each other and keep blocking each other. This scenario is an example of a live-lock. A process seems to be running and not deadlocked but in reality, isn't making any progress.

## Starvation
Other than a deadlock, an application thread can also experience starvation when it never gets CPU time or access to shared resources. Other greedy threads continuously hog shared system resources, not letting the starving thread make any progress.

## Deadlock Example

Consider the pseudocode below:

```ruby
void increment() {
 
 acquire MUTEX_A
 acquire MUTEX_B
 // do work here
 release MUTEX_B
 release MUTEX_A
 
}


void decrement() {
 
 acquire MUTEX_B
 acquire MUTEX_A
 // do work here
 release MUTEX_A
 release MUTEX_B
 
}
```

The above code can potentially result in a deadlock. Note that deadlock may not always happen, but for certain execution sequences, deadlock can occur. Consider the execution sequence below that ends up in a deadlock:

```ruby
T1 enters function increment

T1 acquires MUTEX_A

T1 gets context switched by the operating system

T2 enters function decrement

T2 acquires MUTEX_B

both threads are blocked now
```

Thread T2 can't make progress as it requires MUTEX_A which is being held by T1. Now when T1 wakes up, it can't make progress as it requires MUTEX_B and that is being held up by T2. This is a classic text-book example of a deadlock.

If you run the code snippet below, you'll see that the statements for acquiring mutexes: lockA and lockB print out but there's no progress after that and the Ruby interpreter barfs about the program entering into a deadlock. In this scenario, the deadlock occurs because the mutexes are being acquired in a nested fashion.


</div>
</div>

<div>
# Deadlock and Liveness

<div>
Logical follies committed in multithreaded code, while trying to avoid race conditions and guarding critical sections, can lead to a host of subtle and hard to find bugs and side-effects. Some of these incorrect usage patterns have their specific names and are discussed below.

## Deadlock
Deadlocks occur when two or more threads aren't able to make any progress because the resource required by the first thread is held by the second and the resource required by the second thread is held by the first.

## Liveness
The ability of a program or an application to execute in a timely manner
is called liveness. If a program experiences a deadlock, then it's not
exhibiting liveness.

## Live-Lock
A live-lock occurs when two threads continuously react in response to the actions by the other thread without making any real progress. The best analogy is to think of two persons trying to cross each other in a hallway. John moves to the left to let Arun pass, and Arun moves to his right to let John pass. Both block each other now. John sees he's blocking Arun again and moves to his right, and Arun moves to his left, seeing he's blocking John. They never cross each other and keep blocking each other. This scenario is an example of a live-lock. A process seems to be running and not deadlocked but in reality, isn't making any progress.

## Starvation
Other than a deadlock, an application thread can also experience starvation when it never gets CPU time or access to shared resources. Other greedy threads continuously hog shared system resources, not letting the starving thread make any progress.

## Deadlock Example

Consider the pseudocode below:

```ruby
void increment() {
 
 acquire MUTEX_A
 acquire MUTEX_B
 // do work here
 release MUTEX_B
 release MUTEX_A
 
}


void decrement() {
 
 acquire MUTEX_B
 acquire MUTEX_A
 // do work here
 release MUTEX_A
 release MUTEX_B
 
}
```

The above code can potentially result in a deadlock. Note that deadlock may not always happen, but for certain execution sequences, deadlock can occur. Consider the execution sequence below that ends up in a deadlock:

```ruby
T1 enters function increment

T1 acquires MUTEX_A

T1 gets context switched by the operating system

T2 enters function decrement

T2 acquires MUTEX_B

both threads are blocked now
```

Thread T2 can't make progress as it requires MUTEX_A which is being held by T1. Now when T1 wakes up, it can't make progress as it requires MUTEX_B and that is being held up by T2. This is a classic text-book example of a deadlock.

If you run the code snippet below, you'll see that the statements for acquiring mutexes: lockA and lockB print out but there's no progress after that and the Ruby interpreter barfs about the program entering into a deadlock. In this scenario, the deadlock occurs because the mutexes are being acquired in a nested fashion.


</div>
</div>

We discuss important concurrency concepts such as deadlock, liveness, live-lock, starvation, and reentrant locks in depth. Also included are executable code examples for illustrating these concepts.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

Deadlocks, Liveness & Reentrant Locks

Deadlock and Liveness