On Tue, Jul 27, 2010 at 08:27, Evan Cofsky <evan@theunixman.com> wrote:
On 07/26 22:09, Kevin Ar18 wrote:
Are there detailed docs on why the Python GIL exists?
Here is the page from the Python Wiki:
To keep it short, CPython uses refcounting, and without the GIL the refcount incs and decs would need to be atomic, with a huge performance impact (that's discussed in the below links). However, you can look at this answer from Guido van Rossum: http://www.artima.com/weblogs/viewpost.jsp?thread=214235 And these two attempts to remove the GIL: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Global_Interpreter... http://code.google.com/p/python-safethread/ PyPy does not have this problem, but you still need to make thread-safe the dictionaries holding members of each object. You don't need to make lists thread-safe, I think, because the programmer is supposed to lock them, but you want to allow a thread to add a member to an object while another thread performs a method call. Anyway, all this just explains why the GIL is still there, which is a slightly different question from the original one. With state-of-the-art technology, it is bad on every front, except simplicity of implementation.
And here is an interesting article on the GIL problem:
Given that processor frequencies aren't going to increase a lot in the future as they used to do, while the number of cores is going to increase much more, this article seems outdated nowadays - see also http://atlee.ca/blog/2006/06/27/python-warts-2/. This other link (http://poshmodule.sourceforge.net/) used to be interesting for the problem you are discussing, but seems also dead - there are other modules here: http://wiki.python.org/moin/ParallelProcessing. Best regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/