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">
# Mesa vs Hoare Monitors

<div class="ans">
We discussed the abstract concept of a monitor in the previous section. Now let's discuss the various designs for monitors.

## Mesa Monitors

So far we have determined that the idiomatic usage of a monitor requires using a while loop as follows. Let's see how the design of monitors affects this recommendation.

 
<code class="code-snipt">
 while( condition == false )&nbsp;{ 
 &nbsp;&nbsp;&nbsp;&nbsp;condVar.wait(); 
 }
 </code>
 
Once the asleep thread is signaled and woken up, you may ask why does it needs to check for the condition being false again if the signaling thread must have just set the condition to true?

In Mesa monitors - Mesa being a language developed by Xerox researchers in the 1970s - it is possible that in the time gap between when thread B calls <code class="mthd">notify()</code> and releases its mutex and the instant at which the asleep thread A wakes up and reacquires the mutex, the predicate is changed back to false by another thread different than the signaler and the awoken threads! The woken up thread competes with other threads to acquire the mutex once the signaling thread B empties the monitor. On signaling, thread B doesn't give up the monitor just yet; rather it continues to own the monitor until it exits the monitor section.

## Hoare Monitors
In contrast in Hoare monitors - Hoare being one of the original inventor of monitors - the signaling thread B yields the monitor to the woken up thread A and thread A enters the monitor while thread B sits out. This guarantees that the predicate will not have changed and instead of checking for the predicate in a while loop, an if-clause would suffice. The woken-up/released thread A immediately starts execution when the signaling thread B signals that the predicate has changed. No other thread gets a chance to change the predicate since no other thread gets to enter the monitor.

Mesa monitors are more efficient than Hoare monitors.

Java, in particular, subscribes to Mesa monitor semantics and since Python's <code class="abtc">threading</code> module is based on Java's threading model, therefore it too in turn utilizes the Mesa semantics for monitors. Thus the developer is always expected to check for condition/predicate in a while loop. 
</div>
</div>

<div>
# Mesa vs Hoare Monitors

<div>
We discussed the abstract concept of a monitor in the previous section. Now let's discuss the various designs for monitors.

## Mesa Monitors

So far we have determined that the idiomatic usage of a monitor requires using a while loop as follows. Let's see how the design of monitors affects this recommendation.

 
<code>
 while( condition == false )&nbsp;{ 
 &nbsp;&nbsp;&nbsp;&nbsp;condVar.wait(); 
 }
 </code>
 
Once the asleep thread is signaled and woken up, you may ask why does it needs to check for the condition being false again if the signaling thread must have just set the condition to true?

In Mesa monitors - Mesa being a language developed by Xerox researchers in the 1970s - it is possible that in the time gap between when thread B calls <code>notify()</code> and releases its mutex and the instant at which the asleep thread A wakes up and reacquires the mutex, the predicate is changed back to false by another thread different than the signaler and the awoken threads! The woken up thread competes with other threads to acquire the mutex once the signaling thread B empties the monitor. On signaling, thread B doesn't give up the monitor just yet; rather it continues to own the monitor until it exits the monitor section.

## Hoare Monitors
In contrast in Hoare monitors - Hoare being one of the original inventor of monitors - the signaling thread B yields the monitor to the woken up thread A and thread A enters the monitor while thread B sits out. This guarantees that the predicate will not have changed and instead of checking for the predicate in a while loop, an if-clause would suffice. The woken-up/released thread A immediately starts execution when the signaling thread B signals that the predicate has changed. No other thread gets a chance to change the predicate since no other thread gets to enter the monitor.

Mesa monitors are more efficient than Hoare monitors.

Java, in particular, subscribes to Mesa monitor semantics and since Python's <code>threading</code> module is based on Java's threading model, therefore it too in turn utilizes the Mesa semantics for monitors. Thus the developer is always expected to check for condition/predicate in a while loop. 
</div>
</div>

This lesson looks at the different designs for implementing monitors.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Mesa vs Hoare Monitors

Mesa vs