Python Threads and Concurrency: Difference between revisions
Jump to navigation
Jump to search
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[Python_Language#Thread|Python Language]] | * [[Python_Language#Thread|Python Language]] | ||
* [[ | * [[Concurrent_(Parallel)_Programming#Overview|Concurrent (Parallel) Programming]] | ||
=TODO= | =TODO= | ||
<font color='darkkhaki'> | <font color='darkkhaki'> | ||
* PROCESS [[PyOOP]] "Concurrency" + "Threads" + "The many problems with threads" + "Shared memory" + "The global interpreter lock" + "Thread overhead" + "Multiprocessing" + "Multiprocessing pools" + "Queues" + "The problems with multiprocessing" + "Futures" + "AsyncIO" + "AsyncIO in action" + "Reading an AsyncIO Future" + "AsyncIO for networking" + "Using executors to wrap blocking code" + "Streams" + "Executors" + "AsyncIO clients" + "Case Study" | * PROCESS [[PyOOP]] "Concurrency" + "Threads" + "The many problems with threads" + "Shared memory" + "The global interpreter lock" + "Thread overhead" + "Multiprocessing" + "Multiprocessing pools" + "Queues" + "The problems with multiprocessing" + "Futures" + "AsyncIO" + "AsyncIO in action" + "Reading an AsyncIO Future" + "AsyncIO for networking" + "Using executors to wrap blocking code" + "Streams" + "Executors" + "AsyncIO clients" + "Case Study" | ||
* Develop [[Python_Global_Interpreter_Lock_(GIL)|Python Global Interpreter Lock (GIL)]] | |||
</font> | </font> | ||
=Overview= | =Overview= | ||
Python is not the best choice for building highly concurrent, multi-threaded applications, particularly applications with many CPU-bound threads. The main reason for this is Python's [[Python_Global_Interpreter_Lock_(GIL)|Global Interpreter Lock (GIL)]], a mechanisms that prevents the interpreter from executing more than one instruction at a time, even in the presence of multiple cores. There are Python C extensions that use native multithreading in C or C++ to run code in parallel without being impacted by the GIL, as long as they do not need to regularly interact with Python objects. | |||
Latest revision as of 23:15, 14 May 2024
Internal
TODO
- PROCESS PyOOP "Concurrency" + "Threads" + "The many problems with threads" + "Shared memory" + "The global interpreter lock" + "Thread overhead" + "Multiprocessing" + "Multiprocessing pools" + "Queues" + "The problems with multiprocessing" + "Futures" + "AsyncIO" + "AsyncIO in action" + "Reading an AsyncIO Future" + "AsyncIO for networking" + "Using executors to wrap blocking code" + "Streams" + "Executors" + "AsyncIO clients" + "Case Study"
- Develop Python Global Interpreter Lock (GIL)
Overview
Python is not the best choice for building highly concurrent, multi-threaded applications, particularly applications with many CPU-bound threads. The main reason for this is Python's Global Interpreter Lock (GIL), a mechanisms that prevents the interpreter from executing more than one instruction at a time, even in the presence of multiple cores. There are Python C extensions that use native multithreading in C or C++ to run code in parallel without being impacted by the GIL, as long as they do not need to regularly interact with Python objects.