Threading - Why Not Lock Objects Rather than lock the interpreter

[Christopher A. Craig]

michael at foord.net (Fuzzyman) writes:

> Looking at threading code it seems that the Global Interpreter Lock is
> a bit of a 'brute force' way of preventing two threads attempting to
> access sensitive objects simultaneously....
> 
> Why not have a new type of object with a 'lock' facility... if an
> object is locked then any thread trying to access the object other
> than the one obtaining the lock is blocked until the lock is
> released..... rather than blocking *all* threads until one thread has
> finished with the object.....
> 
> It could be implemented as a new attribute of existing objects... or
> new types of objects.....

It would slow down the interpreter drastically.  The important thing
here is that for the above to be true, you'ld need to define
"sensitive objects" to be "objects with a reference count" (i.e. all
of them).  Because of that if you did this you'ld be doing about as
much locking and unlocking as you would code execution.  For example,
calling the following function would require at least 2 lock/unlock
pairs (there may be more, I'm not thinking too hard about it):

def donothing(): pass

-- 
Christopher A. Craig <list-python at ccraig.org>
Code that does not adhere to the documentation is bad code that should
be broken, even if it is your own. -- Christian Tismer