On Sat, Feb 11, 2012 at 1:30 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Masklinn, 10.02.2012 16:12:
On 2012-02-10, at 15:59 , Stefan Behnel wrote:
GIL + Threads = Simplified, non parallel interpreter
Note that this also applies to PyPy, so even "interpreter" isn't enough of a generalisation.
I think it's best to speak of the GIL as what it is: a lock that protects internal state of the CPython runtime (and also some external code, when used that way). Rather convenient, if you ask me.
It is very convenient from the viewpoint of implementing the interpreter, but you must acknowledge that it comes with quite severe limitations on the ability of user code to take advantage of computing resources.
I don't think it does. See my other post just now in response to Massimo.
Armin Rigo's series on Software Transactional Memory on the PyPy blog is also required reading for anyone seriously interested in practical shared memory concurrency that doesn't impose a horrendous maintenance burden on developers that try to use it: http://morepypy.blogspot.com.au/2011/06/global-interpreter-lock-or-how-to-ki... http://morepypy.blogspot.com.au/2011/08/we-need-software-transactional-memor... http://morepypy.blogspot.com.au/2012/01/transactional-memory-ii.html And for those that may be inclined to dismiss STM as pie-in-the-sky stuff that is never going to be practical in the "real world", the best I can offer is Intel's plans to bake an initial attempt at it into a consumer grade chip within the next couple of years: http://arstechnica.com/business/news/2012/02/transactional-memory-going-main... I do like Armin's analogy that free threading is to concurrency as malloc() and free() are to memory management :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia