Larry Hastings - Python's Infamous GIL
Why Stack Overflow recommends it
Stack Overflow users link it when answering how CPython threads, GIL switching and thread locks actually behave, and as a reference for how other implementations such as IronPython cope without a GIL.
Recommended by 1 people across 1 different months, 2015 to 2024.
What it is
A EuroPython 2015 conference talk by CPython core developer Larry Hastings explaining what the Global Interpreter Lock is, its history, the problems it solves and causes, and what removing it would involve. It assumes familiarity with multithreaded programming and includes some C code in the slides.
What people said
Strong rec tipsqueal · 2015-10 · Stack Overflow · on “How does python handle thread locking / context switching?”
Larry Hastings (a core CPython Developer) has a great talk that covers this subject called " Python's Infamous GIL [this video] ". If you skip to 11:40ish he gives the answer to your question. From the talk: The way Python threads work with the GIL is with a simple counter. With every 100 byte codes executed the GIL is supposed to be released by the thread currently executing in order to give other threads a chance to execute code. This behavior is essentially broken in Python 2.7 because of the thread release/acquire mechanism. It has been fixed in Python 3. When you use a thread lock Python will only execute the threads that are not locked. So if you have several threads sharing 1 lock, then on
Cites Tom Chen · 2021-04 · Stack Overflow · on “Python v3 threading and OS context-switching (changed from v2?)”
The machinism of context switch is different between python 2 and 3,python2 do switch after excuted fixed bytecode and python3 do switch after fixed time interval,see [this video]
Cites Saleh · 2024-02 · Stack Overflow · on “IronPython garbage collection - How does it provides compatibility with C-extensions?”
In this part of the talk on GIL by Larry Hastings, there is an explanation about how ironclad [LINK] provides C-extension compatibility with IronPython. This is the interesting part of the talk [this video] : We implemented something called Ironclad which was an implementation of the Python C-API for IronPython and IronPython doesn't have a GIL and it doesn't use reference counting but we maintain binary compatibility with existing binaries. What you have with those existing binaries is you have C objects (effectively python objects implemented in C) that expect to use reference counting so we had a hybrid system. For objects that were returned from the C extension we artificially inflated their