âčïž Skipped - page is already crawled
| Filter | Status | Condition | Details |
|---|---|---|---|
| HTTP status | PASS | download_http_code = 200 | HTTP 200 |
| Age cutoff | PASS | download_stamp > now() - 6 MONTH | 0.1 months ago |
| History drop | PASS | isNull(history_drop_reason) | No drop reason |
| Spam/ban | PASS | fh_dont_index != 1 AND ml_spam_score = 0 | ml_spam_score=0 |
| Canonical | PASS | meta_canonical IS NULL OR = '' OR = src_unparsed | Not set |
| Property | Value |
|---|---|
| URL | https://realpython.com/python-gil/ |
| Last Crawled | 2026-04-16 12:31:37 (2 days ago) |
| First Indexed | 2018-03-25 04:47:50 (8 years ago) |
| HTTP Status Code | 200 |
| Meta Title | What Is the Python Global Interpreter Lock (GIL)? â Real Python |
| Meta Description | Python's Global Interpreter Lock or GIL, in simple words, is a mutex (or a lock) that allows only one thread to hold the control of the Python interpreter at any one time. In this article you'll learn how the GIL affects the performance of your Python programs. |
| Meta Canonical | null |
| Boilerpipe Text | by
Abhinav Ajitsaria
Reading time estimate
11m
advanced
python
The Python Global Interpreter Lock or
GIL
, in simple words, is a mutex (or a lock) that allows only one
thread
to hold the control of the Python interpreter.
This means that only one thread can be in a state of execution at any point in time. The impact of the GIL isnât visible to developers who execute single-threaded programs, but it can be a performance bottleneck in CPU-bound and multi-threaded code.
Since the GIL allows only one thread to execute at a time even in a multi-threaded architecture with more than one CPU core, the GIL has gained a reputation as an âinfamousâ feature of Python.
In this article youâll learn how the GIL affects the performance of your Python programs, and how you can mitigate the impact it might have on your code.
What Problem Did the GIL Solve for Python?
Python uses reference counting for
memory management
. It means that objects created in Python have a reference count variable that keeps track of the number of references that point to the object. When this count reaches zero, the memory occupied by the object is released.
Letâs take a look at a brief code example to demonstrate how reference counting works:
In the above example, the reference count for the empty list object
[]
was 3. The list object was referenced by
a
,
b
and the argument passed to
sys.getrefcount()
.
Back to the GIL:
The problem was that this reference count variable needed protection from race conditions where two threads increase or decrease its value simultaneously. If this happens, it can cause either leaked memory that is never released or, even worse, incorrectly release the memory while a reference to that object still exists. This can cause crashes or other âweirdâ bugs in your Python programs.
This reference count variable can be kept safe by adding
locks
to all data structures that are shared across threads so that they are not modified inconsistently.
But adding a lock to each object or groups of objects means multiple locks will exist which can cause another problemâDeadlocks (deadlocks can only happen if there is more than one lock). Another side effect would be decreased performance caused by the repeated acquisition and release of locks.
The GIL is a single lock on the interpreter itself which adds a rule that execution of any Python bytecode requires acquiring the interpreter lock. This prevents deadlocks (as there is only one lock) and doesnât introduce much performance overhead. But it effectively makes any CPU-bound Python program single-threaded.
The GIL, although used by interpreters for other languages like Ruby, is not the only solution to this problem. Some languages avoid the requirement of a GIL for thread-safe memory management by using approaches other than reference counting, such as garbage collection.
On the other hand, this means that those languages often have to compensate for the loss of single threaded performance benefits of a GIL by adding other performance boosting features like JIT compilers.
Why Was the GIL Chosen as the Solution?
So, why was an approach that is seemingly so obstructing used in Python? Was it a bad decision by the developers of Python?
Well, in the
words of Larry Hastings
, the design decision of the GIL is one of the things that made Python as popular as it is today.
Python has been around since the days when operating systems did not have a concept of threads. Python was designed to be easy-to-use in order to make development quicker and more and more developers started using it.
A lot of extensions were being written for the existing C libraries whose features were needed in Python. To prevent inconsistent changes, these C extensions required a thread-safe memory management which the GIL provided.
The GIL is simple to implement and was easily added to Python. It provides a performance increase to single-threaded programs as only one lock needs to be managed.
C libraries that were not thread-safe became easier to integrate. And these C extensions became one of the reasons why Python was readily adopted by different communities.
As you can see, the GIL was a pragmatic solution to a difficult problem that the
CPython
developers faced early on in Pythonâs life.
The Impact on Multi-Threaded Python Programs
When you look at a typical Python programâor any computer program for that matterâthereâs a difference between those that are CPU-bound in their performance and those that are I/O-bound.
CPU-bound programs are those that are pushing the CPU to its limit. This includes programs that do mathematical computations like matrix multiplications, searching, image processing, etc.
I/O-bound programs are the ones that spend time waiting for
Input/Output
which can come from a user, file, database, network, etc. I/O-bound programs sometimes have to wait for a significant amount of time till they get what they need from the source due to the fact that the source may need to do its own processing before the input/output is ready, for example, a user thinking about what to enter into an input prompt or a database query running in its own process.
Letâs have a look at a simple CPU-bound program that performs a countdown:
Running this code on my system with 4 cores gave the following output:
Now I modified the code a bit to do to the same countdown using two threads in parallel:
And when I ran it again:
As you can see, both versions take almost same amount of time to finish. In the multi-threaded version the GIL prevented the CPU-bound threads from executing in parallel.
The GIL does not have much impact on the performance of I/O-bound multi-threaded programs as the lock is shared between threads while they are waiting for I/O.
But a program whose threads are entirely CPU-bound, e.g., a program that processes an image in parts using threads, would not only become single threaded due to the lock but will also see an increase in execution time, as seen in the above example, in comparison to a scenario where it was written to be entirely single-threaded.
This increase is the result of acquire and release overheads added by the lock.
Why Hasnât the GIL Been Removed Yet?
The developers of Python receive a lot of complaints regarding this but a language as popular as Python cannot bring a change as significant as the removal of GIL without causing backward incompatibility issues.
The GIL can obviously be removed and this has been done multiple times in the past by the developers and researchers but all those attempts broke the existing C extensions which depend heavily on the solution that the GIL provides.
Of course, there are other solutions to the problem that the GIL solves but some of them decrease the performance of single-threaded and multi-threaded I/O-bound programs and some of them are just too difficult. After all, you wouldnât want your existing Python programs to run slower after a new version comes out, right?
The creator and BDFL of Python, Guido van Rossum, gave an answer to the community in September 2007 in his article
âIt isnât Easy to remove the GILâ
:
âIâd welcome a set of patches into Py3k
only if
the performance for a single-threaded program (and for a multi-threaded but I/O-bound program)
does not decrease
â
And this condition hasnât been fulfilled by any of the attempts made since.
Why Wasnât It Removed in Python 3?
Python 3 did have a chance to start a lot of features from scratch and in the process, broke some of the existing C extensions which then required changes to be updated and ported to work with Python 3. This was the reason why the early versions of Python 3 saw slower adoption by the community.
But why wasnât GIL removed alongside?
Removing the GIL would have made Python 3 slower in comparison to Python 2 in single-threaded performance and you can imagine what that would have resulted in. You canât argue with the single-threaded performance benefits of the GIL. So the result is that Python 3 still has the GIL.
But Python 3 did bring a major improvement to the existing GILâ
We discussed the impact of GIL on âonly CPU-boundâ and âonly I/O-boundâ multi-threaded programs but what about the programs where some threads are I/O-bound and some are CPU-bound?
In such programs, Pythonâs GIL was known to starve the I/O-bound threads by not giving them a chance to acquire the GIL from CPU-bound threads.
This was because of a mechanism built into Python that forced threads to release the GIL
after a fixed interval
of continuous use and if nobody else acquired the GIL, the same thread could continue its use.
The problem in this mechanism was that most of the time the CPU-bound thread would reacquire the GIL itself before other threads could acquire it. This was researched by David Beazley and visualizations can be found
here
.
This problem was fixed in Python 3.2 in 2009 by Antoine Pitrou who
added a mechanism
of looking at the number of GIL acquisition requests by other threads that got dropped and not allowing the current thread to reacquire GIL before other threads got a chance to run.
How to Deal With Pythonâs GIL
If the GIL is causing you problems, here a few approaches you can try:
Multi-processing vs multi-threading:
The most popular way is to use a multi-processing approach where you use multiple processes instead of threads. Each Python process gets its own Python interpreter and memory space so the GIL wonât be a problem. Python has a
multiprocessing
module which lets us create processes easily like this:
Running this on my system gave this output:
A decent performance increase compared to the multi-threaded version, right?
The time didnât drop to half of what we saw above because process management has its own overheads. Multiple processes are heavier than multiple threads, so, keep in mind that this could become a scaling bottleneck.
Alternative Python interpreters:
Python has multiple interpreter implementations. CPython, Jython, IronPython and
PyPy
, written in
C
,
Java
, C# and Python respectively, are the most popular ones. GIL exists only in the original Python implementation that is CPython. If your program, with its libraries, is available for one of the other implementations then you can try them out as well.
Just wait it out:
While many Python users take advantage of the single-threaded performance benefits of GIL. The multi-threading programmers donât have to fret as some of the brightest minds in the Python community are working to remove the GIL from CPython. One such attempt is known as the
Gilectomy
.
The Python GIL is often regarded as a mysterious and difficult topic. But keep in mind that as a Pythonista youâre usually only affected by it if you are writing C extensions or if youâre using CPU-bound multi-threading in your programs.
In that case, this article should give you everything you need to understand what the GIL is and how to deal with it in your own projects. And if you want to understand the low-level inner workings of GIL, Iâd recommend you watch the
Understanding the Python GIL
talk by David Beazley.
Take the Quiz:
Test your knowledge with our interactive âWhat Is the Python Global Interpreter Lock (GIL)?â quiz. Youâll receive a score upon completion to help you track your learning progress: |
| Markdown | [](https://realpython.com/)
- [Start Here](https://realpython.com/start-here/)
- [Learn Python](https://realpython.com/python-gil/)
[Python Tutorials â In-depth articles and video courses](https://realpython.com/search?kind=article&kind=course&order=newest)
[Learning Paths â Guided study plans for accelerated learning](https://realpython.com/learning-paths/)
[Quizzes & Exercises â Check your learning progress](https://realpython.com/quizzes/)
[Browse Topics â Focus on a specific area or skill level](https://realpython.com/tutorials/all/)
[Community Chat â Learn with other Pythonistas](https://realpython.com/community/)
[Office Hours â Live Q\&A calls with Python experts](https://realpython.com/office-hours/)
[Live Courses â Live, instructor-led Python courses](https://realpython.com/live/)
[Podcast â Hear whatâs new in the world of Python](https://realpython.com/podcasts/rpp/)
[Books â Round out your knowledge and learn offline](https://realpython.com/products/books/)
[Reference â Concise definitions for common Python terms](https://realpython.com/ref/)
[Code Mentor âBeta Personalized code assistance & learning tools](https://realpython.com/mentor/)
[Unlock All Content â](https://realpython.com/account/join/)
- [More](https://realpython.com/python-gil/)
[Learner Stories](https://realpython.com/learner-stories/) [Python Newsletter](https://realpython.com/newsletter/) [Python Job Board](https://www.pythonjobshq.com/) [Meet the Team](https://realpython.com/team/) [Become a Contributor](https://realpython.com/jobs/)
- [Search](https://realpython.com/search "Search")
- [Join](https://realpython.com/account/join/)
- [SignâIn](https://realpython.com/account/login/?next=%2Fpython-gil%2F)
[Browse Topics](https://realpython.com/tutorials/all/)
[Guided Learning Paths](https://realpython.com/learning-paths/)
[Basics](https://realpython.com/search?level=basics)
[Intermediate](https://realpython.com/search?level=intermediate)
[Advanced](https://realpython.com/search?level=advanced)
***
[ai](https://realpython.com/tutorials/ai/) [algorithms](https://realpython.com/tutorials/algorithms/) [api](https://realpython.com/tutorials/api/) [best-practices](https://realpython.com/tutorials/best-practices/) [career](https://realpython.com/tutorials/career/) [community](https://realpython.com/tutorials/community/) [databases](https://realpython.com/tutorials/databases/) [data-science](https://realpython.com/tutorials/data-science/) [data-structures](https://realpython.com/tutorials/data-structures/) [data-viz](https://realpython.com/tutorials/data-viz/) [devops](https://realpython.com/tutorials/devops/) [django](https://realpython.com/tutorials/django/) [docker](https://realpython.com/tutorials/docker/) [editors](https://realpython.com/tutorials/editors/) [flask](https://realpython.com/tutorials/flask/) [front-end](https://realpython.com/tutorials/front-end/) [gamedev](https://realpython.com/tutorials/gamedev/) [gui](https://realpython.com/tutorials/gui/) [machine-learning](https://realpython.com/tutorials/machine-learning/) [news](https://realpython.com/tutorials/news/) [numpy](https://realpython.com/tutorials/numpy/) [projects](https://realpython.com/tutorials/projects/) [python](https://realpython.com/tutorials/python/) [stdlib](https://realpython.com/tutorials/stdlib/) [testing](https://realpython.com/tutorials/testing/) [tools](https://realpython.com/tutorials/tools/) [web-dev](https://realpython.com/tutorials/web-dev/) [web-scraping](https://realpython.com/tutorials/web-scraping/)
[Table of Contents](https://realpython.com/python-gil/#toc)
- [What Problem Did the GIL Solve for Python?](https://realpython.com/python-gil/#what-problem-did-the-gil-solve-for-python)
- [Why Was the GIL Chosen as the Solution?](https://realpython.com/python-gil/#why-was-the-gil-chosen-as-the-solution)
- [The Impact on Multi-Threaded Python Programs](https://realpython.com/python-gil/#the-impact-on-multi-threaded-python-programs)
- [Why Hasnât the GIL Been Removed Yet?](https://realpython.com/python-gil/#why-hasnt-the-gil-been-removed-yet)
- [Why Wasnât It Removed in Python 3?](https://realpython.com/python-gil/#why-wasnt-it-removed-in-python-3)
- [How to Deal With Pythonâs GIL](https://realpython.com/python-gil/#how-to-deal-with-pythons-gil)
Mark as Completed
Share
Recommended Course
[ Understanding Python's Global Interpreter Lock (GIL) 39m · 8 lessons](https://realpython.com/courses/understanding-global-interpreter-lock-gil/)

# What Is the Python Global Interpreter Lock (GIL)?
by [Abhinav Ajitsaria](https://realpython.com/python-gil/#author)
Reading time estimate
11m
[advanced](https://realpython.com/tutorials/advanced/) [python](https://realpython.com/tutorials/python/)
Mark as Completed
Share
Table of Contents
- [What Problem Did the GIL Solve for Python?](https://realpython.com/python-gil/#what-problem-did-the-gil-solve-for-python)
- [Why Was the GIL Chosen as the Solution?](https://realpython.com/python-gil/#why-was-the-gil-chosen-as-the-solution)
- [The Impact on Multi-Threaded Python Programs](https://realpython.com/python-gil/#the-impact-on-multi-threaded-python-programs)
- [Why Hasnât the GIL Been Removed Yet?](https://realpython.com/python-gil/#why-hasnt-the-gil-been-removed-yet)
- [Why Wasnât It Removed in Python 3?](https://realpython.com/python-gil/#why-wasnt-it-removed-in-python-3)
- [How to Deal With Pythonâs GIL](https://realpython.com/python-gil/#how-to-deal-with-pythons-gil)
[Remove ads](https://realpython.com/account/join/)
Recommended Course
[Understanding Python's Global Interpreter Lock (GIL)](https://realpython.com/courses/understanding-global-interpreter-lock-gil/) (39m)
The Python Global Interpreter Lock or [GIL](https://wiki.python.org/moin/GlobalInterpreterLock), in simple words, is a mutex (or a lock) that allows only one [thread](https://realpython.com/intro-to-python-threading/) to hold the control of the Python interpreter.
This means that only one thread can be in a state of execution at any point in time. The impact of the GIL isnât visible to developers who execute single-threaded programs, but it can be a performance bottleneck in CPU-bound and multi-threaded code.
Since the GIL allows only one thread to execute at a time even in a multi-threaded architecture with more than one CPU core, the GIL has gained a reputation as an âinfamousâ feature of Python.
**In this article youâll learn how the GIL affects the performance of your Python programs, and how you can mitigate the impact it might have on your code.**
## What Problem Did the GIL Solve for Python?
Python uses reference counting for [memory management](https://realpython.com/python-memory-management/). It means that objects created in Python have a reference count variable that keeps track of the number of references that point to the object. When this count reaches zero, the memory occupied by the object is released.
Letâs take a look at a brief code example to demonstrate how reference counting works:
Python
```
```
In the above example, the reference count for the empty list object `[]` was 3. The list object was referenced by `a`, `b` and the argument passed to `sys.getrefcount()`.
Back to the GIL:
The problem was that this reference count variable needed protection from race conditions where two threads increase or decrease its value simultaneously. If this happens, it can cause either leaked memory that is never released or, even worse, incorrectly release the memory while a reference to that object still exists. This can cause crashes or other âweirdâ bugs in your Python programs.
This reference count variable can be kept safe by adding *locks* to all data structures that are shared across threads so that they are not modified inconsistently.
But adding a lock to each object or groups of objects means multiple locks will exist which can cause another problemâDeadlocks (deadlocks can only happen if there is more than one lock). Another side effect would be decreased performance caused by the repeated acquisition and release of locks.
The GIL is a single lock on the interpreter itself which adds a rule that execution of any Python bytecode requires acquiring the interpreter lock. This prevents deadlocks (as there is only one lock) and doesnât introduce much performance overhead. But it effectively makes any CPU-bound Python program single-threaded.
The GIL, although used by interpreters for other languages like Ruby, is not the only solution to this problem. Some languages avoid the requirement of a GIL for thread-safe memory management by using approaches other than reference counting, such as garbage collection.
On the other hand, this means that those languages often have to compensate for the loss of single threaded performance benefits of a GIL by adding other performance boosting features like JIT compilers.
[Remove ads](https://realpython.com/account/join/)
## Why Was the GIL Chosen as the Solution?
So, why was an approach that is seemingly so obstructing used in Python? Was it a bad decision by the developers of Python?
Well, in the [words of Larry Hastings](https://youtu.be/KVKufdTphKs?t=12m11s), the design decision of the GIL is one of the things that made Python as popular as it is today.
Python has been around since the days when operating systems did not have a concept of threads. Python was designed to be easy-to-use in order to make development quicker and more and more developers started using it.
A lot of extensions were being written for the existing C libraries whose features were needed in Python. To prevent inconsistent changes, these C extensions required a thread-safe memory management which the GIL provided.
The GIL is simple to implement and was easily added to Python. It provides a performance increase to single-threaded programs as only one lock needs to be managed.
C libraries that were not thread-safe became easier to integrate. And these C extensions became one of the reasons why Python was readily adopted by different communities.
As you can see, the GIL was a pragmatic solution to a difficult problem that the [CPython](https://realpython.com/cpython-source-code-guide/) developers faced early on in Pythonâs life.
## The Impact on Multi-Threaded Python Programs
When you look at a typical Python programâor any computer program for that matterâthereâs a difference between those that are CPU-bound in their performance and those that are I/O-bound.
CPU-bound programs are those that are pushing the CPU to its limit. This includes programs that do mathematical computations like matrix multiplications, searching, image processing, etc.
I/O-bound programs are the ones that spend time waiting for [Input/Output](https://realpython.com/python-input-output/) which can come from a user, file, database, network, etc. I/O-bound programs sometimes have to wait for a significant amount of time till they get what they need from the source due to the fact that the source may need to do its own processing before the input/output is ready, for example, a user thinking about what to enter into an input prompt or a database query running in its own process.
Letâs have a look at a simple CPU-bound program that performs a countdown:
Python `single_threaded.py`
```
```
Running this code on my system with 4 cores gave the following output:
Shell
```
```
Now I modified the code a bit to do to the same countdown using two threads in parallel:
Python `multi_threaded.py`
```
```
And when I ran it again:
Shell
```
```
As you can see, both versions take almost same amount of time to finish. In the multi-threaded version the GIL prevented the CPU-bound threads from executing in parallel.
The GIL does not have much impact on the performance of I/O-bound multi-threaded programs as the lock is shared between threads while they are waiting for I/O.
But a program whose threads are entirely CPU-bound, e.g., a program that processes an image in parts using threads, would not only become single threaded due to the lock but will also see an increase in execution time, as seen in the above example, in comparison to a scenario where it was written to be entirely single-threaded.
This increase is the result of acquire and release overheads added by the lock.
[Remove ads](https://realpython.com/account/join/)
## Why Hasnât the GIL Been Removed Yet?
The developers of Python receive a lot of complaints regarding this but a language as popular as Python cannot bring a change as significant as the removal of GIL without causing backward incompatibility issues.
The GIL can obviously be removed and this has been done multiple times in the past by the developers and researchers but all those attempts broke the existing C extensions which depend heavily on the solution that the GIL provides.
Of course, there are other solutions to the problem that the GIL solves but some of them decrease the performance of single-threaded and multi-threaded I/O-bound programs and some of them are just too difficult. After all, you wouldnât want your existing Python programs to run slower after a new version comes out, right?
The creator and BDFL of Python, Guido van Rossum, gave an answer to the community in September 2007 in his article [âIt isnât Easy to remove the GILâ](https://www.artima.com/weblogs/viewpost.jsp?thread=214235):
> âIâd welcome a set of patches into Py3k *only if* the performance for a single-threaded program (and for a multi-threaded but I/O-bound program) *does not decrease*â
And this condition hasnât been fulfilled by any of the attempts made since.
## Why Wasnât It Removed in Python 3?
Python 3 did have a chance to start a lot of features from scratch and in the process, broke some of the existing C extensions which then required changes to be updated and ported to work with Python 3. This was the reason why the early versions of Python 3 saw slower adoption by the community.
But why wasnât GIL removed alongside?
Removing the GIL would have made Python 3 slower in comparison to Python 2 in single-threaded performance and you can imagine what that would have resulted in. You canât argue with the single-threaded performance benefits of the GIL. So the result is that Python 3 still has the GIL.
But Python 3 did bring a major improvement to the existing GILâ
We discussed the impact of GIL on âonly CPU-boundâ and âonly I/O-boundâ multi-threaded programs but what about the programs where some threads are I/O-bound and some are CPU-bound?
In such programs, Pythonâs GIL was known to starve the I/O-bound threads by not giving them a chance to acquire the GIL from CPU-bound threads.
This was because of a mechanism built into Python that forced threads to release the GIL **after a fixed interval** of continuous use and if nobody else acquired the GIL, the same thread could continue its use.
Python
```
```
The problem in this mechanism was that most of the time the CPU-bound thread would reacquire the GIL itself before other threads could acquire it. This was researched by David Beazley and visualizations can be found [here](http://www.dabeaz.com/blog/2010/01/python-gil-visualized.html).
This problem was fixed in Python 3.2 in 2009 by Antoine Pitrou who [added a mechanism](https://mail.python.org/pipermail/python-dev/2009-October/093321.html) of looking at the number of GIL acquisition requests by other threads that got dropped and not allowing the current thread to reacquire GIL before other threads got a chance to run.
## How to Deal With Pythonâs GIL
If the GIL is causing you problems, here a few approaches you can try:
**Multi-processing vs multi-threading:** The most popular way is to use a multi-processing approach where you use multiple processes instead of threads. Each Python process gets its own Python interpreter and memory space so the GIL wonât be a problem. Python has a [`multiprocessing`](https://docs.python.org/2/library/multiprocessing.html) module which lets us create processes easily like this:
Python `multiprocess.py`
```
```
Running this on my system gave this output:
Shell
```
```
A decent performance increase compared to the multi-threaded version, right?
The time didnât drop to half of what we saw above because process management has its own overheads. Multiple processes are heavier than multiple threads, so, keep in mind that this could become a scaling bottleneck.
**Alternative Python interpreters:** Python has multiple interpreter implementations. CPython, Jython, IronPython and [PyPy](https://realpython.com/pypy-faster-python/), written in [C](https://realpython.com/c-for-python-programmers/), [Java](https://realpython.com/oop-in-python-vs-java/), C\# and Python respectively, are the most popular ones. GIL exists only in the original Python implementation that is CPython. If your program, with its libraries, is available for one of the other implementations then you can try them out as well.
**Just wait it out:** While many Python users take advantage of the single-threaded performance benefits of GIL. The multi-threading programmers donât have to fret as some of the brightest minds in the Python community are working to remove the GIL from CPython. One such attempt is known as the [Gilectomy](https://github.com/larryhastings/gilectomy).
The Python GIL is often regarded as a mysterious and difficult topic. But keep in mind that as a Pythonista youâre usually only affected by it if you are writing C extensions or if youâre using CPU-bound multi-threading in your programs.
In that case, this article should give you everything you need to understand what the GIL is and how to deal with it in your own projects. And if you want to understand the low-level inner workings of GIL, Iâd recommend you watch the [Understanding the Python GIL](https://youtu.be/Obt-vMVdM8s) talk by David Beazley.
***Take the Quiz:*** Test your knowledge with our interactive âWhat Is the Python Global Interpreter Lock (GIL)?â quiz. Youâll receive a score upon completion to help you track your learning progress:
***
[](https://realpython.com/quizzes/python-gil/)
**Interactive Quiz**
[What Is the Python Global Interpreter Lock (GIL)?](https://realpython.com/quizzes/python-gil/)
Test your knowledge of Python's Global Interpreter Lock (GIL), how it affects multi-threaded programs, and ways to work around it.
Mark as Completed
Share
Recommended Course
[Understanding Python's Global Interpreter Lock (GIL)](https://realpython.com/courses/understanding-global-interpreter-lock-gil/) (39m)
đ Python Tricks đ
Get a short & sweet **Python Trick** delivered to your inbox every couple of days. No spam ever. Unsubscribe any time. Curated by the Real Python team.

About **Abhinav Ajitsaria**
[ ](https://realpython.com/team/aajitsaria/)
Abhinav is a Software Engineer from India. He loves to talk about system design, machine learning, AWS and of course, Python.
[» More about Abhinav](https://realpython.com/team/aajitsaria/)
***
*Each tutorial at Real Python is created by a team of developers so that it meets our high quality standards. The team members who worked on this tutorial are:*
[](https://realpython.com/team/asantos/)
[Aldren](https://realpython.com/team/asantos/)
[](https://realpython.com/team/dbader/)
[Dan](https://realpython.com/team/dbader/)
Master Real-World Python Skills With Unlimited Access to Real Python

**Join us and get access to thousands of tutorials, hands-on video courses, and a community of expert Pythonistas:**
[Level Up Your Python Skills »](https://realpython.com/account/join/?utm_source=rp_article_footer&utm_content=python-gil)
Master Real-World Python Skills
With Unlimited Access to Real Python

**Join us and get access to thousands of tutorials, hands-on video courses, and a community of expert Pythonistas:**
[Level Up Your Python Skills »](https://realpython.com/account/join/?utm_source=rp_article_footer&utm_content=python-gil)
What Do You Think?
**Rate this article:**
[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Frealpython.com%2Fpython-gil%2F)
[Twitter](https://twitter.com/intent/tweet/?text=Interesting%20Python%20article%20on%20%40realpython%3A%20What%20Is%20the%20Python%20Global%20Interpreter%20Lock%20%28GIL%29%3F&url=https%3A%2F%2Frealpython.com%2Fpython-gil%2F)
[Bluesky](https://bsky.app/intent/compose?text=Interesting%20Python%20article%20on%20%40realpython.com%3A%20What%20Is%20the%20Python%20Global%20Interpreter%20Lock%20%28GIL%29%3F%20https%3A%2F%2Frealpython.com%2Fpython-gil%2F)
[Facebook](https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Frealpython.com%2Fpython-gil%2F)
[Email](mailto:?subject=Python%20article%20for%20you&body=What%20Is%20the%20Python%20Global%20Interpreter%20Lock%20%28GIL%29%3F%20on%20Real%20Python%0A%0Ahttps%3A%2F%2Frealpython.com%2Fpython-gil%2F%0A)
Whatâs your \#1 takeaway or favorite thing you learned? How are you going to put your newfound skills to use? Leave a comment below and let us know.
**Commenting Tips:** The most useful comments are those written with the goal of learning from or helping out other students. [Get tips for asking good questions](https://realpython.com/python-beginner-tips/#tip-9-ask-good-questions) and [get answers to common questions in our support portal](https://support.realpython.com/).
***
Looking for a real-time conversation? Visit the [Real Python Community Chat](https://realpython.com/community/) or join the next [âOffice Hoursâ Live Q\&A Session](https://realpython.com/office-hours/). Happy Pythoning\!
Keep Learning
Related Topics: [advanced](https://realpython.com/tutorials/advanced/) [python](https://realpython.com/tutorials/python/)
Related Learning Paths:
- [Concurrency and Async Programming](https://realpython.com/learning-paths/python-concurrency-parallel-programming/?utm_source=realpython&utm_medium=web&utm_campaign=related-learning-path&utm_content=python-gil)
Related Courses:
- [Understanding Python's Global Interpreter Lock (GIL)](https://realpython.com/courses/understanding-global-interpreter-lock-gil/?utm_source=realpython&utm_medium=web&utm_campaign=related-course&utm_content=python-gil)
Related Tutorials:
- [Speed Up Your Python Program With Concurrency](https://realpython.com/python-concurrency/?utm_source=realpython&utm_medium=web&utm_campaign=related-post&utm_content=python-gil)
- [Python's asyncio: A Hands-On Walkthrough](https://realpython.com/async-io-python/?utm_source=realpython&utm_medium=web&utm_campaign=related-post&utm_content=python-gil)
- [An Intro to Threading in Python](https://realpython.com/intro-to-python-threading/?utm_source=realpython&utm_medium=web&utm_campaign=related-post&utm_content=python-gil)
- [Memory Management in Python](https://realpython.com/python-memory-management/?utm_source=realpython&utm_medium=web&utm_campaign=related-post&utm_content=python-gil)
- [Python Thread Safety: Using a Lock and Other Techniques](https://realpython.com/python-thread-lock/?utm_source=realpython&utm_medium=web&utm_campaign=related-post&utm_content=python-gil)
## Keep reading Real Python by creating a free account or signing in:
[](https://realpython.com/account/signup/?intent=continue_reading&utm_source=rp&utm_medium=web&utm_campaign=rwn&utm_content=v1&next=%2Fpython-gil%2F)
[Continue »](https://realpython.com/account/signup/?intent=continue_reading&utm_source=rp&utm_medium=web&utm_campaign=rwn&utm_content=v1&next=%2Fpython-gil%2F)
Already have an account? [Sign-In](https://realpython.com/account/login/?next=/python-gil/)
##### Learn Python
- [Start Here](https://realpython.com/start-here/)
- [Learning Resources](https://realpython.com/search)
- [Code Mentor](https://realpython.com/mentor/)
- [Python Reference](https://realpython.com/ref/)
- [Python Cheat Sheet](https://realpython.com/cheatsheets/python/)
- [Support Center](https://support.realpython.com/)
##### Courses & Paths
- [Learning Paths](https://realpython.com/learning-paths/)
- [Quizzes & Exercises](https://realpython.com/quizzes/)
- [Browse Topics](https://realpython.com/tutorials/all/)
- [Live Courses](https://realpython.com/live/)
- [Books](https://realpython.com/books/)
##### Community
- [Podcast](https://realpython.com/podcasts/rpp/)
- [Newsletter](https://realpython.com/newsletter/)
- [Community Chat](https://realpython.com/community/)
- [Office Hours](https://realpython.com/office-hours/)
- [Learner Stories](https://realpython.com/learner-stories/)
##### Membership
- [Plans & Pricing](https://realpython.com/account/join/)
- [Team Plans](https://realpython.com/account/join-team/)
- [For Business](https://realpython.com/account/join-team/inquiry/)
- [For Schools](https://realpython.com/account/join-team/education-inquiry/)
- [Reviews](https://realpython.com/learner-stories/)
##### Company
- [About Us](https://realpython.com/about/)
- [Team](https://realpython.com/team/)
- [Mission & Values](https://realpython.com/mission/)
- [Editorial Guidelines](https://realpython.com/editorial-guidelines/)
- [Sponsorships](https://realpython.com/sponsorships/)
- [Careers](https://realpython.workable.com/)
- [Press Kit](https://realpython.com/media-kit/)
- [Merch](https://realpython.com/merch)
[Privacy Policy](https://realpython.com/privacy-policy/) â
[Terms of Use](https://realpython.com/terms/) â
[Security](https://realpython.com/security/) â
[Contact](https://realpython.com/contact/)
Happy Pythoning\!
© 2012â2026 DevCademy Media Inc. DBA Real Python. All rights reserved.
REALPYTHONâą is a trademark of DevCademy Media Inc.
[](https://realpython.com/)
 |
| Readable Markdown | by [Abhinav Ajitsaria](https://realpython.com/python-gil/#author) Reading time estimate 11m [advanced](https://realpython.com/tutorials/advanced/) [python](https://realpython.com/tutorials/python/)
The Python Global Interpreter Lock or [GIL](https://wiki.python.org/moin/GlobalInterpreterLock), in simple words, is a mutex (or a lock) that allows only one [thread](https://realpython.com/intro-to-python-threading/) to hold the control of the Python interpreter.
This means that only one thread can be in a state of execution at any point in time. The impact of the GIL isnât visible to developers who execute single-threaded programs, but it can be a performance bottleneck in CPU-bound and multi-threaded code.
Since the GIL allows only one thread to execute at a time even in a multi-threaded architecture with more than one CPU core, the GIL has gained a reputation as an âinfamousâ feature of Python.
**In this article youâll learn how the GIL affects the performance of your Python programs, and how you can mitigate the impact it might have on your code.**
## What Problem Did the GIL Solve for Python?
Python uses reference counting for [memory management](https://realpython.com/python-memory-management/). It means that objects created in Python have a reference count variable that keeps track of the number of references that point to the object. When this count reaches zero, the memory occupied by the object is released.
Letâs take a look at a brief code example to demonstrate how reference counting works:
In the above example, the reference count for the empty list object `[]` was 3. The list object was referenced by `a`, `b` and the argument passed to `sys.getrefcount()`.
Back to the GIL:
The problem was that this reference count variable needed protection from race conditions where two threads increase or decrease its value simultaneously. If this happens, it can cause either leaked memory that is never released or, even worse, incorrectly release the memory while a reference to that object still exists. This can cause crashes or other âweirdâ bugs in your Python programs.
This reference count variable can be kept safe by adding *locks* to all data structures that are shared across threads so that they are not modified inconsistently.
But adding a lock to each object or groups of objects means multiple locks will exist which can cause another problemâDeadlocks (deadlocks can only happen if there is more than one lock). Another side effect would be decreased performance caused by the repeated acquisition and release of locks.
The GIL is a single lock on the interpreter itself which adds a rule that execution of any Python bytecode requires acquiring the interpreter lock. This prevents deadlocks (as there is only one lock) and doesnât introduce much performance overhead. But it effectively makes any CPU-bound Python program single-threaded.
The GIL, although used by interpreters for other languages like Ruby, is not the only solution to this problem. Some languages avoid the requirement of a GIL for thread-safe memory management by using approaches other than reference counting, such as garbage collection.
On the other hand, this means that those languages often have to compensate for the loss of single threaded performance benefits of a GIL by adding other performance boosting features like JIT compilers.
## Why Was the GIL Chosen as the Solution?
So, why was an approach that is seemingly so obstructing used in Python? Was it a bad decision by the developers of Python?
Well, in the [words of Larry Hastings](https://youtu.be/KVKufdTphKs?t=12m11s), the design decision of the GIL is one of the things that made Python as popular as it is today.
Python has been around since the days when operating systems did not have a concept of threads. Python was designed to be easy-to-use in order to make development quicker and more and more developers started using it.
A lot of extensions were being written for the existing C libraries whose features were needed in Python. To prevent inconsistent changes, these C extensions required a thread-safe memory management which the GIL provided.
The GIL is simple to implement and was easily added to Python. It provides a performance increase to single-threaded programs as only one lock needs to be managed.
C libraries that were not thread-safe became easier to integrate. And these C extensions became one of the reasons why Python was readily adopted by different communities.
As you can see, the GIL was a pragmatic solution to a difficult problem that the [CPython](https://realpython.com/cpython-source-code-guide/) developers faced early on in Pythonâs life.
## The Impact on Multi-Threaded Python Programs
When you look at a typical Python programâor any computer program for that matterâthereâs a difference between those that are CPU-bound in their performance and those that are I/O-bound.
CPU-bound programs are those that are pushing the CPU to its limit. This includes programs that do mathematical computations like matrix multiplications, searching, image processing, etc.
I/O-bound programs are the ones that spend time waiting for [Input/Output](https://realpython.com/python-input-output/) which can come from a user, file, database, network, etc. I/O-bound programs sometimes have to wait for a significant amount of time till they get what they need from the source due to the fact that the source may need to do its own processing before the input/output is ready, for example, a user thinking about what to enter into an input prompt or a database query running in its own process.
Letâs have a look at a simple CPU-bound program that performs a countdown:
Running this code on my system with 4 cores gave the following output:
Now I modified the code a bit to do to the same countdown using two threads in parallel:
And when I ran it again:
As you can see, both versions take almost same amount of time to finish. In the multi-threaded version the GIL prevented the CPU-bound threads from executing in parallel.
The GIL does not have much impact on the performance of I/O-bound multi-threaded programs as the lock is shared between threads while they are waiting for I/O.
But a program whose threads are entirely CPU-bound, e.g., a program that processes an image in parts using threads, would not only become single threaded due to the lock but will also see an increase in execution time, as seen in the above example, in comparison to a scenario where it was written to be entirely single-threaded.
This increase is the result of acquire and release overheads added by the lock.
## Why Hasnât the GIL Been Removed Yet?
The developers of Python receive a lot of complaints regarding this but a language as popular as Python cannot bring a change as significant as the removal of GIL without causing backward incompatibility issues.
The GIL can obviously be removed and this has been done multiple times in the past by the developers and researchers but all those attempts broke the existing C extensions which depend heavily on the solution that the GIL provides.
Of course, there are other solutions to the problem that the GIL solves but some of them decrease the performance of single-threaded and multi-threaded I/O-bound programs and some of them are just too difficult. After all, you wouldnât want your existing Python programs to run slower after a new version comes out, right?
The creator and BDFL of Python, Guido van Rossum, gave an answer to the community in September 2007 in his article [âIt isnât Easy to remove the GILâ](https://www.artima.com/weblogs/viewpost.jsp?thread=214235):
> âIâd welcome a set of patches into Py3k *only if* the performance for a single-threaded program (and for a multi-threaded but I/O-bound program) *does not decrease*â
And this condition hasnât been fulfilled by any of the attempts made since.
## Why Wasnât It Removed in Python 3?
Python 3 did have a chance to start a lot of features from scratch and in the process, broke some of the existing C extensions which then required changes to be updated and ported to work with Python 3. This was the reason why the early versions of Python 3 saw slower adoption by the community.
But why wasnât GIL removed alongside?
Removing the GIL would have made Python 3 slower in comparison to Python 2 in single-threaded performance and you can imagine what that would have resulted in. You canât argue with the single-threaded performance benefits of the GIL. So the result is that Python 3 still has the GIL.
But Python 3 did bring a major improvement to the existing GILâ
We discussed the impact of GIL on âonly CPU-boundâ and âonly I/O-boundâ multi-threaded programs but what about the programs where some threads are I/O-bound and some are CPU-bound?
In such programs, Pythonâs GIL was known to starve the I/O-bound threads by not giving them a chance to acquire the GIL from CPU-bound threads.
This was because of a mechanism built into Python that forced threads to release the GIL **after a fixed interval** of continuous use and if nobody else acquired the GIL, the same thread could continue its use.
The problem in this mechanism was that most of the time the CPU-bound thread would reacquire the GIL itself before other threads could acquire it. This was researched by David Beazley and visualizations can be found [here](http://www.dabeaz.com/blog/2010/01/python-gil-visualized.html).
This problem was fixed in Python 3.2 in 2009 by Antoine Pitrou who [added a mechanism](https://mail.python.org/pipermail/python-dev/2009-October/093321.html) of looking at the number of GIL acquisition requests by other threads that got dropped and not allowing the current thread to reacquire GIL before other threads got a chance to run.
## How to Deal With Pythonâs GIL
If the GIL is causing you problems, here a few approaches you can try:
**Multi-processing vs multi-threading:** The most popular way is to use a multi-processing approach where you use multiple processes instead of threads. Each Python process gets its own Python interpreter and memory space so the GIL wonât be a problem. Python has a [`multiprocessing`](https://docs.python.org/2/library/multiprocessing.html) module which lets us create processes easily like this:
Running this on my system gave this output:
A decent performance increase compared to the multi-threaded version, right?
The time didnât drop to half of what we saw above because process management has its own overheads. Multiple processes are heavier than multiple threads, so, keep in mind that this could become a scaling bottleneck.
**Alternative Python interpreters:** Python has multiple interpreter implementations. CPython, Jython, IronPython and [PyPy](https://realpython.com/pypy-faster-python/), written in [C](https://realpython.com/c-for-python-programmers/), [Java](https://realpython.com/oop-in-python-vs-java/), C\# and Python respectively, are the most popular ones. GIL exists only in the original Python implementation that is CPython. If your program, with its libraries, is available for one of the other implementations then you can try them out as well.
**Just wait it out:** While many Python users take advantage of the single-threaded performance benefits of GIL. The multi-threading programmers donât have to fret as some of the brightest minds in the Python community are working to remove the GIL from CPython. One such attempt is known as the [Gilectomy](https://github.com/larryhastings/gilectomy).
The Python GIL is often regarded as a mysterious and difficult topic. But keep in mind that as a Pythonista youâre usually only affected by it if you are writing C extensions or if youâre using CPU-bound multi-threading in your programs.
In that case, this article should give you everything you need to understand what the GIL is and how to deal with it in your own projects. And if you want to understand the low-level inner workings of GIL, Iâd recommend you watch the [Understanding the Python GIL](https://youtu.be/Obt-vMVdM8s) talk by David Beazley.
***Take the Quiz:*** Test your knowledge with our interactive âWhat Is the Python Global Interpreter Lock (GIL)?â quiz. Youâll receive a score upon completion to help you track your learning progress:
***
[](https://realpython.com/quizzes/python-gil/) |
| Shard | 71 (laksa) |
| Root Hash | 13351397557425671 |
| Unparsed URL | com,realpython!/python-gil/ s443 |