Jean-Paul Calderone <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list