[IronPython] IronPython cs Cpython wrt GIL
jim at ironpython.com
Wed Oct 13 05:36:40 CEST 2004
Nicolas Lehuen wrote:
> There has been yet another thread on the Global Interpreter Lock found in
> Cpython on comp.lang.python. Is there any such "annoyance" in IronPython
> (and, come to think of it, Jython) ? If not, I guess it would be a big
> advantage of IronPython (or Jython) vs CPython on multi-CPU or
> hyperthreading CPUs ?
IronPython has no GIL today and it's unlikely that it will ever have one.
This could be useful for running multi-threaded Python programs. The
IronPython core itself should be mostly thread-safe; however, that hasn't
been tested so there are almost certainly some issues there. I have full
confidence that the IronPython core functionality will have no difficulty
becoming fully thread safe as it moves to 1.0.
My area of concern is around the standard objects. IronPython lists and
dictionaries are not currently thread-safe. This is in line with the CLR
collection APIs that assume the developer using lists and dictionaries will
handle any needed synchronization. However, because of Python's GIL, Python
lists and dictionaries behave as if they are thread-safe to the Python
programmer. For compatibility with multi-threaded Python programs,
IronPython will probably need to use thread-safe lists and dicts for these
standard Python objects and this will impose some small but noticeable
performance overhead. I'd like to come up with a more clever solution to
this dilemma so that synchronization overhead is only imposed when it's
truly needed, but I can't come up with a solution that wouldn't inflict
undue compatibility burdens on Python devs.
More information about the Ironpython-users