Python 3.2 - GIL - good/bad?

python multithreading locking interpreter
JerryK picture JerryK · Aug 2, 2010 · Viewed 12.6k times · Source

Python 3.2 ALPHA is out.

From the Change Log, it appears the GIL has been entirely rewritten.

A few questions:

  1. Is having a GIL good or bad? (and why).
  2. Is the new GIL better? If so, how?

UPDATE:

I'm fairly new to Python. So all of this is new to my but I do at least understand that the existence of a GIL with CPython is a huge deal.

Question though, why does CPython not just clone the interpreter like Perl does in an attempt to remove the need for the GIL?

Answer

phkahler picture phkahler · Aug 2, 2010

The best explanation I've seen as to why the GIL sucks is here:

http://www.dabeaz.com/python/GIL.pdf

And the same guy has a presentation on the new GIL here:

http://www.dabeaz.com/python/NewGIL.pdf

If that's all that's been done it still sucks - just not as bad. Multiple threads will behave better. Multi-core will still do nothing for you with a single python app.

Related questions

What is the difference between Lock and RLock

From the docs: threading.RLock() -- A factory function that returns a new reentrant lock object. A reentrant lock must be released by the thread that acquired it. Once a thread has acquired a reentrant lock, the same thread may …

Read More
Why the Global Interpreter Lock?

What is exactly the function of Python's Global Interpreter Lock? Do other languages that are compiled to bytecode employ a similar mechanism?

Read More
Are locks unnecessary in multi-threaded Python code because of the GIL?

If you are relying on an implementation of Python that has a Global Interpreter Lock (i.e. CPython) and writing multithreaded code, do you really need locks at all? If the GIL doesn't allow multiple instructions to be executed in …

Read More