Using python as primary language
hniksic at xemacs.org
Fri Nov 9 10:37:15 CET 2007
"Martin Vilcans" <martin at librador.com> writes:
>> If by 'this' you mean the global interpreter lock, yes, there are good
>> technical reasons. All attempts so far to remove it have resulted in an
>> interpeter that is substantially slower on a single processor.
> Is there any good technical reason that CPython doesn't use the GIL
> on single CPU systems and other locking mechanisms on multi-CPU
It's not the locking mechanism itself that is slow, what's slow is the
Python you get when you remove it. By removing the GIL you grant
different threads concurrent access to a number of shared resources.
Removing the global lock requires protecting those shared resources
with a large number of smaller locks. Suddenly each incref and decref
(at the C level) must acquire a lock, every dict operation must be
locked (dicts are used to implement namespaces and in many other
places), every access to a global (module) variable must be locked, a
number of optimizations that involve using global objects must be
removed, and so on. Each of those changes would slow down Python;
combined, they grind it to a halt.
More information about the Python-list