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="ans">
We create a condition variable as follows:
# Creating a condition variable

```python
cond_var = Condition()
```

The two important methods of a condition variable are:

<ul>
<li><code class="mthd">wait()</code> - invoked to make a thread sleep and give up resources</li>
<li><code class="mthd">notify()</code> - invoked by a thread when a condition becomes true and the invoking threads want to inform the waiting thread or threads to proceed</li>
</ul>

A condition variable is always associated with a lock. The lock can be either reentrant or a plain vanilla lock. The associated lock must be acquired before a thread can invoke <code class="mthd">wait()</code>or <code class="mthd">notify()</code> on the condition variable. 
# Incorrect way of using condition variables


```python
cond_var = Condition()
cond_var.wait() # throws an error
```



</div>

from threading import Condition

cond_var = Condition()
cond_var.wait()  # throws an error

<div class="ans">
We can create a lock ourselves and pass it to the condition variable's constructor. If no lock object is passed then a lock is created underneath the hood by the condition variable. In the examples below we demonstrate all the different ways of invoking condition variables.

We can create the condition variable as follows:
# Creating a condition variable by passing 
a custom lock


```python
lock = Lock()
cond_var = Condition(lock) # pass custom lock to condition variable
cond_var.acquire()
cond_var.wait()
```

We can also create a condition variable without passing in a custom lock.
# Creating a condition variable without passing a lock


```python
cond_var = Condition()
cond_var.acquire()
cond_var.wait()
```


Given what we know so far about condition variables, let's try to rewrite the printer thread code from the previous section. Note, that we are checking for the boolean variables in an <code class="clazz">if</code> statement.
# Printer thread refactored code


```python
cond_var = Condition()
found_prime = False
prime_holder = None
exit_prog = False

def printer_thread_func():
 global prime_holder
 global found_prime

 while not exit_prog:

 # check for predicate
 cond_var.acquire()
 if not found_prime and not exit_prog:
 cond_var.wait()
 cond_var.release()
 

 if not exit_prog:
 print(prime_holder)
 prime_holder = None
 
 # acquire lock before modifying shared variable
 cond_var.acquire()
 found_prime = False
 # remember to wake up the other thread
 cond_var.notify()
 cond_var.release()

```

 
Note that we have rid ourselves of the busy wait loop. Now we check if the <code class="mthd">found_prime</code> is false and if so we first acquire the lock on the condition variable and then invoke the <code class="mthd">wait()</code> method on it. When the finder thread invokes <code class="mthd">notify()</code> on the variable <code class="mthd">cond_var</code>, that is the moment when the printer thread will wake up from its slumber and continue.

There are however two questions we need to answer:

<ul>
<li>If the printer thread acquires the lock on the condition variable <code class="mthd">cond_var</code> then how can the finder thread <code class="mthd">acquire()</code> the lock when it needs to invoke the <code class="mthd">notify()</code> method?</li>

<li>Can the condition, which is the variable <code class="mthd">found_prime</code>, change once the printer thread is woken up?</li>
</ul>
 
The answer to the first question is that when a thread invokes <code class="mthd">wait()</code> it simultaneously gives up the lock associated with the condition variable. Only when the sleeping thread wakes up again on a <code class="mthd">nofity()</code>, will it reacquire the lock.

The second question is very important and leads us to the correct idiomatic usage of the condition variable. The way we have nested the acquire and wait call under an if statement is incorrect. The reason is that if a thread invokes <code class="mthd">notifyAll()</code> on a condition variable, then all the threads waiting on the condition variable will be woken up but only one thread will be allowed to make progress. Once the first thread exits the critical section and releases the lock associated with the condition variable, another thread, from the set of threads that were waiting when the original <code class="mthd">notifyAll()</code> call was made, is allowed to make progress. This may not be appropriate for every use case and certainly not for ours if we had multiple printer threads.
We would want a printer thread to make progress only when the condition <code class="mthd">found_prime</code> is set to true. 
This can only be possible with a while loop where we check if the condition <code class="mthd">found_prime</code> is true before allowing a printer thread to move ahead. The change will look as follows:


```python
 cond_var.acquire()
 while not found_prime and not exit_prog:
 cond_var.wait()
 cond_var.release()
```



On a side note, remember that a woken up thread reacquires the lock associated with the condition variable the thread was waiting on and doesn't give up the lock until it releases the condition variable. Hence, any statements executed between the <code class="mthd">wait()</code> and the <code class="mthd">release()</code> call would happen while the thread holds the lock assuring mutual exclusion within that block of code. Consider the below pseudocode:

```python
0. cond_var.acquire()
1. while predicate is not True:
2. cond_var.wait()
3. 
4. # code statement 1
5. # code statement 2
6. # code statement 3
7. 
8. cond_var.release()
``` 

In the hypothetical snippet above, the lines 2 to 8 would be executed by a woken up thread while holding the lock associated with the condition variable.


# Spurious Wakeups

We may convince ourselves to not use a while loop if we only have a single printer thread in our program. However, a thread can be woken up even if there has been no notification!

A peculiarity of condition variables is the possibility of spurious wakeups. It means that a thread might wakeup as if it has been signaled even though nobody called <code class="mthd">notify()</code> on the condition variable in question. This is specifically allowed by the POSIX standard because it allows more efficient implementations of condition variables under some circumstances. Such wakeups are called spurious wakeups.

A thread that has been woken up does not imply that the conditions for it to move forward hold. The thread must test the conditions again for validity before moving forward. In conclusion, we must always check for conditions in a loop and <code class="mthd">wait()</code> inside it. The correct idiomatic usage of a condition variable appears below:
## Idiomatic use of wait()


```python
acquire lock
while(condition_to_test is not satisfied):
 wait

# condition is now true, perform necessary tasks

release lock
```


The idiomatic usage to notify() is as follows:
## Idiomatic use of notify


```python
acquire lock
set condition_to_test to true/satisfied
notify
release lock
```


In the next section, we'll rewrite our printer and finder threads using condition variables.

</div>

<div>
We create a condition variable as follows:
# Creating a condition variable

```python
cond_var = Condition()
```

The two important methods of a condition variable are:

<ul>
<li><code>wait()</code> - invoked to make a thread sleep and give up resources</li>
<li><code>notify()</code> - invoked by a thread when a condition becomes true and the invoking threads want to inform the waiting thread or threads to proceed</li>
</ul>

A condition variable is always associated with a lock. The lock can be either reentrant or a plain vanilla lock. The associated lock must be acquired before a thread can invoke <code>wait()</code>or <code>notify()</code> on the condition variable. 
# Incorrect way of using condition variables


```python
cond_var = Condition()
cond_var.wait() # throws an error
```



</div>

<div>
We can create a lock ourselves and pass it to the condition variable's constructor. If no lock object is passed then a lock is created underneath the hood by the condition variable. In the examples below we demonstrate all the different ways of invoking condition variables.

We can create the condition variable as follows:
# Creating a condition variable by passing 
a custom lock


```python
lock = Lock()
cond_var = Condition(lock) # pass custom lock to condition variable
cond_var.acquire()
cond_var.wait()
```

We can also create a condition variable without passing in a custom lock.
# Creating a condition variable without passing a lock


```python
cond_var = Condition()
cond_var.acquire()
cond_var.wait()
```


Given what we know so far about condition variables, let's try to rewrite the printer thread code from the previous section. Note, that we are checking for the boolean variables in an <code>if</code> statement.
# Printer thread refactored code


```python
cond_var = Condition()
found_prime = False
prime_holder = None
exit_prog = False

def printer_thread_func():
 global prime_holder
 global found_prime

 while not exit_prog:

 # check for predicate
 cond_var.acquire()
 if not found_prime and not exit_prog:
 cond_var.wait()
 cond_var.release()
 

 if not exit_prog:
 print(prime_holder)
 prime_holder = None
 
 # acquire lock before modifying shared variable
 cond_var.acquire()
 found_prime = False
 # remember to wake up the other thread
 cond_var.notify()
 cond_var.release()

```

 
Note that we have rid ourselves of the busy wait loop. Now we check if the <code>found_prime</code> is false and if so we first acquire the lock on the condition variable and then invoke the <code>wait()</code> method on it. When the finder thread invokes <code>notify()</code> on the variable <code>cond_var</code>, that is the moment when the printer thread will wake up from its slumber and continue.

There are however two questions we need to answer:

<ul>
<li>If the printer thread acquires the lock on the condition variable <code>cond_var</code> then how can the finder thread <code>acquire()</code> the lock when it needs to invoke the <code>notify()</code> method?</li>

<li>Can the condition, which is the variable <code>found_prime</code>, change once the printer thread is woken up?</li>
</ul>
 
The answer to the first question is that when a thread invokes <code>wait()</code> it simultaneously gives up the lock associated with the condition variable. Only when the sleeping thread wakes up again on a <code>nofity()</code>, will it reacquire the lock.

The second question is very important and leads us to the correct idiomatic usage of the condition variable. The way we have nested the acquire and wait call under an if statement is incorrect. The reason is that if a thread invokes <code>notifyAll()</code> on a condition variable, then all the threads waiting on the condition variable will be woken up but only one thread will be allowed to make progress. Once the first thread exits the critical section and releases the lock associated with the condition variable, another thread, from the set of threads that were waiting when the original <code>notifyAll()</code> call was made, is allowed to make progress. This may not be appropriate for every use case and certainly not for ours if we had multiple printer threads.
We would want a printer thread to make progress only when the condition <code>found_prime</code> is set to true. 
This can only be possible with a while loop where we check if the condition <code>found_prime</code> is true before allowing a printer thread to move ahead. The change will look as follows:


```python
 cond_var.acquire()
 while not found_prime and not exit_prog:
 cond_var.wait()
 cond_var.release()
```



On a side note, remember that a woken up thread reacquires the lock associated with the condition variable the thread was waiting on and doesn't give up the lock until it releases the condition variable. Hence, any statements executed between the <code>wait()</code> and the <code>release()</code> call would happen while the thread holds the lock assuring mutual exclusion within that block of code. Consider the below pseudocode:

```python
0. cond_var.acquire()
1. while predicate is not True:
2. cond_var.wait()
3. 
4. # code statement 1
5. # code statement 2
6. # code statement 3
7. 
8. cond_var.release()
``` 

In the hypothetical snippet above, the lines 2 to 8 would be executed by a woken up thread while holding the lock associated with the condition variable.


# Spurious Wakeups

We may convince ourselves to not use a while loop if we only have a single printer thread in our program. However, a thread can be woken up even if there has been no notification!

A peculiarity of condition variables is the possibility of spurious wakeups. It means that a thread might wakeup as if it has been signaled even though nobody called <code>notify()</code> on the condition variable in question. This is specifically allowed by the POSIX standard because it allows more efficient implementations of condition variables under some circumstances. Such wakeups are called spurious wakeups.

A thread that has been woken up does not imply that the conditions for it to move forward hold. The thread must test the conditions again for validity before moving forward. In conclusion, we must always check for conditions in a loop and <code>wait()</code> inside it. The correct idiomatic usage of a condition variable appears below:
## Idiomatic use of wait()


```python
acquire lock
while(condition_to_test is not satisfied):
 wait

# condition is now true, perform necessary tasks

release lock
```


The idiomatic usage to notify() is as follows:
## Idiomatic use of notify


```python
acquire lock
set condition_to_test to true/satisfied
notify
release lock
```


In the next section, we'll rewrite our printer and finder threads using condition variables.

</div>

Continuation of discussion on condition variables.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

... continued

Creating a condition variable