Adding a Par construct to Python?
pavlovevidence at gmail.com
Tue May 19 04:31:06 CEST 2009
On May 18, 1:52 pm, jer... at martinfamily.freeserve.co.uk wrote:
> As I understand it the reason for the GIL is to prevent problems with
> garbage collection in multi-threaded applications.
Not really. It's main purpose to prevent context switches from
happening in the middle of some C code (essentially it makes all C
code a "critical" section, except when the C code explicitly releases
the GIL). This tremendously simplifies the task of writing extension
modules, not to mention the Python core.
> Without it the
> reference count method is prone to race conditions. However it seems
> like a fairly crude mechanism to solve this problem. Individual
> semaphores could be used for each object reference counter, as in
Java doesn't use reference counting.
Individual locks on the refcounts would be prohibitively expensive in
Python, a cost that Java doesn't have.
Even if you decided to accept the penalty and add locking to
refcounts, you still have to be prepared for context switching at any
time when writing C code, which means in practice you have to lock any
object that's being accessed--that's in addition to the refcount lock.
I am not disagreeing with your assessment in general, it would be
great if Python were better able to take advantage of multiple cores,
but it's not as simple a thing as you're making it out to be.
More information about the Python-list