How to choose the right concurrency model<\/h4>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AhwsMbtR0kWWcej8AYWOwYA.jpeg?ssl=1\")
Image by Paul Esch-Laurent<\/a> from\u00a0Unsplash<\/a><\/figcaption><\/figure>\nPython provides three main approaches to handle multiple tasks simultaneously: multithreading, multiprocessing, and\u00a0asyncio.<\/p>\n
Choosing the right model is crucial for maximising your program\u2019s performance and efficiently using system resources. (P.S. It is also a common interview question!)<\/p>\n
Without concurrency, a program processes only one task at a time. During operations like file loading, network requests, or user input, it stays idle, wasting valuable CPU cycles. Concurrency solves this by enabling multiple tasks to run efficiently.<\/p>\n
But which model should you use? Let\u2019s dive\u00a0in!<\/p>\n
Contents<\/h3>\n\n- Fundamentals of concurrency
– Concurrency vs parallelism
– Programs
– Processes
– Threads
– How does the OS manage threads and processes?<\/li>\n - Python\u2019s concurrency models
– Multithreading
– Python\u2019s Global Interpreter Lock (GIL)
– Multiprocessing
–\u00a0Asyncio<\/li>\n - When should I use which concurrency model?<\/li>\n<\/ol>\n
Fundamentals of concurrency<\/h3>\n
Before jumping into Python\u2019s concurrency models, let\u2019s recap some foundational concepts.<\/p>\n
1. Concurrency vs Parallelism<\/h4>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A5zUHBzNkzOZYPu1uvuLcSQ.png?ssl=1\")
Visual representation of concurrency vs parallelism (drawn by\u00a0me)<\/figcaption><\/figure>\nConcurrency is all about managing multiple tasks at the same time, not necessarily simultaneously. Tasks may take turns, creating the illusion of multitasking.<\/p>\n
Parallelism is about running multiple tasks simultaneously, typically by leveraging multiple CPU\u00a0cores.<\/p>\n
2. Programs<\/h4>\n
Now let\u2019s move on to some fundamental OS concepts\u200a\u2014\u200aprograms, processes and\u00a0threads.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A7oO4wA3pvsqXgx6Gwc7twg.png?ssl=1\")
Multiple threads can exist simultaneously within the a single process\u200a\u2014\u200aknown as multithreading (drawn by\u00a0me)<\/figcaption><\/figure>\nA program is simply a static file, like a Python script or an executable.<\/p><\/blockquote>\n
A program sits on disk, and is passive until the operating system (OS) loads it into memory to run. Once this happens, the program becomes a\u00a0process<\/strong>.<\/p>\n3. Processes<\/h4>\nA process is an independent instance of a running\u00a0program.<\/p><\/blockquote>\n
A process has its own memory space, resources, and execution state. Processes are isolated from each other, meaning one process cannot interfere with another unless explicitly designed to do so via mechanisms like inter-process communication (IPC)<\/em><\/strong>.<\/p>\nProcesses can generally be categorised into two\u00a0types:<\/p>\n
\n- \nI\/O-bound processes:<\/strong>
Spend most of it\u2019s time waiting<\/em><\/strong> for input\/output operations to complete, such as file access, network communication, or user input. While waiting, the CPU sits\u00a0idle.<\/li>\n- \nCPU-bound processes:<\/strong>
Spend most of their time doing computations<\/em><\/strong> (e.g video encoding, numerical analysis). These tasks require a lot of CPU\u00a0time.<\/li>\n<\/ol>\nLifecycle of a\u00a0process:<\/strong><\/p>\n\n- A process starts in a new<\/em> state when\u00a0created.<\/li>\n
- It moves to the ready<\/em> state, waiting for CPU\u00a0time.<\/li>\n
- If the process waits for an event like I\/O, it enters the waiting<\/em>\u00a0state.<\/li>\n
- Finally, it terminates<\/em> after completing its\u00a0task.<\/li>\n<\/ul>\n
4. Threads<\/h4>\nA thread is the smallest unit of execution within a process.
A process acts as a \u201ccontainer\u201d for threads, and multiple threads can be created and destroyed over the process\u2019s lifetime.<\/p><\/blockquote>\n
Every process has at least one thread\u200a\u2014\u200athe main thread<\/em><\/strong>\u200a<\/em>\u2014\u200abut it can also create additional threads.<\/p>\nThreads share memory and resources within the same process, enabling efficient communication. However, this sharing can lead to synchronisation issues like race conditions or deadlocks if not managed carefully. Unlike processes, multiple threads in a single process are not isolated\u200a\u2014\u200aone misbehaving thread can crash the entire\u00a0process.<\/p>\n
5. How does the OS manage threads and processes?<\/h4>\n
The CPU can execute only one task per core at a time<\/em><\/strong>. To handle multiple tasks, the operating system uses preemptive context switching<\/em><\/strong>.<\/p>\nDuring a context switch, the OS pauses the current task, saves its state and loads the state of the next task to be executed.<\/p>\n
This rapid switching creates the illusion of simultaneous execution on a single CPU\u00a0core.<\/p>\n
For processes, context switching is more resource-intensive because the OS must save and load separate memory spaces. For threads, switching is faster because threads share the same memory within a process. However, frequent switching introduces overhead, which can slow down performance.<\/p>\n
True parallel execution of processes can only occur if there are multiple CPU cores available. Each core handles a separate process simultaneously.<\/p>\n
Python\u2019s concurrency models<\/h3>\n
Let\u2019s now explore Python\u2019s specific concurrency models.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AYrsrPOh5y4EL_7UOFJ08yg.png?ssl=1\")
Summary of the different concurrency models (drawn by\u00a0me)<\/figcaption><\/figure>\n1. Multithreading<\/h3>\n
Multithreading allows a process to execute multiple threads concurrently, with threads sharing the same memory and resources (see diagrams 2 and\u00a04).<\/p>\n
However, Python\u2019s Global Interpreter Lock (GIL) limits multithreading\u2019s effectiveness for CPU-bound tasks.<\/p>\n
Python\u2019s Global Interpreter Lock\u00a0(GIL)<\/h4>\nThe GIL is a lock that allows only one thread to hold control of the Python interpreter at any time, meaning only one thread can execute Python bytecode at\u00a0once.<\/p><\/blockquote>\n
The GIL was introduced to simplify memory management in Python as many internal operations, such as object creation, are not thread safe by default. Without a GIL, multiple threads trying to access the shared resources will require complex locks or synchronisation mechanisms to prevent race conditions and data corruption.<\/p>\n
When is GIL a bottleneck?<\/em><\/strong><\/p>\n\n- For single threaded programs, the GIL is irrelevant as the thread has exclusive access to the Python interpreter.<\/li>\n
- For multithreaded I\/O-bound programs, the GIL is less problematic as threads release the GIL when waiting for I\/O operations.<\/li>\n
- For multithreaded CPU-bound operations, the GIL becomes a significant bottleneck. Multiple threads competing for the GIL must take turns executing Python bytecode.<\/li>\n<\/ul>\n
An interesting case worth noting is the use of time.sleep, which Python effectively treats as an I\/O operation. The time.sleep function is not CPU-bound because it does not involve active computation or the execution of Python bytecode during the sleep period. Instead, the responsibility of tracking the elapsed time is delegated to the OS. During this time, the thread releases the GIL, allowing other threads to run and utilise the interpreter.<\/p>\n
2. Multiprocessing<\/h3>\n
Multiprocessing enables a system to run multiple processes in parallel, each with its own memory, GIL and resources. Within each process, there may be one or more threads (see diagrams 3 and\u00a04).<\/p>\n
Multiprocessing bypasses the limitations of the GIL. This makes it suitable for CPU bound tasks that require heavy computation.<\/p>\n
However, multiprocessing is more resource intensive due to separate memory and process overheads.<\/p>\n
3. Asyncio<\/h3>\nUnlike threads or processes, asyncio uses a single thread to handle multiple\u00a0tasks.<\/p><\/blockquote>\n
When writing asynchronous code with the asyncio library, you’ll use the async\/await keywords to manage\u00a0tasks.<\/p>\n
Key concepts<\/em><\/strong><\/h4>\n\n- \nCoroutines:<\/strong> These are functions defined with async def\u00a0. They are the core of asyncio and represent tasks that can be paused and resumed\u00a0later.<\/li>\n
- \nEvent loop:<\/strong> It manages the execution of\u00a0tasks.<\/li>\n
- \nTasks:<\/strong> Wrappers around coroutines. When you want a coroutine to actually start running, you turn it into a task\u200a\u2014\u200aeg. using asyncio.create_task()<\/li>\n
- \nawait<\/strong>\u00a0: Pauses execution of a coroutine, giving control back to the event\u00a0loop.<\/li>\n<\/ol>\n
How it\u00a0works<\/em><\/strong><\/h4>\nAsyncio runs an event loop that schedules tasks. Tasks voluntarily \u201cpause\u201d themselves when waiting for something, like a network response or a file read. While the task is paused, the event loop switches to another task, ensuring no time is wasted\u00a0waiting.<\/p>\n
This makes asyncio ideal for scenarios involving many small tasks that spend a lot of time waiting<\/strong>, such as handling thousands of web requests or managing database queries. Since everything runs on a single thread, asyncio avoids the overhead and complexity of thread switching.<\/p>\nThe key difference between asyncio and multithreading lies in how they handle waiting\u00a0tasks.<\/strong><\/p><\/blockquote>\n\n- Multithreading relies on the OS to switch between threads when one thread is waiting (preemptive context switching<\/em><\/strong>).
When a thread is waiting, the OS switches to another thread automatically.<\/li>\n- Asyncio uses a single thread and depends on tasks to \u201ccooperate\u201d by pausing when they need to wait (cooperative multitasking<\/em><\/strong>).<\/li>\n<\/ul>\n
2 ways to write async\u00a0code:<\/h4>\n
method 1: await coroutine<\/strong><\/p>\nWhen you directly await a coroutine, the execution of the current coroutine pauses<\/em><\/strong> at the await statement until the awaited coroutine finishes. Tasks are executed sequentially <\/em><\/strong>within the current coroutine.<\/em><\/strong><\/p>\nUse this approach when you need the result of the coroutine <\/em>immediately<\/em><\/strong> to proceed with the next\u00a0steps.<\/p>\nAlthough this might sound like synchronous code, it\u2019s not. In synchronous code, the entire program would block during a\u00a0pause.<\/p>\n
With asyncio, only the current coroutine pauses, while the rest of the program can continue running. This makes asyncio non-blocking at the program\u00a0level.<\/p><\/blockquote>\n
Example:<\/strong><\/p>\nThe event loop pauses the current coroutine until fetch_data is complete.<\/p>\n
async def fetch_data():
print(\"Fetching data...\")
await asyncio.sleep(1) # Simulate a network call
print(\"Data fetched\")
return \"data\"
async def main():
result = await fetch_data() # Current coroutine pauses here
print(f\"Result: {result}\")
asyncio.run(main())<\/pre>\nmethod 2: asyncio.create_task(coroutine)<\/strong><\/p>\nThe coroutine is scheduled to run concurrently in the background<\/em><\/strong>. Unlike await, the current coroutine continues executing immediately without waiting for the scheduled task to\u00a0finish.<\/p>\nThe scheduled coroutine starts running as soon as the event loop finds an opportunity<\/em><\/strong>, without needing to wait for an explicit\u00a0await.<\/p>\nNo new threads are created; instead, the coroutine runs within the same thread as the event loop, which manages when each task gets execution time.<\/p><\/blockquote>\n
This approach enables concurrency within the program, allowing multiple tasks to overlap their execution efficiently. You will later need to await the task to get it\u2019s result and ensure it\u2019s\u00a0done.<\/p>\n
Use this approach when you want to run tasks concurrently and don\u2019t need the results immediately.<\/p>\n
Example:<\/strong><\/p>\nWhen the line asyncio.create_task() is reached, the coroutine fetch_data() is scheduled to start running immediately when the event loop is available<\/em><\/strong>. This can happen even before<\/em><\/strong> you explicitly await the task. In contrast, in the first await method, the coroutine only starts executing when the await statement is\u00a0reached.<\/p>\nOverall, this makes the program more efficient by overlapping the execution of multiple\u00a0tasks.<\/p>\n
async def fetch_data():
# Simulate a network call
await asyncio.sleep(1)
return \"data\"
async def main():
# Schedule fetch_data
task = asyncio.create_task(fetch_data())
# Simulate doing other work
await asyncio.sleep(5)
# Now, await task to get the result
result = await task
print(result)
asyncio.run(main())<\/pre>\nOther important points<\/h4>\n\n- \nYou can mix synchronous and asynchronous code. <\/strong>
Since synchronous code is blocking, it can be offloaded to a separate thread using asyncio.to_thread(). This makes your program effectively multithreaded.
In the example below, the asyncio event loop runs on the main thread, while a separate background thread is used to execute the sync_task.<\/li>\n<\/ul>\nimport asyncio
import time
def sync_task():
time.sleep(2)
return \"Completed\"
async def main():
result = await asyncio.to_thread(sync_task)
print(result)
asyncio.run(main())<\/pre>\n
\n- You should offload CPU-bound tasks which are computationally intensive to a separate\u00a0process.<\/li>\n<\/ul>\n
When should I use which concurrency model?<\/h3>\n
This flow is a good way to decide when to use\u00a0what.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A7Das-hY02tbJbHPxCmMvXA.png?ssl=1\")
Flowchart (drawn by me), referencing this stackoverflow<\/a> discussion<\/figcaption><\/figure>\n\n- \nMultiprocessing<\/strong>
– Best for CPU-bound tasks which are computationally intensive.
– When you need to bypass the GIL\u200a\u2014\u200aEach process has it\u2019s own Python interpreter, allowing for true parallelism.<\/li>\n- \nMultithreading<\/strong>
– Best for fast I\/O-bound tasks as the frequency of context switching is reduced and the Python interpreter sticks to a single thread for longer
– Not ideal for CPU-bound tasks due to\u00a0GIL.<\/li>\n- \nAsyncio<\/strong>
– Ideal for slow I\/O-bound tasks such as long network requests or database queries because it efficiently handles waiting, making it scalable.
– Not suitable for CPU-bound tasks without offloading work to other processes.<\/li>\n<\/ol>\nWrapping up<\/h3>\n
That\u2019s it folks. There\u2019s a lot more that this topic has to cover but I hope I\u2019ve introduced to you the various concepts, and when to use each\u00a0method.<\/p>\n
Thanks for reading! I write regularly on Python, software development and the projects I build, so give me a follow to not miss out. See you in the next article\u00a0\ud83d\ude42<\/p>\n
![\"\"](\"https:\/\/medium.com\/_\/stat?event=post.clientViewed&referrerSource=full_rss&postId=94fdbe0c91f0\")
<\/p>\n
\nDeep Dive into Multithreading, Multiprocessing, and Asyncio<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\n
Python provides three main approaches to handle multiple tasks simultaneously: multithreading, multiprocessing, and\u00a0asyncio.<\/p>\n
Choosing the right model is crucial for maximising your program\u2019s performance and efficiently using system resources. (P.S. It is also a common interview question!)<\/p>\n
Without concurrency, a program processes only one task at a time. During operations like file loading, network requests, or user input, it stays idle, wasting valuable CPU cycles. Concurrency solves this by enabling multiple tasks to run efficiently.<\/p>\n
But which model should you use? Let\u2019s dive\u00a0in!<\/p>\n
Contents<\/h3>\n\n- Fundamentals of concurrency
– Concurrency vs parallelism
– Programs
– Processes
– Threads
– How does the OS manage threads and processes?<\/li>\n - Python\u2019s concurrency models
– Multithreading
– Python\u2019s Global Interpreter Lock (GIL)
– Multiprocessing
–\u00a0Asyncio<\/li>\n - When should I use which concurrency model?<\/li>\n<\/ol>\n
Fundamentals of concurrency<\/h3>\n
Before jumping into Python\u2019s concurrency models, let\u2019s recap some foundational concepts.<\/p>\n
1. Concurrency vs Parallelism<\/h4>\nVisual representation of concurrency vs parallelism (drawn by\u00a0me)<\/figcaption><\/figure>\nConcurrency is all about managing multiple tasks at the same time, not necessarily simultaneously. Tasks may take turns, creating the illusion of multitasking.<\/p>\n
Parallelism is about running multiple tasks simultaneously, typically by leveraging multiple CPU\u00a0cores.<\/p>\n
2. Programs<\/h4>\n
Now let\u2019s move on to some fundamental OS concepts\u200a\u2014\u200aprograms, processes and\u00a0threads.<\/p>\nMultiple threads can exist simultaneously within the a single process\u200a\u2014\u200aknown as multithreading (drawn by\u00a0me)<\/figcaption><\/figure>\nA program is simply a static file, like a Python script or an executable.<\/p><\/blockquote>\n
A program sits on disk, and is passive until the operating system (OS) loads it into memory to run. Once this happens, the program becomes a\u00a0process<\/strong>.<\/p>\n3. Processes<\/h4>\nA process is an independent instance of a running\u00a0program.<\/p><\/blockquote>\n
A process has its own memory space, resources, and execution state. Processes are isolated from each other, meaning one process cannot interfere with another unless explicitly designed to do so via mechanisms like inter-process communication (IPC)<\/em><\/strong>.<\/p>\nProcesses can generally be categorised into two\u00a0types:<\/p>\n
\n- \nI\/O-bound processes:<\/strong>
Spend most of it\u2019s time waiting<\/em><\/strong> for input\/output operations to complete, such as file access, network communication, or user input. While waiting, the CPU sits\u00a0idle.<\/li>\n- \nCPU-bound processes:<\/strong>
Spend most of their time doing computations<\/em><\/strong> (e.g video encoding, numerical analysis). These tasks require a lot of CPU\u00a0time.<\/li>\n<\/ol>\nLifecycle of a\u00a0process:<\/strong><\/p>\n\n- A process starts in a new<\/em> state when\u00a0created.<\/li>\n
- It moves to the ready<\/em> state, waiting for CPU\u00a0time.<\/li>\n
- If the process waits for an event like I\/O, it enters the waiting<\/em>\u00a0state.<\/li>\n
- Finally, it terminates<\/em> after completing its\u00a0task.<\/li>\n<\/ul>\n
4. Threads<\/h4>\nA thread is the smallest unit of execution within a process.
A process acts as a \u201ccontainer\u201d for threads, and multiple threads can be created and destroyed over the process\u2019s lifetime.<\/p><\/blockquote>\n
Every process has at least one thread\u200a\u2014\u200athe main thread<\/em><\/strong>\u200a<\/em>\u2014\u200abut it can also create additional threads.<\/p>\nThreads share memory and resources within the same process, enabling efficient communication. However, this sharing can lead to synchronisation issues like race conditions or deadlocks if not managed carefully. Unlike processes, multiple threads in a single process are not isolated\u200a\u2014\u200aone misbehaving thread can crash the entire\u00a0process.<\/p>\n
5. How does the OS manage threads and processes?<\/h4>\n
The CPU can execute only one task per core at a time<\/em><\/strong>. To handle multiple tasks, the operating system uses preemptive context switching<\/em><\/strong>.<\/p>\nDuring a context switch, the OS pauses the current task, saves its state and loads the state of the next task to be executed.<\/p>\n
This rapid switching creates the illusion of simultaneous execution on a single CPU\u00a0core.<\/p>\n
For processes, context switching is more resource-intensive because the OS must save and load separate memory spaces. For threads, switching is faster because threads share the same memory within a process. However, frequent switching introduces overhead, which can slow down performance.<\/p>\n
True parallel execution of processes can only occur if there are multiple CPU cores available. Each core handles a separate process simultaneously.<\/p>\n
Python\u2019s concurrency models<\/h3>\n
Let\u2019s now explore Python\u2019s specific concurrency models.<\/p>\nSummary of the different concurrency models (drawn by\u00a0me)<\/figcaption><\/figure>\n1. Multithreading<\/h3>\n
Multithreading allows a process to execute multiple threads concurrently, with threads sharing the same memory and resources (see diagrams 2 and\u00a04).<\/p>\n
However, Python\u2019s Global Interpreter Lock (GIL) limits multithreading\u2019s effectiveness for CPU-bound tasks.<\/p>\n
Python\u2019s Global Interpreter Lock\u00a0(GIL)<\/h4>\nThe GIL is a lock that allows only one thread to hold control of the Python interpreter at any time, meaning only one thread can execute Python bytecode at\u00a0once.<\/p><\/blockquote>\n
The GIL was introduced to simplify memory management in Python as many internal operations, such as object creation, are not thread safe by default. Without a GIL, multiple threads trying to access the shared resources will require complex locks or synchronisation mechanisms to prevent race conditions and data corruption.<\/p>\n
When is GIL a bottleneck?<\/em><\/strong><\/p>\n\n- For single threaded programs, the GIL is irrelevant as the thread has exclusive access to the Python interpreter.<\/li>\n
- For multithreaded I\/O-bound programs, the GIL is less problematic as threads release the GIL when waiting for I\/O operations.<\/li>\n
- For multithreaded CPU-bound operations, the GIL becomes a significant bottleneck. Multiple threads competing for the GIL must take turns executing Python bytecode.<\/li>\n<\/ul>\n
An interesting case worth noting is the use of time.sleep, which Python effectively treats as an I\/O operation. The time.sleep function is not CPU-bound because it does not involve active computation or the execution of Python bytecode during the sleep period. Instead, the responsibility of tracking the elapsed time is delegated to the OS. During this time, the thread releases the GIL, allowing other threads to run and utilise the interpreter.<\/p>\n
2. Multiprocessing<\/h3>\n
Multiprocessing enables a system to run multiple processes in parallel, each with its own memory, GIL and resources. Within each process, there may be one or more threads (see diagrams 3 and\u00a04).<\/p>\n
Multiprocessing bypasses the limitations of the GIL. This makes it suitable for CPU bound tasks that require heavy computation.<\/p>\n
However, multiprocessing is more resource intensive due to separate memory and process overheads.<\/p>\n
3. Asyncio<\/h3>\nUnlike threads or processes, asyncio uses a single thread to handle multiple\u00a0tasks.<\/p><\/blockquote>\n
When writing asynchronous code with the asyncio library, you’ll use the async\/await keywords to manage\u00a0tasks.<\/p>\n
Key concepts<\/em><\/strong><\/h4>\n\n- \nCoroutines:<\/strong> These are functions defined with async def\u00a0. They are the core of asyncio and represent tasks that can be paused and resumed\u00a0later.<\/li>\n
- \nEvent loop:<\/strong> It manages the execution of\u00a0tasks.<\/li>\n
- \nTasks:<\/strong> Wrappers around coroutines. When you want a coroutine to actually start running, you turn it into a task\u200a\u2014\u200aeg. using asyncio.create_task()<\/li>\n
- \nawait<\/strong>\u00a0: Pauses execution of a coroutine, giving control back to the event\u00a0loop.<\/li>\n<\/ol>\n
How it\u00a0works<\/em><\/strong><\/h4>\nAsyncio runs an event loop that schedules tasks. Tasks voluntarily \u201cpause\u201d themselves when waiting for something, like a network response or a file read. While the task is paused, the event loop switches to another task, ensuring no time is wasted\u00a0waiting.<\/p>\n
This makes asyncio ideal for scenarios involving many small tasks that spend a lot of time waiting<\/strong>, such as handling thousands of web requests or managing database queries. Since everything runs on a single thread, asyncio avoids the overhead and complexity of thread switching.<\/p>\nThe key difference between asyncio and multithreading lies in how they handle waiting\u00a0tasks.<\/strong><\/p><\/blockquote>\n\n- Multithreading relies on the OS to switch between threads when one thread is waiting (preemptive context switching<\/em><\/strong>).
When a thread is waiting, the OS switches to another thread automatically.<\/li>\n- Asyncio uses a single thread and depends on tasks to \u201ccooperate\u201d by pausing when they need to wait (cooperative multitasking<\/em><\/strong>).<\/li>\n<\/ul>\n
2 ways to write async\u00a0code:<\/h4>\n
method 1: await coroutine<\/strong><\/p>\nWhen you directly await a coroutine, the execution of the current coroutine pauses<\/em><\/strong> at the await statement until the awaited coroutine finishes. Tasks are executed sequentially <\/em><\/strong>within the current coroutine.<\/em><\/strong><\/p>\nUse this approach when you need the result of the coroutine <\/em>immediately<\/em><\/strong> to proceed with the next\u00a0steps.<\/p>\nAlthough this might sound like synchronous code, it\u2019s not. In synchronous code, the entire program would block during a\u00a0pause.<\/p>\n
With asyncio, only the current coroutine pauses, while the rest of the program can continue running. This makes asyncio non-blocking at the program\u00a0level.<\/p><\/blockquote>\n
Example:<\/strong><\/p>\nThe event loop pauses the current coroutine until fetch_data is complete.<\/p>\n
async def fetch_data():
print(\"Fetching data...\")
await asyncio.sleep(1) # Simulate a network call
print(\"Data fetched\")
return \"data\"
async def main():
result = await fetch_data() # Current coroutine pauses here
print(f\"Result: {result}\")
asyncio.run(main())<\/pre>\nmethod 2: asyncio.create_task(coroutine)<\/strong><\/p>\nThe coroutine is scheduled to run concurrently in the background<\/em><\/strong>. Unlike await, the current coroutine continues executing immediately without waiting for the scheduled task to\u00a0finish.<\/p>\nThe scheduled coroutine starts running as soon as the event loop finds an opportunity<\/em><\/strong>, without needing to wait for an explicit\u00a0await.<\/p>\nNo new threads are created; instead, the coroutine runs within the same thread as the event loop, which manages when each task gets execution time.<\/p><\/blockquote>\n
This approach enables concurrency within the program, allowing multiple tasks to overlap their execution efficiently. You will later need to await the task to get it\u2019s result and ensure it\u2019s\u00a0done.<\/p>\n
Use this approach when you want to run tasks concurrently and don\u2019t need the results immediately.<\/p>\n
Example:<\/strong><\/p>\nWhen the line asyncio.create_task() is reached, the coroutine fetch_data() is scheduled to start running immediately when the event loop is available<\/em><\/strong>. This can happen even before<\/em><\/strong> you explicitly await the task. In contrast, in the first await method, the coroutine only starts executing when the await statement is\u00a0reached.<\/p>\nOverall, this makes the program more efficient by overlapping the execution of multiple\u00a0tasks.<\/p>\n
async def fetch_data():
# Simulate a network call
await asyncio.sleep(1)
return \"data\"
async def main():
# Schedule fetch_data
task = asyncio.create_task(fetch_data())
# Simulate doing other work
await asyncio.sleep(5)
# Now, await task to get the result
result = await task
print(result)
asyncio.run(main())<\/pre>\nOther important points<\/h4>\n\n- \nYou can mix synchronous and asynchronous code. <\/strong>
Since synchronous code is blocking, it can be offloaded to a separate thread using asyncio.to_thread(). This makes your program effectively multithreaded.
In the example below, the asyncio event loop runs on the main thread, while a separate background thread is used to execute the sync_task.<\/li>\n<\/ul>\nimport asyncio
import time
def sync_task():
time.sleep(2)
return \"Completed\"
async def main():
result = await asyncio.to_thread(sync_task)
print(result)
asyncio.run(main())<\/pre>\n
\n- You should offload CPU-bound tasks which are computationally intensive to a separate\u00a0process.<\/li>\n<\/ul>\n
When should I use which concurrency model?<\/h3>\n
This flow is a good way to decide when to use\u00a0what.<\/p>\nFlowchart (drawn by me), referencing this stackoverflow<\/a> discussion<\/figcaption><\/figure>\n\n- \nMultiprocessing<\/strong>
– Best for CPU-bound tasks which are computationally intensive.
– When you need to bypass the GIL\u200a\u2014\u200aEach process has it\u2019s own Python interpreter, allowing for true parallelism.<\/li>\n- \nMultithreading<\/strong>
– Best for fast I\/O-bound tasks as the frequency of context switching is reduced and the Python interpreter sticks to a single thread for longer
– Not ideal for CPU-bound tasks due to\u00a0GIL.<\/li>\n- \nAsyncio<\/strong>
– Ideal for slow I\/O-bound tasks such as long network requests or database queries because it efficiently handles waiting, making it scalable.
– Not suitable for CPU-bound tasks without offloading work to other processes.<\/li>\n<\/ol>\nWrapping up<\/h3>\n
That\u2019s it folks. There\u2019s a lot more that this topic has to cover but I hope I\u2019ve introduced to you the various concepts, and when to use each\u00a0method.<\/p>\n
Thanks for reading! I write regularly on Python, software development and the projects I build, so give me a follow to not miss out. See you in the next article\u00a0\ud83d\ude42<\/p>\n
<\/p>\n
\nDeep Dive into Multithreading, Multiprocessing, and Asyncio<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\n
– Concurrency vs parallelism
– Programs
– Processes
– Threads
– How does the OS manage threads and processes?<\/li>\n
– Multithreading
– Python\u2019s Global Interpreter Lock (GIL)
– Multiprocessing
–\u00a0Asyncio<\/li>\n
Fundamentals of concurrency<\/h3>\n
Before jumping into Python\u2019s concurrency models, let\u2019s recap some foundational concepts.<\/p>\n
1. Concurrency vs Parallelism<\/h4>\nVisual representation of concurrency vs parallelism (drawn by\u00a0me)<\/figcaption><\/figure>\nConcurrency is all about managing multiple tasks at the same time, not necessarily simultaneously. Tasks may take turns, creating the illusion of multitasking.<\/p>\n
Parallelism is about running multiple tasks simultaneously, typically by leveraging multiple CPU\u00a0cores.<\/p>\n
2. Programs<\/h4>\n
Now let\u2019s move on to some fundamental OS concepts\u200a\u2014\u200aprograms, processes and\u00a0threads.<\/p>\nMultiple threads can exist simultaneously within the a single process\u200a\u2014\u200aknown as multithreading (drawn by\u00a0me)<\/figcaption><\/figure>\nA program is simply a static file, like a Python script or an executable.<\/p><\/blockquote>\n
A program sits on disk, and is passive until the operating system (OS) loads it into memory to run. Once this happens, the program becomes a\u00a0process<\/strong>.<\/p>\n3. Processes<\/h4>\nA process is an independent instance of a running\u00a0program.<\/p><\/blockquote>\n
A process has its own memory space, resources, and execution state. Processes are isolated from each other, meaning one process cannot interfere with another unless explicitly designed to do so via mechanisms like inter-process communication (IPC)<\/em><\/strong>.<\/p>\nProcesses can generally be categorised into two\u00a0types:<\/p>\n
\n- \nI\/O-bound processes:<\/strong>
Spend most of it\u2019s time waiting<\/em><\/strong> for input\/output operations to complete, such as file access, network communication, or user input. While waiting, the CPU sits\u00a0idle.<\/li>\n- \nCPU-bound processes:<\/strong>
Spend most of their time doing computations<\/em><\/strong> (e.g video encoding, numerical analysis). These tasks require a lot of CPU\u00a0time.<\/li>\n<\/ol>\nLifecycle of a\u00a0process:<\/strong><\/p>\n\n- A process starts in a new<\/em> state when\u00a0created.<\/li>\n
- It moves to the ready<\/em> state, waiting for CPU\u00a0time.<\/li>\n
- If the process waits for an event like I\/O, it enters the waiting<\/em>\u00a0state.<\/li>\n
- Finally, it terminates<\/em> after completing its\u00a0task.<\/li>\n<\/ul>\n
4. Threads<\/h4>\nA thread is the smallest unit of execution within a process.
A process acts as a \u201ccontainer\u201d for threads, and multiple threads can be created and destroyed over the process\u2019s lifetime.<\/p><\/blockquote>\n
Every process has at least one thread\u200a\u2014\u200athe main thread<\/em><\/strong>\u200a<\/em>\u2014\u200abut it can also create additional threads.<\/p>\nThreads share memory and resources within the same process, enabling efficient communication. However, this sharing can lead to synchronisation issues like race conditions or deadlocks if not managed carefully. Unlike processes, multiple threads in a single process are not isolated\u200a\u2014\u200aone misbehaving thread can crash the entire\u00a0process.<\/p>\n
5. How does the OS manage threads and processes?<\/h4>\n
The CPU can execute only one task per core at a time<\/em><\/strong>. To handle multiple tasks, the operating system uses preemptive context switching<\/em><\/strong>.<\/p>\nDuring a context switch, the OS pauses the current task, saves its state and loads the state of the next task to be executed.<\/p>\n
This rapid switching creates the illusion of simultaneous execution on a single CPU\u00a0core.<\/p>\n
For processes, context switching is more resource-intensive because the OS must save and load separate memory spaces. For threads, switching is faster because threads share the same memory within a process. However, frequent switching introduces overhead, which can slow down performance.<\/p>\n
True parallel execution of processes can only occur if there are multiple CPU cores available. Each core handles a separate process simultaneously.<\/p>\n
Python\u2019s concurrency models<\/h3>\n
Let\u2019s now explore Python\u2019s specific concurrency models.<\/p>\nSummary of the different concurrency models (drawn by\u00a0me)<\/figcaption><\/figure>\n1. Multithreading<\/h3>\n
Multithreading allows a process to execute multiple threads concurrently, with threads sharing the same memory and resources (see diagrams 2 and\u00a04).<\/p>\n
However, Python\u2019s Global Interpreter Lock (GIL) limits multithreading\u2019s effectiveness for CPU-bound tasks.<\/p>\n
Python\u2019s Global Interpreter Lock\u00a0(GIL)<\/h4>\nThe GIL is a lock that allows only one thread to hold control of the Python interpreter at any time, meaning only one thread can execute Python bytecode at\u00a0once.<\/p><\/blockquote>\n
The GIL was introduced to simplify memory management in Python as many internal operations, such as object creation, are not thread safe by default. Without a GIL, multiple threads trying to access the shared resources will require complex locks or synchronisation mechanisms to prevent race conditions and data corruption.<\/p>\n
When is GIL a bottleneck?<\/em><\/strong><\/p>\n\n- For single threaded programs, the GIL is irrelevant as the thread has exclusive access to the Python interpreter.<\/li>\n
- For multithreaded I\/O-bound programs, the GIL is less problematic as threads release the GIL when waiting for I\/O operations.<\/li>\n
- For multithreaded CPU-bound operations, the GIL becomes a significant bottleneck. Multiple threads competing for the GIL must take turns executing Python bytecode.<\/li>\n<\/ul>\n
An interesting case worth noting is the use of time.sleep, which Python effectively treats as an I\/O operation. The time.sleep function is not CPU-bound because it does not involve active computation or the execution of Python bytecode during the sleep period. Instead, the responsibility of tracking the elapsed time is delegated to the OS. During this time, the thread releases the GIL, allowing other threads to run and utilise the interpreter.<\/p>\n
2. Multiprocessing<\/h3>\n
Multiprocessing enables a system to run multiple processes in parallel, each with its own memory, GIL and resources. Within each process, there may be one or more threads (see diagrams 3 and\u00a04).<\/p>\n
Multiprocessing bypasses the limitations of the GIL. This makes it suitable for CPU bound tasks that require heavy computation.<\/p>\n
However, multiprocessing is more resource intensive due to separate memory and process overheads.<\/p>\n
3. Asyncio<\/h3>\nUnlike threads or processes, asyncio uses a single thread to handle multiple\u00a0tasks.<\/p><\/blockquote>\n
When writing asynchronous code with the asyncio library, you’ll use the async\/await keywords to manage\u00a0tasks.<\/p>\n
Key concepts<\/em><\/strong><\/h4>\n\n- \nCoroutines:<\/strong> These are functions defined with async def\u00a0. They are the core of asyncio and represent tasks that can be paused and resumed\u00a0later.<\/li>\n
- \nEvent loop:<\/strong> It manages the execution of\u00a0tasks.<\/li>\n
- \nTasks:<\/strong> Wrappers around coroutines. When you want a coroutine to actually start running, you turn it into a task\u200a\u2014\u200aeg. using asyncio.create_task()<\/li>\n
- \nawait<\/strong>\u00a0: Pauses execution of a coroutine, giving control back to the event\u00a0loop.<\/li>\n<\/ol>\n
How it\u00a0works<\/em><\/strong><\/h4>\nAsyncio runs an event loop that schedules tasks. Tasks voluntarily \u201cpause\u201d themselves when waiting for something, like a network response or a file read. While the task is paused, the event loop switches to another task, ensuring no time is wasted\u00a0waiting.<\/p>\n
This makes asyncio ideal for scenarios involving many small tasks that spend a lot of time waiting<\/strong>, such as handling thousands of web requests or managing database queries. Since everything runs on a single thread, asyncio avoids the overhead and complexity of thread switching.<\/p>\nThe key difference between asyncio and multithreading lies in how they handle waiting\u00a0tasks.<\/strong><\/p><\/blockquote>\n\n- Multithreading relies on the OS to switch between threads when one thread is waiting (preemptive context switching<\/em><\/strong>).
When a thread is waiting, the OS switches to another thread automatically.<\/li>\n- Asyncio uses a single thread and depends on tasks to \u201ccooperate\u201d by pausing when they need to wait (cooperative multitasking<\/em><\/strong>).<\/li>\n<\/ul>\n
2 ways to write async\u00a0code:<\/h4>\n
method 1: await coroutine<\/strong><\/p>\nWhen you directly await a coroutine, the execution of the current coroutine pauses<\/em><\/strong> at the await statement until the awaited coroutine finishes. Tasks are executed sequentially <\/em><\/strong>within the current coroutine.<\/em><\/strong><\/p>\nUse this approach when you need the result of the coroutine <\/em>immediately<\/em><\/strong> to proceed with the next\u00a0steps.<\/p>\nAlthough this might sound like synchronous code, it\u2019s not. In synchronous code, the entire program would block during a\u00a0pause.<\/p>\n
With asyncio, only the current coroutine pauses, while the rest of the program can continue running. This makes asyncio non-blocking at the program\u00a0level.<\/p><\/blockquote>\n
Example:<\/strong><\/p>\nThe event loop pauses the current coroutine until fetch_data is complete.<\/p>\n
async def fetch_data():
print(\"Fetching data...\")
await asyncio.sleep(1) # Simulate a network call
print(\"Data fetched\")
return \"data\"
async def main():
result = await fetch_data() # Current coroutine pauses here
print(f\"Result: {result}\")
asyncio.run(main())<\/pre>\nmethod 2: asyncio.create_task(coroutine)<\/strong><\/p>\nThe coroutine is scheduled to run concurrently in the background<\/em><\/strong>. Unlike await, the current coroutine continues executing immediately without waiting for the scheduled task to\u00a0finish.<\/p>\nThe scheduled coroutine starts running as soon as the event loop finds an opportunity<\/em><\/strong>, without needing to wait for an explicit\u00a0await.<\/p>\nNo new threads are created; instead, the coroutine runs within the same thread as the event loop, which manages when each task gets execution time.<\/p><\/blockquote>\n
This approach enables concurrency within the program, allowing multiple tasks to overlap their execution efficiently. You will later need to await the task to get it\u2019s result and ensure it\u2019s\u00a0done.<\/p>\n
Use this approach when you want to run tasks concurrently and don\u2019t need the results immediately.<\/p>\n
Example:<\/strong><\/p>\nWhen the line asyncio.create_task() is reached, the coroutine fetch_data() is scheduled to start running immediately when the event loop is available<\/em><\/strong>. This can happen even before<\/em><\/strong> you explicitly await the task. In contrast, in the first await method, the coroutine only starts executing when the await statement is\u00a0reached.<\/p>\nOverall, this makes the program more efficient by overlapping the execution of multiple\u00a0tasks.<\/p>\n
async def fetch_data():
# Simulate a network call
await asyncio.sleep(1)
return \"data\"
async def main():
# Schedule fetch_data
task = asyncio.create_task(fetch_data())
# Simulate doing other work
await asyncio.sleep(5)
# Now, await task to get the result
result = await task
print(result)
asyncio.run(main())<\/pre>\nOther important points<\/h4>\n\n- \nYou can mix synchronous and asynchronous code. <\/strong>
Since synchronous code is blocking, it can be offloaded to a separate thread using asyncio.to_thread(). This makes your program effectively multithreaded.
In the example below, the asyncio event loop runs on the main thread, while a separate background thread is used to execute the sync_task.<\/li>\n<\/ul>\nimport asyncio
import time
def sync_task():
time.sleep(2)
return \"Completed\"
async def main():
result = await asyncio.to_thread(sync_task)
print(result)
asyncio.run(main())<\/pre>\n
\n- You should offload CPU-bound tasks which are computationally intensive to a separate\u00a0process.<\/li>\n<\/ul>\n
When should I use which concurrency model?<\/h3>\n
This flow is a good way to decide when to use\u00a0what.<\/p>\nFlowchart (drawn by me), referencing this stackoverflow<\/a> discussion<\/figcaption><\/figure>\n\n- \nMultiprocessing<\/strong>
– Best for CPU-bound tasks which are computationally intensive.
– When you need to bypass the GIL\u200a\u2014\u200aEach process has it\u2019s own Python interpreter, allowing for true parallelism.<\/li>\n- \nMultithreading<\/strong>
– Best for fast I\/O-bound tasks as the frequency of context switching is reduced and the Python interpreter sticks to a single thread for longer
– Not ideal for CPU-bound tasks due to\u00a0GIL.<\/li>\n- \nAsyncio<\/strong>
– Ideal for slow I\/O-bound tasks such as long network requests or database queries because it efficiently handles waiting, making it scalable.
– Not suitable for CPU-bound tasks without offloading work to other processes.<\/li>\n<\/ol>\nWrapping up<\/h3>\n
That\u2019s it folks. There\u2019s a lot more that this topic has to cover but I hope I\u2019ve introduced to you the various concepts, and when to use each\u00a0method.<\/p>\n
Thanks for reading! I write regularly on Python, software development and the projects I build, so give me a follow to not miss out. See you in the next article\u00a0\ud83d\ude42<\/p>\n
<\/p>\n
\nDeep Dive into Multithreading, Multiprocessing, and Asyncio<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\n
Concurrency is all about managing multiple tasks at the same time, not necessarily simultaneously. Tasks may take turns, creating the illusion of multitasking.<\/p>\n
Parallelism is about running multiple tasks simultaneously, typically by leveraging multiple CPU\u00a0cores.<\/p>\n
2. Programs<\/h4>\n
Now let\u2019s move on to some fundamental OS concepts\u200a\u2014\u200aprograms, processes and\u00a0threads.<\/p>\n A program is simply a static file, like a Python script or an executable.<\/p><\/blockquote>\n A program sits on disk, and is passive until the operating system (OS) loads it into memory to run. Once this happens, the program becomes a\u00a0process<\/strong>.<\/p>\n A process is an independent instance of a running\u00a0program.<\/p><\/blockquote>\n A process has its own memory space, resources, and execution state. Processes are isolated from each other, meaning one process cannot interfere with another unless explicitly designed to do so via mechanisms like inter-process communication (IPC)<\/em><\/strong>.<\/p>\n Processes can generally be categorised into two\u00a0types:<\/p>\n Lifecycle of a\u00a0process:<\/strong><\/p>\n A thread is the smallest unit of execution within a process. Every process has at least one thread\u200a\u2014\u200athe main thread<\/em><\/strong>\u200a<\/em>\u2014\u200abut it can also create additional threads.<\/p>\n Threads share memory and resources within the same process, enabling efficient communication. However, this sharing can lead to synchronisation issues like race conditions or deadlocks if not managed carefully. Unlike processes, multiple threads in a single process are not isolated\u200a\u2014\u200aone misbehaving thread can crash the entire\u00a0process.<\/p>\n The CPU can execute only one task per core at a time<\/em><\/strong>. To handle multiple tasks, the operating system uses preemptive context switching<\/em><\/strong>.<\/p>\n During a context switch, the OS pauses the current task, saves its state and loads the state of the next task to be executed.<\/p>\n This rapid switching creates the illusion of simultaneous execution on a single CPU\u00a0core.<\/p>\n For processes, context switching is more resource-intensive because the OS must save and load separate memory spaces. For threads, switching is faster because threads share the same memory within a process. However, frequent switching introduces overhead, which can slow down performance.<\/p>\n True parallel execution of processes can only occur if there are multiple CPU cores available. Each core handles a separate process simultaneously.<\/p>\n Let\u2019s now explore Python\u2019s specific concurrency models.<\/p>\n Multithreading allows a process to execute multiple threads concurrently, with threads sharing the same memory and resources (see diagrams 2 and\u00a04).<\/p>\n However, Python\u2019s Global Interpreter Lock (GIL) limits multithreading\u2019s effectiveness for CPU-bound tasks.<\/p>\n The GIL is a lock that allows only one thread to hold control of the Python interpreter at any time, meaning only one thread can execute Python bytecode at\u00a0once.<\/p><\/blockquote>\n The GIL was introduced to simplify memory management in Python as many internal operations, such as object creation, are not thread safe by default. Without a GIL, multiple threads trying to access the shared resources will require complex locks or synchronisation mechanisms to prevent race conditions and data corruption.<\/p>\n When is GIL a bottleneck?<\/em><\/strong><\/p>\n An interesting case worth noting is the use of time.sleep, which Python effectively treats as an I\/O operation. The time.sleep function is not CPU-bound because it does not involve active computation or the execution of Python bytecode during the sleep period. Instead, the responsibility of tracking the elapsed time is delegated to the OS. During this time, the thread releases the GIL, allowing other threads to run and utilise the interpreter.<\/p>\n Multiprocessing enables a system to run multiple processes in parallel, each with its own memory, GIL and resources. Within each process, there may be one or more threads (see diagrams 3 and\u00a04).<\/p>\n Multiprocessing bypasses the limitations of the GIL. This makes it suitable for CPU bound tasks that require heavy computation.<\/p>\n However, multiprocessing is more resource intensive due to separate memory and process overheads.<\/p>\n Unlike threads or processes, asyncio uses a single thread to handle multiple\u00a0tasks.<\/p><\/blockquote>\n When writing asynchronous code with the asyncio library, you’ll use the async\/await keywords to manage\u00a0tasks.<\/p>\n Asyncio runs an event loop that schedules tasks. Tasks voluntarily \u201cpause\u201d themselves when waiting for something, like a network response or a file read. While the task is paused, the event loop switches to another task, ensuring no time is wasted\u00a0waiting.<\/p>\n This makes asyncio ideal for scenarios involving many small tasks that spend a lot of time waiting<\/strong>, such as handling thousands of web requests or managing database queries. Since everything runs on a single thread, asyncio avoids the overhead and complexity of thread switching.<\/p>\n The key difference between asyncio and multithreading lies in how they handle waiting\u00a0tasks.<\/strong><\/p><\/blockquote>\n method 1: await coroutine<\/strong><\/p>\n When you directly await a coroutine, the execution of the current coroutine pauses<\/em><\/strong> at the await statement until the awaited coroutine finishes. Tasks are executed sequentially <\/em><\/strong>within the current coroutine.<\/em><\/strong><\/p>\n Use this approach when you need the result of the coroutine <\/em>immediately<\/em><\/strong> to proceed with the next\u00a0steps.<\/p>\n Although this might sound like synchronous code, it\u2019s not. In synchronous code, the entire program would block during a\u00a0pause.<\/p>\n With asyncio, only the current coroutine pauses, while the rest of the program can continue running. This makes asyncio non-blocking at the program\u00a0level.<\/p><\/blockquote>\n Example:<\/strong><\/p>\n The event loop pauses the current coroutine until fetch_data is complete.<\/p>\n method 2: asyncio.create_task(coroutine)<\/strong><\/p>\n The coroutine is scheduled to run concurrently in the background<\/em><\/strong>. Unlike await, the current coroutine continues executing immediately without waiting for the scheduled task to\u00a0finish.<\/p>\n The scheduled coroutine starts running as soon as the event loop finds an opportunity<\/em><\/strong>, without needing to wait for an explicit\u00a0await.<\/p>\n No new threads are created; instead, the coroutine runs within the same thread as the event loop, which manages when each task gets execution time.<\/p><\/blockquote>\n This approach enables concurrency within the program, allowing multiple tasks to overlap their execution efficiently. You will later need to await the task to get it\u2019s result and ensure it\u2019s\u00a0done.<\/p>\n Use this approach when you want to run tasks concurrently and don\u2019t need the results immediately.<\/p>\n Example:<\/strong><\/p>\n When the line asyncio.create_task() is reached, the coroutine fetch_data() is scheduled to start running immediately when the event loop is available<\/em><\/strong>. This can happen even before<\/em><\/strong> you explicitly await the task. In contrast, in the first await method, the coroutine only starts executing when the await statement is\u00a0reached.<\/p>\n Overall, this makes the program more efficient by overlapping the execution of multiple\u00a0tasks.<\/p>\n This flow is a good way to decide when to use\u00a0what.<\/p>\n That\u2019s it folks. There\u2019s a lot more that this topic has to cover but I hope I\u2019ve introduced to you the various concepts, and when to use each\u00a0method.<\/p>\n Thanks for reading! I write regularly on Python, software development and the projects I build, so give me a follow to not miss out. See you in the next article\u00a0\ud83d\ude42<\/p>\n Deep Dive into Multithreading, Multiprocessing, and Asyncio<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\n3. Processes<\/h4>\n
\n
Spend most of it\u2019s time waiting<\/em><\/strong> for input\/output operations to complete, such as file access, network communication, or user input. While waiting, the CPU sits\u00a0idle.<\/li>\n
Spend most of their time doing computations<\/em><\/strong> (e.g video encoding, numerical analysis). These tasks require a lot of CPU\u00a0time.<\/li>\n<\/ol>\n\n
4. Threads<\/h4>\n
A process acts as a \u201ccontainer\u201d for threads, and multiple threads can be created and destroyed over the process\u2019s lifetime.<\/p><\/blockquote>\n5. How does the OS manage threads and processes?<\/h4>\n
Python\u2019s concurrency models<\/h3>\n
1. Multithreading<\/h3>\n
Python\u2019s Global Interpreter Lock\u00a0(GIL)<\/h4>\n
\n
2. Multiprocessing<\/h3>\n
3. Asyncio<\/h3>\n
Key concepts<\/em><\/strong><\/h4>\n
\n
How it\u00a0works<\/em><\/strong><\/h4>\n
\n
When a thread is waiting, the OS switches to another thread automatically.<\/li>\n2 ways to write async\u00a0code:<\/h4>\n
async def fetch_data():
print(\"Fetching data...\")
await asyncio.sleep(1) # Simulate a network call
print(\"Data fetched\")
return \"data\"
async def main():
result = await fetch_data() # Current coroutine pauses here
print(f\"Result: {result}\")
asyncio.run(main())<\/pre>\nasync def fetch_data():
# Simulate a network call
await asyncio.sleep(1)
return \"data\"
async def main():
# Schedule fetch_data
task = asyncio.create_task(fetch_data())
# Simulate doing other work
await asyncio.sleep(5)
# Now, await task to get the result
result = await task
print(result)
asyncio.run(main())<\/pre>\nOther important points<\/h4>\n
\n
Since synchronous code is blocking, it can be offloaded to a separate thread using asyncio.to_thread(). This makes your program effectively multithreaded.
In the example below, the asyncio event loop runs on the main thread, while a separate background thread is used to execute the sync_task.<\/li>\n<\/ul>\nimport asyncio
import time
def sync_task():
time.sleep(2)
return \"Completed\"
async def main():
result = await asyncio.to_thread(sync_task)
print(result)
asyncio.run(main())<\/pre>\n\n
When should I use which concurrency model?<\/h3>\n
\n
– Best for CPU-bound tasks which are computationally intensive.
– When you need to bypass the GIL\u200a\u2014\u200aEach process has it\u2019s own Python interpreter, allowing for true parallelism.<\/li>\n
– Best for fast I\/O-bound tasks as the frequency of context switching is reduced and the Python interpreter sticks to a single thread for longer
– Not ideal for CPU-bound tasks due to\u00a0GIL.<\/li>\n
– Ideal for slow I\/O-bound tasks such as long network requests or database queries because it efficiently handles waiting, making it scalable.
– Not suitable for CPU-bound tasks without offloading work to other processes.<\/li>\n<\/ol>\nWrapping up<\/h3>\n
<\/p>\n
\n