In Python, the standard library provides the threading module for multitasking. Threads allow multiple operations to be executed in parallel within a single process. However, in the standard implementation of Python (CPython), there is a mechanism called GIL (Global Interpreter Lock) — a global lock that allows only one thread to execute Python bytecode at a time.
This means that in CPython, multithreading does not achieve real parallelism when executing Python code at the CPU level; parallelism is useful only for I/O-bound tasks. For CPU-bound tasks, it is recommended to use the multiprocessing module, which spawns multiple processes and bypasses the GIL.
Example:
import threading def worker(): print('Start') # heavy computations print('End') threads = [threading.Thread(target=worker) for _ in range(5)] for t in threads: t.start() for t in threads: t.join()
For parallelism in intensive computations, use multiprocessing:
from multiprocessing import Pool def square(x): return x*x with Pool(4) as p: print(p.map(square, [1, 2, 3, 4]))
Can multithreading in Python speed up the execution of compute-heavy tasks?
Answer: No, due to the GIL in the standard implementation of Python (CPython), threads won't yield performance improvements on CPU-bound tasks; for such tasks, use multiprocessing or alternative interpreter implementations (e.g., Jython, IronPython) that do not have GIL.
Story
In a project for processing large volumes of data, the team tried to speed up calculations using threads (
threading). Instead of speeding up, the execution time increased because the GIL did not allow threads to operate in parallel; after switching tomultiprocessing, the task was solved.
Story
A developer was trying to download large files and process them in multiple threads simultaneously but often encountered "deadlock" due to careless use of shared variables without locks (thread safety).
Story
On a backend server, heavy request processing was implemented in a thread pool. As the load increased, the server began to "freeze" — it turned out that most of the time, threads spent waiting for the execution of Python code due to GIL, even though the requests were not related to intensive I/O.