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">

# Locks & Reentrant Lock

   <div class="ans">
<p>Similar to the <code class="abtc">threading</code> module, synchronization primitives exist for the <code class="abtc">multiprocessing</code> module to coordinate among multiple processes. The primitives between the two modules have a lot of commonalities.</p>

<p>Because of the similarities, we just reproduce the examples from the threading section using the primitives from the multiprocessing module.</p> 

## Lock   
<p>Lock is a non-recursive object and shares the same DNA as the <code class="abtc">threading.Lock</code> class. In the section on using Queues and Pipes we introduced a snippet with a bug, that could potentially hang depending on the order in which the two processes consumed objects placed on the queue. We can change that example snippet to be process-safe. First let's see the faulty code:</p>
### Faulty queue sharing code
<b>

```python
def child_process(q):
    count = 0
    while not q.empty():
        print(q.get())
        count += 1

    print("child process {0} processed {1} items from the queue".format(current_process().name, count), flush=True)

if __name__ == '__main__':
    multiprocessing.set_start_method("forkserver")
    q = Queue()

    random.seed()
    for _ in range(100):
        q.put(random.randrange(10))

    p1 = Process(target=child_process, args=(q,))
    p2 = Process(target=child_process, args=(q,))

    p1.start()
    p2.start()

    p1.join()
    p2.join()

```
</b>

<p>The problem with the above snippet is that a process can find the <code class="mthd">q.empty()</code> to be false but before it gets a chance to take the last item off the queue, another process may have already removed it. Thus, our process ends up getting blocked on the get call because the queue is empty.</p>

<p>Using locks can we avoid the described situation? The key is to make the emptiness check and the get call atomic, i.e. when a process executes the two calls, no other process should be able to make the same calls. The fix is shown below:</p>
### Fixed Code
<b>

```python
def child_process(q, lock):
    count = 0
    keep_going = True

    while keep_going:
        lock.acquire()
        if not q.empty():
            print(q.get())
            count += 1
        else:
            keep_going = False
        lock.release()

    print("child process {0} processed {1} items from the queue".format(current_process().name, count), flush=True)


if __name__ == '__main__':

    multiprocessing.set_start_method("forkserver")
    lock = Lock()
    q = Queue()

    random.seed()
    for _ in range(100):
        q.put(random.randrange(10))

    p1 = Process(target=child_process, args=(q, lock))
    p2 = Process(target=child_process, args=(q, lock))

    p1.start()
    p2.start()

    p1.join()
    p2.join()
```
</b>

<p>Note, we had to change the code slightly to make the two calls atomic but the overall intent of the code is unchanged.</p>
</div>
</div>


<div>

# Locks & Reentrant Lock

   <div>
<p>Similar to the <code>threading</code> module, synchronization primitives exist for the <code>multiprocessing</code> module to coordinate among multiple processes. The primitives between the two modules have a lot of commonalities.</p>

<p>Because of the similarities, we just reproduce the examples from the threading section using the primitives from the multiprocessing module.</p> 

## Lock   
<p>Lock is a non-recursive object and shares the same DNA as the <code>threading.Lock</code> class. In the section on using Queues and Pipes we introduced a snippet with a bug, that could potentially hang depending on the order in which the two processes consumed objects placed on the queue. We can change that example snippet to be process-safe. First let's see the faulty code:</p>
### Faulty queue sharing code
<b>

```python
def child_process(q):
    count = 0
    while not q.empty():
        print(q.get())
        count += 1

    print("child process {0} processed {1} items from the queue".format(current_process().name, count), flush=True)

if __name__ == '__main__':
    multiprocessing.set_start_method("forkserver")
    q = Queue()

    random.seed()
    for _ in range(100):
        q.put(random.randrange(10))

    p1 = Process(target=child_process, args=(q,))
    p2 = Process(target=child_process, args=(q,))

    p1.start()
    p2.start()

    p1.join()
    p2.join()

```
</b>

<p>The problem with the above snippet is that a process can find the <code>q.empty()</code> to be false but before it gets a chance to take the last item off the queue, another process may have already removed it. Thus, our process ends up getting blocked on the get call because the queue is empty.</p>

<p>Using locks can we avoid the described situation? The key is to make the emptiness check and the get call atomic, i.e. when a process executes the two calls, no other process should be able to make the same calls. The fix is shown below:</p>
### Fixed Code
<b>

```python
def child_process(q, lock):
    count = 0
    keep_going = True

    while keep_going:
        lock.acquire()
        if not q.empty():
            print(q.get())
            count += 1
        else:
            keep_going = False
        lock.release()

    print("child process {0} processed {1} items from the queue".format(current_process().name, count), flush=True)


if __name__ == '__main__':

    multiprocessing.set_start_method("forkserver")
    lock = Lock()
    q = Queue()

    random.seed()
    for _ in range(100):
        q.put(random.randrange(10))

    p1 = Process(target=child_process, args=(q, lock))
    p2 = Process(target=child_process, args=(q, lock))

    p1.start()
    p2.start()

    p1.join()
    p2.join()
```
</b>

<p>Note, we had to change the code slightly to make the two calls atomic but the overall intent of the code is unchanged.</p>
</div>
</div>


This lesson discusses the Lock and Reentrant Lock versions of the multiprocessing module.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Locks & Reentrant Lock

Locks & Reentrant Lock