Why GIL? (was Re: what's the point of rpython?)

[Bryan Olson]

Carl Banks wrote:
> Paul Rubin wrote:
>> Bryan Olson writes:
>>>> BTW, class instances are usually immutable and thus don't require a
>>>> mutex in the system I described.
>>> Then you are describing a language radically different from Python.

>> That one threw me for a minute too, but I think the idea is that the
>> class instance itself is immutable, while its slots (specifically the
>> attribute dictionary) point to mutable objects.
> 
> Correct, and, getting back to the point, an instance itself would not
> require a mutex.  The dict would need it, of course.

The dict is part of the object and some important slots are mutable. 
What's more, if your point was to do away with the GIL without changing 
Python semantics nor requiring heaping masses of locking, I fear you've 
not fully grasped the problem.

Languages such as Java, C++, and C# do not require nearly as much 
locking as Python because they are not nearly as dynamic. Consider how a 
method is invoked. Java / C++ / C# can always resolve the method with no 
locking; the data they need is fixed at link time. Python is much more 
dynamic. A demo:


     from __future__ import print_function

     # A simple class hierarchy:

     class Foo (object):
         title = "Mr. Foo"

         def identify(self):
             print("I'm called", self.title)

     class Bar (Foo):
         title = "Ms. Bar"

     class Jafo (Bar):
         title = "Major Jafo"

     dude = Jafo()


     # Searches 5 dicts to find the function to call:

     dude.identify()


     # Class dicts are mutable:

     def id(self):
         print("I'm still called", self.title)

     Jafo.identify = id
     dude.identify()


     # An object's class can change:

     dude.__class__ = Bar
     dude.identify()


     # A class's base classes can change:

     class Fu (object):
         def identify(self):
             print("Call me", self.title)

     Bar.__bases__ = (Fu,)
     dude.identify()


Result:
 >>>
I'm called Major Jafo
I'm still called Major Jafo
I'm called Ms. Bar
Call me Ms. Bar
 >>>


In that first simple call of dude.identify(), Python looked up "dude" in 
  the module's (mutable) dict to find the object. Then it looked in 
object's (mutable) dict, and did not find "identify". So it looked at 
the object's (mutable) __class__ slot, and in that class's (mutable) 
dict. It still did not find "identify", so it looked in the class's 
(mutable) __bases__ slot, following Python's depth-first "object 
protocol" and thus looking in what other (mutable) class dicts and 
(mutable) __bases__ slots were required.

An object's __dict__ slot is *not* mutable; thus we could gain some 
efficiency by protecting the object and its dict with the same lock. I 
do not see a major win in Mr. Banks' point that we do not need to lock 
the object, just its dict.


-- 
--Bryan