Is python is fully thread safe

Donn Cave donn at
Wed Jul 28 07:07:48 CEST 2004

Quoth Dave Brueck <dave at>:
| As an aside, I think the documentation wrt to multi-threaded safety 
| could be improved, but I'm not sure how exactly to improve it because 
| "thread safety" doesn't always have a clear definition. For example, two 
| threads can safely access and even modify the same Python object (such 
| as a dictionary) without explicit locking and the interpreter will not 
| crash, so at that low-level you could say it is thread safe. But at the 
| semantic level of your particular application, a function that modifies 
| the same dictionary by multiple threads may or may not need explicit 
| locking around the dictionary modification (depending on what is being 
| done), so at that level the access may not be considered thread safe.
| As to what the Python documentation needs to say (and, in the end, 
| perhaps it already does this well enough), I'd think it needs to make a 
| few things clear:
| 1) Accessing the same Python object from multiple threads from Python 
| code won't corrupt the internals of the interpreter.
| 2) Modules/functions that are just plain not thread-safe should be 
| marked as such (e.g. the fpectl module).
| Beyond that, can you think of anything else? I doubt that the work 
| required to document the low-level thread safety of each and every 
| function is really worth it (not to mention the effort required to keep 
| it up to date over time) - partly because of #1, above, partly because 
| in decent multi-threaded programs there aren't too many shared objects 
| and the points at which they are shared are fairly well-defined, and 
| partly because when in doubt, it's fairly simple to add a mutex around a 
|   resource.

Well, in the anything else category, we can consider the point that
came up in another thread, where Paul Moore pointed out that the
dictionary access that's atomic with core dictionaries is not atomic
for Python instance objects that implement setitem.  I know you can
dismiss that as irrelevant because it doesn't break internal structures,
but at least it underscores the point - we can't really say much more
about thread safety than this, we think the interpreter will survive.
The rest is up to the programmer.

	Donn Cave, donn at

More information about the Python-list mailing list