The ultimate guide to senior engineering interviews. Strategies developed by FAANG engineers on Python concurrency, multithreading, monitors, and event loops. Prep faster for top company questions.

Concurrency in Python 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, Event Loops 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 basic Python would be helpful.

Python 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
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:

```python
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:

```java
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.

You can come back to the examples presented below as they require an understanding of the <code class="clazz">Lock</code> and <code class="clazz">RLock</code> classes. Or you can just run the examples and observe the output for now to get a high-level overview of the concepts we discussed in this lesson.

If you run the code snippet below, you'll see that the statements for acquiring locks: lock1 and lock2 print out but there's no progress after that and the execution times out. In this scenario, the deadlock occurs because the locks 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
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:

```python
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:

```java
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.

You can come back to the examples presented below as they require an understanding of the <code>Lock</code> and <code>RLock</code> classes. Or you can just run the examples and observe the output for now to get a high-level overview of the concepts we discussed in this lesson.

If you run the code snippet below, you'll see that the statements for acquiring locks: lock1 and lock2 print out but there's no progress after that and the execution times out. In this scenario, the deadlock occurs because the locks 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

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Deadlock, Liveness & Reentrant Locks

Deadlock and Liveness