> >> For example, when one thread do `od[k1] = v1` and another thread do >> `od[k2] = v2`, >> result should be equivalent to one of `od[k1] = v1; od[k2] = v2;` or >> `od[k2] = v2; od[k1] = v1`. And internal data structure should be >> consistent. > > I agree the pure Python OrderedDict is not thread-safe. But who said > it should?
No one. I meant just let's say "it should" from Python 3.7. > And, actually, are you sure the C implementation is? GIL switches can > happen at many points. A simple Py_DECREF, or perhaps even a tuple > allocation can trigger a GC run that may release the GIL at some point > in a finalizer function. > I know such difficulity already. I thought simple (when key is str or int) __setitem__ doesn't break internal state of current C implementation of OrderedDict. And I'll carefully review my code too. >> Sometime, writing reentrant and threadsafe container in C is easier than >> in Pure Python. > > The C and Python versions needn't make exactly the same guarantees. > Yes, of course. But what we can recommend for library developers (including stdlib)? Currently, dict ordering is implementation detail of CPython and PyPy. We don't recommend to rely on the behavior. Like that, should we say "atomic & threadsafe __setitem__ for simple key is implementation detail of CPython and PyPy. We recommend using mutex when using OrderedDict from multiple thread."? That was my point about thread safety. Regards, INADA Naoki <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
