[IronPython] IronPython cs Cpython wrt GIL

[Nicolas Lehuen]

> -----Message d'origine-----
> De : users-ironpython.com-bounces at lists.ironpython.com 
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] De 
> la part de Andy Sy
> Envoyé : jeudi 14 octobre 2004 16:38
> À : users-ironpython.com at lists.ironpython.com
> Objet : Re: [IronPython] IronPython cs Cpython wrt GIL
> 

...

> >
> > 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.

Thread safety can have different meanings. Do you mean that if I read/write
concurrently in a dict, I can break it (i.e. put it in a incoherent state,
for example due to two or three rehashing taking place at the same time and
overwriting the hash buckets) ? Or simply that I cannot predict the global
behaviour and that code like this is bound to have surprises :

if mydict.has_key('foo'):
	# oh non, I don't want any foo here
	del mydict['foo']

Two threads can run concurrently this code, so that they both pass the
has_key test and one of the two raises a KeyError since the other has
already removed the foo key.

My guess is that because of the GIL and the way native calls are performed
while the GIL is locked (except when it performs I/O), you cannot "break" a
dict (in the sense given above), as hard as you may try. In that sense, it
is thread-safe. But, the code above is bound to fail if you don't perform
some kind of user-level locking using threading.Lock or threading.Rlock. In
that sense, it is NOT thread-safe. And there is no way it can be thread safe
without the developer paying attention to what (s)he does.

The Queue module is just a list with proper user-level locking to make sure
that you can put() and get() objects in a safe way from different threads.
Have a look at it, it's just a standard list with locking based on
thread.allocate_lock() (which is the low-level object used by threading.Lock
and threading.RLock()). It is not a one-size-fits-all solution to threading
problems, just a handy way to communicate between threads.

Regards,
Nicolas