"Martin Vilcans" <[EMAIL PROTECTED]> 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 > systems?
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. -- http://mail.python.org/mailman/listinfo/python-list
