Queue.Queue vs. collections.deque

Preciso de uma fila na qual vários threads possam colocar coisas e vários threads possam ler.

O Python possui pelo menos duas classes de fila, Queue.Queue e collections.deque, sendo que o primeiro parece usar o último internamente. Ambos afirmam ser seguros para threads na documentação.

No entanto, os documentos da fila também declaram:

collections.deque é uma implementação alternativa de filas ilimitadas com operações atômicas append () e popleft () rápidas que não requerem bloqueio.

Acho que não entendo bem: isso significa que o deque não é totalmente seguro para threads, afinal?

Se for, posso não entender completamente a diferença entre as duas classes. Percebo que a fila adiciona funcionalidade de bloqueio. Por outro lado, perde alguns recursos de deque, como suporte para o operador.

Acessar o objeto deque interno diretamente, é

x em Queue (). deque

discussão segura?

Além disso, por que o Queue emprega um mutex para suas operações quando o deque já é seguro para threads?

Queue.Queuee collections.dequeservir a propósitos diferentes. O Queue.Queue destina-se a permitir que diferentes threads se comuniquem usando mensagens / dados em fila, ao passo que collections.dequeé simplesmente uma estrutura de dados. É por isso que Queue.Queuetem métodos como put_nowait(), get_nowait()e join(), enquanto collections.dequenão. Queue.Queuenão se destina a ser usado como uma coleção, e é por isso que não possui os gostos do inoperador.

Tudo se resume a isso: se você tem vários threads e deseja que eles possam se comunicar sem a necessidade de bloqueios, está procurando Queue.Queue; se você quiser apenas uma fila ou uma fila dupla como uma estrutura de dados, use collections.deque.

Finalmente, acessar e manipular o deque interno de a Queue.Queueestá brincando com fogo - você realmente não quer fazer isso.

Se tudo que você procura é uma maneira segura de encadear a transferência de objetos entre encadeamentos , ambos funcionam (ambos para FIFO e LIFO). Para FIFO:

• Queue.put()e Queue.get()são seguros para threads
• deque.append()e deque.popleft()são seguros para threads

Nota:

• Outras operações no dequepodem não ser seguras para threads, não tenho certeza.
• dequenão bloqueia pop()ou, popleft()portanto, você não pode basear seu fluxo de encadeamento no bloqueio até que um novo item chegue.

No entanto, parece que o deque tem uma vantagem de eficiência significativa . Aqui estão alguns resultados de benchmark em segundos usando o CPython 2.7.3 para inserir e remover 100k itens

deque 0.0747888759791
Queue 1.60079066852

Aqui está o código de referência:

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

Para obter informações, há um ticket Python referenciado para deque thread-safety ( https://bugs.python.org/issue15329 ). Título "esclarecer quais métodos de deque são seguros para threads"

Bottom line here: https://bugs.python.org/issue15329#msg199368

As operações append (), appendleft (), pop (), popleft () e len (d) do deque são seguras para threads no CPython. Os métodos append possuem um DECREF no final (para casos em que maxlen foi definido), mas isso acontece após todas as atualizações de estrutura terem sido feitas e os invariantes terem sido restaurados, portanto, não há problema em tratar essas operações como atômicas.

De qualquer forma, se você não tem 100% de certeza e prefere confiabilidade ao desempenho, basta colocar um Lock;)

Todos os métodos de elemento único ativados dequesão atômicos e seguros para threads. Todos os outros métodos também são seguros para threads. Coisas como len(dq), dq[4]produzem valores corretos momentâneos. Mas pense, por exemplo dq.extend(mylist): você não tem garantia de que todos os elementos mylistsão arquivados em uma linha quando outros threads também acrescentam elementos do mesmo lado - mas isso geralmente não é um requisito na comunicação entre threads e para a tarefa questionada.

Portanto, a dequeé ~ 20x mais rápido do que Queue(que usa um dequesob o capô) e, a menos que você não precise da API de sincronização "confortável" (bloqueio / tempo limite), a maxsizeobediência estrita ou a "Substituir esses métodos (_put, _get, .. ) para implementar o comportamento de subclasse de outras organizações de filas " , ou quando você cuida dessas coisas sozinho, um negócio simples dequeé bom e eficiente para a comunicação entre threads de alta velocidade.

De fato, o uso intenso de um método extra mutex e extra, ._get()etc., Queue.pyé devido a restrições de compatibilidade com versões anteriores, excesso de design passado e falta de cuidados em fornecer uma solução eficiente para esse importante problema de gargalo de velocidade na comunicação entre threads. Uma lista foi usada em versões mais antigas do Python - mas mesmo list.append () /. Pop (0) era & é atômica e segura para threads ...

Adicionando notify_all()a cada deque appende popleftresulta em muito piores resultados para dequeque a melhoria 20x alcançado por padrão dequede comportamento :

deque + notify_all: 0.469802
Queue:              0.667279

@ Jonathan modifica um pouco seu código e eu recebo o benchmark usando o cPython 3.6.2 e adiciono a condição no loop deque para simular o comportamento da fila.

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)

E parece que o desempenho limitado por esta função condition.notify_all()

collections.deque é uma implementação alternativa de filas ilimitadas com operações atômicas append () e popleft () rápidas que não requerem bloqueio. docs Fila

dequeé seguro para threads. "operações que não exigem bloqueio" significa que você não precisa fazer o bloqueio sozinho, dequeele cuida disso.

Examinando a Queuefonte, o deque interno é chamado self.queuee usa um mutex para acessadores e mutações, portanto, nãoQueue().queue é seguro para uso em threads.

Se você estiver procurando por um operador "in", uma fila ou fila provavelmente não é a estrutura de dados mais apropriada para o seu problema.

(parece que não tenho reputação para comentar ...) Você precisa ter cuidado com quais métodos do deque você usa em diferentes threads.

deque.get () parece ser seguro para threads, mas descobri que fazer

for item in a_deque:
   process(item)

pode falhar se outro segmento estiver adicionando itens ao mesmo tempo. Eu recebi um RuntimeException que reclamou "deque foi alterado durante a iteração".

Verifique collectionsmodule.c para ver quais operações são afetadas por este