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">
# Generator Based Coroutines
<div class="ans">

Some of the readers might want to skip this lesson and head straight to native coroutines section but following through the discussion on legacy generator based coroutines can be useful when working with older code-bases.

Coroutines formally became part of Python in version 2.4 when generators were enhanced via <a href="https://www.python.org/dev/peps/pep-0342/" target="_blank">PEP-342</a>. And in Python 3.4, asyncio framework introduced an event loop which enabled asynchronous programs in Python. Note that with PEP-342, all generators received the new methods. So all generators fit the textbook definition of a coroutine. In fact, a post PEP-342 Python generator is functionally equivalent of what the world outside Python would call a coroutine. However, Python created a distinction between Python generators and generators that were meant to be used as coroutines. These coroutines are called generator based coroutines and require the decorator <code class="anno">@asynio.coroutine</code> to be added to the function definition though this isn't strictly enforced. The decorator enables compatibility with <code class="clazz">async def</code> coroutines, and also serves as documentation.

Generator based coroutines use <code class="clazz">yield from</code> syntax instead of <code class="clazz">yield</code>. A coroutine can:

<ul>
<li>yield from another coroutine</li>
<li>yield from a future</li>
<li>return an expression</li>
<li>raise exception</li>
</ul> 


To sum up, a function that uses <code class="clazz">yield from</code> becomes a coroutine and requires the <code class="anno">@asyncio.coroutine</code> decorator. If a function doesn't use <code class="clazz">yield from</code> adding the decorator will make it a coroutine. Consider the following method


```python
@asyncio.coroutine
def hello_world():
 print("hello world")
```


The above method becomes a coroutine with the addition of the decorator and can be run using the event loop as follows:


```python
coro_obj = hello_world()
asyncio.get_event_loop().run_until_complete(coro_obj)
```


In the runnable script below remove the decorator and observe the event loop throw an exception.

</div>
</div>

<div>
# Generator Based Coroutines
<div>

Some of the readers might want to skip this lesson and head straight to native coroutines section but following through the discussion on legacy generator based coroutines can be useful when working with older code-bases.

Coroutines formally became part of Python in version 2.4 when generators were enhanced via <a href="https://www.python.org/dev/peps/pep-0342/" target="_blank">PEP-342</a>. And in Python 3.4, asyncio framework introduced an event loop which enabled asynchronous programs in Python. Note that with PEP-342, all generators received the new methods. So all generators fit the textbook definition of a coroutine. In fact, a post PEP-342 Python generator is functionally equivalent of what the world outside Python would call a coroutine. However, Python created a distinction between Python generators and generators that were meant to be used as coroutines. These coroutines are called generator based coroutines and require the decorator <code>@asynio.coroutine</code> to be added to the function definition though this isn't strictly enforced. The decorator enables compatibility with <code>async def</code> coroutines, and also serves as documentation.

Generator based coroutines use <code>yield from</code> syntax instead of <code>yield</code>. A coroutine can:

<ul>
<li>yield from another coroutine</li>
<li>yield from a future</li>
<li>return an expression</li>
<li>raise exception</li>
</ul> 


To sum up, a function that uses <code>yield from</code> becomes a coroutine and requires the <code>@asyncio.coroutine</code> decorator. If a function doesn't use <code>yield from</code> adding the decorator will make it a coroutine. Consider the following method


```python
@asyncio.coroutine
def hello_world():
 print("hello world")
```


The above method becomes a coroutine with the addition of the decorator and can be run using the event loop as follows:


```python
coro_obj = hello_world()
asyncio.get_event_loop().run_until_complete(coro_obj)
```


In the runnable script below remove the decorator and observe the event loop throw an exception.

</div>
</div>

This lesson goes into the details of generator-based coroutines in Python.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Generator Based Coroutines

Generator Based Coroutines