Очередь.Очередь против коллекций.двусторонняя очередь

если все, что вы ищете-это потокобезопасный способ передачи объектов между потоками, тогда оба будут работать (как для FIFO, так и для LIFO). ФИФО:

• Queue.put() и Queue.get() являются потокобезопасными
• deque.append() и deque.popleft() являются потокобезопасными

Примечание:

• прочие операции на deque не может быть потокобезопасным, я не уверен.
• deque не блок pop() или popleft() таким образом, вы не можете основывать поток потока потребителей на блокировке до прибытия нового элемента.

однако, кажется, что deque имеет значительное преимущество эффективности. Вот некоторые результаты тестов в секундах с помощью CPython 2.7.3 для вставки и удаления 100k элементов

deque 0.0747888759791
Queue 1.60079066852

вот контрольный код:

import time
import Queue
import collections

q = collections.deque()
t0 = time.clock()
for i in xrange(100000):
    q.append(1)
for i in xrange(100000):
    q.popleft()
print 'deque', time.clock() - t0

q = Queue.Queue(200000)
t0 = time.clock()
for i in xrange(100000):
    q.put(1)
for i in xrange(100000):
    q.get()
print 'Queue', time.clock() - t0

для информации есть билет Python, на который ссылается deque thread-safety (https://bugs.python.org/issue15329). Название "уточните, какие методы deque являются потокобезопасными"

итог здесь:https://bugs.python.org/issue15329#msg199368

двухсторонняя очередь это функции append(), appendleft(), поп(), popleft () и лен(д) операции потокобезопасны в CPython. Методы append имеют DECREF в конце (для случаев, когда maxlen имеет было установлено), но это происходит после всех обновления структуры и инварианты были восстановлены, поэтому можно обрабатывать эти операции как атомный.

в любом случае, если вы не уверены на 100% и предпочитаете надежность производительности, просто поставьте блокировку ;)

deque является потокобезопасным. "операции, которые не требуют блокировки" означает, что вы не должны делать блокировку самостоятельно,deque позаботится об этом.

на Queue источник, внутренний deque называется self.queue и использует мьютекс для аксессоров и мутаций, так что Queue().queue is не thread-safe для использования.

если вы ищете оператор "in" , то deque или queue, возможно, не самая подходящая структура данных для вашего проблема.

deque 0.469802
Queue 0.667279

@Jonathan немного модифицирует свой код, и я получаю тест с помощью cPython 3.6.2 и добавляю условие в цикл deque для имитации очереди поведения.

import time
from queue import Queue
import threading
import collections

mutex = threading.Lock()
condition = threading.Condition(mutex)
q = collections.deque()
t0 = time.clock()
for i in range(100000):
    with condition:
        q.append(1)
        condition.notify_all()
for _ in range(100000):
    with condition:
        q.popleft()
        condition.notify_all()
print('deque', time.clock() - t0)

q = Queue(200000)
t0 = time.clock()
for _ in range(100000):
    q.put(1)
for _ in range(100000):
    q.get()
print('Queue', time.clock() - t0)

и кажется, что производительность ограничена эта функция condition.notify_all()

сборники.deque-это альтернативная реализация неограниченных очередей с операциями fast atomic append() и popleft (), которые не требуют блокировки. очереди документы

(Кажется, у меня нет репутации, чтобы комментировать...) Вы должны быть осторожны, какие методы deque вы используете из разных потоков.

deque.get () кажется threadsafe, но я обнаружил, что делаю

for item in a_deque:
   process(item)

может произойти сбой, если другой поток добавляет элементы одновременно. Я получил RuntimeException, который жаловался "deque мутировал во время итерации".

Регистрация collectionsmodule.c чтобы увидеть, какие операции будут затронуты этим

все одноэлементные методы на deque атомная и потокобезопасным. Все остальные методы также потокобезопасны. Такие вещи, как len(dq), dq[4] дайте мгновенные правильные значения. Но подумайте, например, о dq.extend(mylist): вы не получаете гарантию того, что все элементы mylist хранятся в строке, когда другие потоки также добавляют элементы на той же стороне - но это обычно не требование в межпотоковой связи и для поставленной задачи.

так deque ~20x быстрее, чем Queue (который использует deque под капотом) и если вам не нужен" удобный " API синхронизации (блокировка / тайм-аут), строгий maxsize подчинение или "переопределить эти методы (_put, запросе, ..) реализовать другие организации очереди" поведение подкласса, или когда вы заботитесь о таких вещах сами, тогда голый deque хорошее и эффективное дело для высокоскоростного сообщения Интер-потока.

на самом деле тяжелое использование дополнительного мьютекса и дополнительный метод ._get() etc. метод вызывает Queue.py из-за ограничений обратной совместимости, прошлого чрезмерного дизайна и отсутствия заботы о предоставлении эффективного решения этой важной проблемы узкого места скорости в межпотоковой связи. Список использовался в более старых версиях Python - но даже список.добавлять./)(pop (0) был и является атомарным и threadsafe ...