Thread-safe dictionary

[Duncan Booth]

Jean-Paul Calderone <exarkun at divmod.com> wrote:

>>- would I need to override another methods e.g. update() or items() in
>>order to remain thread-safe or is this enough?

No, you'll need to protect almost everything. items may be safe. update, 
clear, get, has_key, pop, and setdefault all need a lock in the general 
case.

Also be aware that some Python internals bypass things like __getitem__ in 
dict subclasses, so the lock will be ignored if (for example) you use the 
dict as a namespace for exec.

>>- in __getitem__, does it release the lock after returning the item?
>>- wouldn't it be better to use threading.RLock, mutex, ... instead?
>>
> 
> The builtin dict type is already thread safe.

It very much depends on what you mean by 'thread safe'. Calls to dict 
methods from multiple threads won't result in Python getting into an 
inconsistent state and crashing, but they aren't necessarily atomic either.

In particular, any method which can modify the content of the dictionary 
could release an instance of a class with a __del__ method written in 
Python and other threads will be able to run at that point. 
Likewise any lookup in a dict where a key is an instance of a class with 
user-defined comparison method could allow Python code and therefore other 
threads to run.

Of course if your particular dict objects all use simple types this may not 
matter, but it needs a careful programmer to use an ordinary Python dict 
(or list) safely across threads.

IMHO you are probably best to write a thread-safe class which uses an 
ordinary dict (and has a nicely limited interface) rather than trying to 
produce a completely thread-safe dict type.