method calls in Queue.py is due to backwards compatibility constraints, past over-design and lack of care for providing an efficient solution for this important speed bottleneck issue in inter-thread communication. In fact the heavy usage of an extra mutex and extra method. ) to implement other queue organizations' sub-classing behavior, or when you take care of such things yourself, then a bare deque is a good and efficient deal for high-speed inter-thread communication. So a deque is ~20x faster than Queue (which uses a deque under the hood) and unless you don't need the 'comfortable' synchronization API (blocking / timeout), the strict maxsize obeyance or the 'Override these methods (_put, _get. about dq.extend(mylist): you don't get a guarantee that all elements in mylist are filed in a row when other threads also append elements on the same side - but thats usually not a requirement in inter-thread communication and for the questioned task.

Things like len(dq), dq yield momentary correct values. Here are some benchmark results in seconds using CPython 2.7.3 for inserting and removing 100k items deque 0.0747888759791Īll single-element methods on deque are atomic and thread-safe. However, it seems that deque has a significant efficiency advantage.

deque does not block on pop() or popleft() so you can't base your consumer thread flow on blocking till a new item arrives.

Other operations on deque might not be thread safe, I'm not sure.

deque.append() and deque.popleft() are thread-safe.

Queue.put() and Queue.get() are thread-safe.

If all you're looking for is a thread-safe way to transfer objects between threads, then both would work (both for FIFO and LIFO).

Python queue collections