[Python-Dev] Thread safety of deques

Raymond Hettinger python at rcn.com
Mon Jul 19 07:09:00 CEST 2004

[Paul Moore]
> The documentation for the collections.deque type states that "Deques
> support thread-safe, memory efficient appends and pops from either
> side of the deque". I'm not clear what the implication of saying that
> these operations are "thread-safe" is.

It is thread-safe in the same sense as the MersenneTwister's random()
method -- all state is updated in a single step.  This contrasts with
pure python implementations which can be interrupted in the middle of
updating state.

For random number generation, the implication is that two threads can
share the same generator (giving up ability to recreate a sequence)
without worrying about wrecking the generator's internal state.
Likewise, two threads can append or pop from the same deque without
trashing its internal state (of course, that's only a good idea if you
don't care about who appends or pops first).

> To contrast, list.append() does not claim thread safety. 

List operations like most C functions are also atomic.

> This way to the slippery slope... :-)

Yes.  It is clearly possible to twist words into meaningless knots while
talking about threads.  Feel free to submit a clarifying doc patch.  

Try to keep it in proportion.  It would be easy to introduce a rats nest
of discussion about the GIL and whatnot.  While possibly more precise,
it is likely to be a distraction from the surrounding documentation and
make things even less clear to those who have no interest in threads.  

As an alternative, it may be worthwhile to submit a candidate glossary
entry about thread-safety.


More information about the Python-Dev mailing list