Python Memory Management and Tips Transcripts
Chapter: Recovering memory in Python
Lecture: Ref-counting and the GIL

Login or purchase this course to watch this video and the rest of the course contents.
0:00 If you thought about multi-threaded programming or parallel or asynchronous programming in Python, you've surely heard about this thing,
0:07 the "GIL", or the "Global Interpreter Lock", and you often hear this presented as a negative. What this thing does is it
0:14 Only allows a single Python instruction to be executed at any given moment, no matter how many threads you have or how many cores you have,
0:22 none of that, Python instruction one at a time. So that could be very limiting for how parallelism works in Python.
0:31 Now there's a lot of situations where it works awesome, actually I go through it in my asynchronous programming course.
0:36 But things like "I'm waiting on a network connection from a response from a Web service
0:42 or some kind of API I'm calling", that doesn't count is executing a Python statement, that's down somewhere in the OS.
0:48 So if you're waiting on other things, actually the parallelism is great. But for computational stuff where the computational bits are in
0:56 Python, this GIL is a big problem. Actually, Eric Snow and some of the other core developers are working on PEP
1:02 5.5.4 which will create what are called sub interpreters or multiple interpreters that take sort of a
1:09 copy of everything we've talked about and replicate separate, isolated versions and each version can run on a thread
1:15 and it'll potentially solve or alleviate some of these problems by not sharing objects. That's in the future. I have a lot of hope for it.
1:22 It sounds really cool, but I want to just bring up this GIL cause it's
1:26 actually super interesting around what we've just talked about about, not the garbage collection, more the reference counting side of things.
1:33 So let's think about a world without the GIL. We have stuff running. We've got these different references
1:40 to the PyObjects, different pointers that are all pointing back from potentially different threads,
1:46 and they're coming and going, as they do, multi-threaded, right? In parallel. So in that case, you're gonna have to do some kind of thread lock,
1:54 some kind of critical section or muText or something around that piece of data that is the reference count on the PyObject,
2:02 every single one, even things like numbers and strings. You can imagine that's gonna drag down and be super, super, slow
2:12 right? That's a lot of overhead for every single normal operation. So the tradeoff was made that said,
2:17 Well, "let's only let one bit of Python run at a time", in that case, there's no possibility of a race condition around the reference count,
2:25 so we don't have to have thread-locking on it and it'll be much faster. So that's really what the GIL is all about.
2:31 People think of it as like a threading protection thing and it kind of, sort of
2:35 is. But really, what it is, is a reference counting protection mechanism that allows
2:39 Pythons reference counting to be done without thought or care of parallelism or thread safety or
2:46 all those things that are somewhat hard but certainly expensive relative to not doing them,
2:51 and they can just freely work with these objects and because of the way it runs, you're
2:55 never gonna get a race condition on that pointer. That's a global interpreter lock. When I always thought about it,
3:00 when I first heard about, was like "this is a threading thing", and technically yes, but really the most relevant part of it is this has to do
3:08 with reference counting. So it's a Python memory management feature, if you will. Actually, you can read more about it over at Real Python
3:14 Check out the article. They always have a bunch of good articles on this type of stuff, so they've done a really good one
3:20 exploring the Python GIL. You can see the URL at the bottom. If you want to learn even more about it,
3:24 go check it out there, but keep in mind when you hear about the GIL, it's actually there to make reference counting much faster and easier. Yes,
3:33 it's a trade off, but it's an interesting one to consider, and a lot of times, if you're not doing parallelism, you're better off because of it.

Talk Python's Mastodon Michael Kennedy's Mastodon