Queue.Queue vs. collections.deque

Necesito una cola en la que múltiples hilos puedan poner cosas, y múltiples hilos pueden leer.

Python tiene al menos dos clases de cola, Queue.Queue y collections.deque, y la primera aparentemente usa la segunda internamente. Ambos afirman ser seguros para subprocesos en la documentación.

Sin embargo, los documentos de la cola también indican:

collections.deque es una implementación alternativa de colas ilimitadas con operaciones rápidas atómica append () y popleft () que no requieren bloqueo.

Lo que supongo que no entiendo del todo: ¿significa esto que deque no es completamente seguro para subprocesos después de todo?

Si es así, es posible que no entienda completamente la diferencia entre las dos clases. Puedo ver que Queue agrega funcionalidad de bloqueo. Por otro lado, pierde algunas características antiguas como el soporte para el operador interno.

Acceder al objeto de deque interno directamente, es

x en Queue (). deque

¿a salvo de amenazas?

Además, ¿por qué Queue emplea un mutex para sus operaciones cuando deque ya es seguro para subprocesos?

Queue.Queuey collections.dequesirven para diferentes propósitos. Queue.Queue está destinado a permitir que diferentes hilos se comuniquen usando mensajes / datos en cola, mientras collections.dequeque simplemente está pensado como una estructura de datos. Es por eso que Queue.Queuetiene como métodos put_nowait(), get_nowait()y join(), mientras que collections.dequeno lo hace. Queue.Queueno está destinado a ser utilizado como una colección, por lo que carece de los gustos del inoperador.

Se reduce a esto: si tiene múltiples hilos y desea que puedan comunicarse sin la necesidad de bloqueos, está buscando Queue.Queue; si solo desea una cola o una cola de doble extremo como estructura de datos, use collections.deque.

Finalmente, acceder y manipular la deque interna de un Queue.Queuejuego es jugar con fuego, realmente no quieres estar haciendo eso.

Si todo lo que está buscando es una forma segura de subprocesos para transferir objetos entre subprocesos , entonces ambos funcionarían (tanto para FIFO como para LIFO). Para FIFO:

• Queue.put()y Queue.get()son seguros para subprocesos
• deque.append()y deque.popleft()son seguros para subprocesos

Nota:

• Es posible que otras operaciones dequeno sean seguras para subprocesos, no estoy seguro.
• dequeno se bloquea pop()o popleft()no puede basar su flujo de hilo de consumidor en el bloqueo hasta que llegue un nuevo artículo.

Sin embargo, parece que deque tiene una ventaja de eficiencia significativa . Estos son algunos resultados de referencia en segundos utilizando CPython 2.7.3 para insertar y eliminar elementos de 100k

deque 0.0747888759791
Queue 1.60079066852

Aquí está el código de referencia:

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 obtener información, hay un ticket de Python al que se hace referencia para deque thread-safety ( https://bugs.python.org/issue15329 ). Título "aclarar qué métodos de extracción son seguros para subprocesos"

En pocas palabras aquí: https://bugs.python.org/issue15329#msg199368

Las operaciones append (), appendleft (), pop (), popleft () y len (d) de la deque son seguras para subprocesos en CPython. Los métodos de agregar tienen un DECREF al final (para los casos en que se ha configurado maxlen), pero esto sucede después de que se hayan realizado todas las actualizaciones de la estructura y se hayan restaurado los invariantes, por lo que está bien tratar estas operaciones como atómicas.

De todos modos, si no está 100% seguro y prefiere la confiabilidad sobre el rendimiento, simplemente coloque un bloqueo similar;)

Todos los métodos de un solo elemento dequeson atómicos y seguros para subprocesos. Todos los demás métodos también son seguros para subprocesos. Cosas como len(dq), dq[4]producen valores correctos momentáneos. Pero piense, por ejemplo dq.extend(mylist): no se garantiza que todos los elementos mylistse archiven en una fila cuando otros hilos también agregan elementos en el mismo lado, pero eso generalmente no es un requisito en la comunicación entre hilos y para la tarea cuestionada.

Por lo tanto, a dequees ~ 20 veces más rápido que Queue(que usa un dequeoculto) y, a menos que no necesite la API de sincronización "cómoda" (bloqueo / tiempo de espera), la estricta maxsizeobediencia o la "Anulación de estos métodos (_put, _get, .. ) para implementar el comportamiento de subclasificación de otras organizaciones de colas , o cuando usted se ocupa de esas cosas usted mismo, entonces un simple dequees un trato bueno y eficiente para la comunicación entre subprocesos de alta velocidad.

De hecho, el uso intensivo de un mutex adicional y un método adicional, ._get()etc., Queue.pyse debe a restricciones de compatibilidad con versiones anteriores, sobre diseño pasado y falta de cuidado para proporcionar una solución eficiente para este importante problema de cuello de botella de velocidad en la comunicación entre subprocesos. Se utilizó una lista en versiones anteriores de Python, pero incluso list.append () /. Pop (0) era y es atómica y segura para subprocesos ...

Sumar notify_all()a cada uno deque appendy popleftda como resultado resultados mucho peores dequeque la mejora 20x lograda por el dequecomportamiento predeterminado :

deque + notify_all: 0.469802
Queue:              0.667279

@Jonathan modifica un poco su código y obtengo el punto de referencia usando cPython 3.6.2 y agrego la condición en el bucle deque para simular el comportamiento de Queue do.

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)

Y parece que el rendimiento está limitado por esta función condition.notify_all()

collections.deque es una implementación alternativa de colas ilimitadas con operaciones atómicas rápidas de append () y popleft () que no requieren bloqueo. docs Queue

dequees seguro para subprocesos. "operaciones que no requieren bloqueo" significa que no tiene que hacer el bloqueo usted mismo, dequese encarga de ello.

Echando un vistazo a la Queuefuente, se llama a la deque interna self.queuey utiliza un mutex para accesores y mutaciones, por Queue().queuelo que no es seguro para usar en subprocesos.

Si está buscando un operador "in", una deque o cola posiblemente no sea la estructura de datos más adecuada para su problema.

(parece que no tengo reputación para comentar ...) Debes tener cuidado con los métodos de deque que utilizas de diferentes hilos.

deque.get () parece ser seguro para subprocesos, pero he encontrado que hacer

for item in a_deque:
   process(item)

puede fallar si otro hilo está agregando elementos al mismo tiempo. Obtuve una RuntimeException que se quejaba de "mutar deque durante la iteración".

Consulte collectionsmodule.c para ver qué operaciones se ven afectadas por esto