Jean-Paul Calderone schrieb: > On 10 May 2007 05:45:24 -0700, [EMAIL PROTECTED] wrote: >> Hi, >> >> please consider the following code: >> >> >> from __future__ import with_statement >> >> class safe_dict(dict): >> def __init__(self, *args, **kw): >> self.lock = threading.Lock() >> dict.__init__(self, *args, **kw) >> def __getitem__(self, key): >> with self.lock: >> return dict.__getitem__(self, key) >> def __setitem__(self, key, value): >> with self.lock: >> dict.__setitem__(self, key, value) >> def __delitem__(self, key): >> with self.lock: >> dict.__delitem__(self, key) >> >> >> - would I need to override another methods e.g. update() or items() in >> order to remain thread-safe or is this enough? >> - 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.
Technically - yes. But you should mention that the reason for that is the GIL, which essentially ensures that python as whole is threadsafe on the level of assignments, collection manipulation and so forth. At the cost of not being able to have real concurrent threads except for C-code that explicitly releases the GIL. Diez -- http://mail.python.org/mailman/listinfo/python-list
