[IronPython] IronPython cs Cpython wrt GIL

[Andy Sy]

Nicolas Lehuen wrote:

>>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.
>
> I'm not sure that lists and dictionaries behave as if they are thread-safe.
> What's sure is that a lot of Python developer act as if they are ;). I've
> joined a recent comp.lang.python thread where I ranted about the
> quasi-prehistoric thread support in Python, quite representative of the fact
> that a lot of Python developer don't worry about locking issues (as an
> illustration, a very core tool such as a reentrant lock is still implemented
> in pure Python, see threading.Rlock ; this should definitely be implemented
> in C).

If I recall correctly from when I used them last in a threaded
program, lists and dicts are indeed NOT thread-safe and is
exactly why a Queue module is present.


-- 
reply-to: a n d y @ n e t f x p h . c o m

Lobbying for reply-to munging...