Why GIL? (was Re: what's the point of rpython?)
fakeaddress at nowhere.org
Sat Jan 24 07:55:32 CET 2009
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"
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:
# Class dicts are mutable:
print("I'm still called", self.title)
Jafo.identify = id
# An object's class can change:
dude.__class__ = Bar
# A class's base classes can change:
class Fu (object):
print("Call me", self.title)
Bar.__bases__ = (Fu,)
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.
More information about the Python-list