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">
   # Implementing Semaphore
    <div class="ans">
    <p>Python does provide its own implementation of <code class="clazz">Semaphore</code> and <code class="clazz">BoundedSemaphore</code>, however, we want to implement a semaphore with a slight twist.</p>

<p> Briefly, a semaphore is a construct that allows some threads to access a fixed set of resources in parallel. Always think of a semaphore as having a fixed number of permits to give out. Once all the permits are given out, requesting threads, need to wait for a permit to be returned before proceeding forward.</p>

<p>Your task is to implement a semaphore which takes in its constructor the maximum number of permits allowed and is also initialized with the same number of permits. Additionally, if all the permits have been given out, the semaphore blocks threads attempting to acquire it.</p>
</div>
</div>

  <div class="card">
   # Solution
  <div class="ans">
<p>Given the above definition we can now start to think of what functions our Semaphore class will need to expose. We need a function to "gain the permit" and a function to "return the permit".</p>

<ol>
  <li><code class="mthd">acquire()</code> function to simulate gaining a permit</li>
  <li><code class="mthd">release()</code> function to simulate releasing a permit</li>
  </ol>

<p>The constructor accepts an integer parameter defining the number of permits available with the semaphore. Internally we need to store a count which keeps track of the permits given out so far.

The skeleton for our Semaphore class looks something like this so far.</p>
<b>

```python
class CountSemaphore():

    def __init__(self, permits):
        self.max_permits = permits
        self.given_out = 0

    def acquire(self):
        pass

    def release(self):
        pass

```
</b>

<p>Realize that the two methods <code class="mthd">acquire()</code> and <code class="mthd">release()</code> can be invoked at the same time by different threads and therefore we need to guard the logic inside of them by some kind of lock. We can use a simple <code class="clazz">Lock</code> object for this purpose. Hold on to that thought as we'll shortly see that we'd need something more than just a lock.</p>

<p>Now let us fill in the implementation for our <code class="mthd">acquire()</code> method. When can a thread not be allowed to acquire a semaphore? When all the permits are out! This implies we'll need to wait for a permit to become available when <code class="mthd"> given_out == max_permits</code>. If this condition isn't true we simply increment <code class="mthd">given_out</code> to simulate giving out a permit. The fact that we need to <i>wait</i> for a permit if none is available should ring a bell. What synchronization primitive allows us to wait on a condition? A <code class="clazz">Condition</code> object! The condition object also comes with an implicit or explicitly passed-in lock that can be used to guard the critical section of the two methods.</p>

</p>The implementation of the <code class="mthd">acquire()</code> method appears below. Note that we are also <code class="mthd">notifyAll()-ing</code> at the end of the method. We'll talk shortly, about why we need it.</p>


```python
    def acquire(self):
        self.cond_var.acquire()
        while self.given_out == self.max_permits:
            self.cond_var.wait()

        self.given_out += 1
        self.cond_var.notifyAll()
        self.cond_var.release()
```

<p>Implementing the <code class="mthd">release()</code> method should require a simple decrement of the <code class="mthd">given_out</code> variable. However, when should we block a thread from proceeding forward like we did in <code class="mthd">acquire()</code> method? If <code class="mthd">given_out == 0</code> then it won't make sense to decrement <code class="mthd">given_out</code> and we should block at this condition.</p> 

<p>This might seem counter-intuitive, you might ask why would someone call <code class="mthd">release()</code> before calling <code class="mthd">acquire()</code> - This is entirely possible since semaphore can also be used for signaling between threads. A thread can call <code class="mthd">release()</code> on a semaphore object before another thread calls <code class="mthd">acquire()</code> on the same semaphore object. There is no concept of ownership for a semaphore! Hence different threads can call acquire or release methods as they deem fit.</p>

<p>This also means that whenever we decrement or increment the <code class="mthd">given_out</code> variable we need to call <code class="mthd">notifyAll()</code> so that any waiting thread in the other method is able to move forward. The full implementation appears below:</p>
<b>

```python
class CountSemaphore():

    def __init__(self, permits):
        self.max_permits = permits
        self.given_out = 0
        self.cond_var = Condition()

    def acquire(self):
        self.cond_var.acquire()
        while self.given_out == self.max_permits:
            self.cond_var.wait()

        self.given_out += 1
        self.cond_var.notifyAll()
        self.cond_var.release()

    def release(self):

        self.cond_var.acquire()

        while self.given_out == 0:
            self.cond_var.wait()

        self.given_out -= 1
        self.cond_var.notifyAll()
        self.cond_var.release()
```
</b>

## Follow up
<p>Note that in both the methods, we increment or decrement the variable <code class="mthd">given_out</code> before invoking <code class="mthd">notifyAll()</code> on the condition variable. Does it matter if we switch the order of the two statements in the two methods? The answer is no. A thread inside either of the methods holds the lock associated with the condition variable until the point the thread invokes <code class="mthd">release()</code> on the condition variable, which is the last statement in both the methods. A waiting thread once notified must acquire the lock associated with the condition variable before resuming execution, therefore, the order of the two statements doesn't matter.</p>

## Test Case
<p>In the example below, we have two threads, one always acquires the semaphore while the other always releases it. The execution of the two threads is staggered. We are using the semaphore as a signaling mechanism between the two threads.</p>

</div>
</div>

<div>
   # Implementing Semaphore
    <div>
    <p>Python does provide its own implementation of <code>Semaphore</code> and <code>BoundedSemaphore</code>, however, we want to implement a semaphore with a slight twist.</p>

<p> Briefly, a semaphore is a construct that allows some threads to access a fixed set of resources in parallel. Always think of a semaphore as having a fixed number of permits to give out. Once all the permits are given out, requesting threads, need to wait for a permit to be returned before proceeding forward.</p>

<p>Your task is to implement a semaphore which takes in its constructor the maximum number of permits allowed and is also initialized with the same number of permits. Additionally, if all the permits have been given out, the semaphore blocks threads attempting to acquire it.</p>
</div>
</div>

  <div>
   # Solution
  <div>
<p>Given the above definition we can now start to think of what functions our Semaphore class will need to expose. We need a function to "gain the permit" and a function to "return the permit".</p>

<ol>
  <li><code>acquire()</code> function to simulate gaining a permit</li>
  <li><code>release()</code> function to simulate releasing a permit</li>
  </ol>

<p>The constructor accepts an integer parameter defining the number of permits available with the semaphore. Internally we need to store a count which keeps track of the permits given out so far.

The skeleton for our Semaphore class looks something like this so far.</p>
<b>

```python
class CountSemaphore():

    def __init__(self, permits):
        self.max_permits = permits
        self.given_out = 0

    def acquire(self):
        pass

    def release(self):
        pass

```
</b>

<p>Realize that the two methods <code>acquire()</code> and <code>release()</code> can be invoked at the same time by different threads and therefore we need to guard the logic inside of them by some kind of lock. We can use a simple <code>Lock</code> object for this purpose. Hold on to that thought as we'll shortly see that we'd need something more than just a lock.</p>

<p>Now let us fill in the implementation for our <code>acquire()</code> method. When can a thread not be allowed to acquire a semaphore? When all the permits are out! This implies we'll need to wait for a permit to become available when <code> given_out == max_permits</code>. If this condition isn't true we simply increment <code>given_out</code> to simulate giving out a permit. The fact that we need to <i>wait</i> for a permit if none is available should ring a bell. What synchronization primitive allows us to wait on a condition? A <code>Condition</code> object! The condition object also comes with an implicit or explicitly passed-in lock that can be used to guard the critical section of the two methods.</p>

</p>The implementation of the <code>acquire()</code> method appears below. Note that we are also <code>notifyAll()-ing</code> at the end of the method. We'll talk shortly, about why we need it.</p>


```python
    def acquire(self):
        self.cond_var.acquire()
        while self.given_out == self.max_permits:
            self.cond_var.wait()

        self.given_out += 1
        self.cond_var.notifyAll()
        self.cond_var.release()
```

<p>Implementing the <code>release()</code> method should require a simple decrement of the <code>given_out</code> variable. However, when should we block a thread from proceeding forward like we did in <code>acquire()</code> method? If <code>given_out == 0</code> then it won't make sense to decrement <code>given_out</code> and we should block at this condition.</p> 

<p>This might seem counter-intuitive, you might ask why would someone call <code>release()</code> before calling <code>acquire()</code> - This is entirely possible since semaphore can also be used for signaling between threads. A thread can call <code>release()</code> on a semaphore object before another thread calls <code>acquire()</code> on the same semaphore object. There is no concept of ownership for a semaphore! Hence different threads can call acquire or release methods as they deem fit.</p>

<p>This also means that whenever we decrement or increment the <code>given_out</code> variable we need to call <code>notifyAll()</code> so that any waiting thread in the other method is able to move forward. The full implementation appears below:</p>
<b>

```python
class CountSemaphore():

    def __init__(self, permits):
        self.max_permits = permits
        self.given_out = 0
        self.cond_var = Condition()

    def acquire(self):
        self.cond_var.acquire()
        while self.given_out == self.max_permits:
            self.cond_var.wait()

        self.given_out += 1
        self.cond_var.notifyAll()
        self.cond_var.release()

    def release(self):

        self.cond_var.acquire()

        while self.given_out == 0:
            self.cond_var.wait()

        self.given_out -= 1
        self.cond_var.notifyAll()
        self.cond_var.release()
```
</b>

## Follow up
<p>Note that in both the methods, we increment or decrement the variable <code>given_out</code> before invoking <code>notifyAll()</code> on the condition variable. Does it matter if we switch the order of the two statements in the two methods? The answer is no. A thread inside either of the methods holds the lock associated with the condition variable until the point the thread invokes <code>release()</code> on the condition variable, which is the last statement in both the methods. A waiting thread once notified must acquire the lock associated with the condition variable before resuming execution, therefore, the order of the two statements doesn't matter.</p>

## Test Case
<p>In the example below, we have two threads, one always acquires the semaphore while the other always releases it. The execution of the two threads is staggered. We are using the semaphore as a signaling mechanism between the two threads.</p>

</div>
</div>

Learn how to design and implement a simple semaphore class in Python.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Implementing Semaphore

Implementing Semaphore