Queue.Queue vs. collections.deque

Question

J'ai besoin d'une file d'attente dans laquelle plusieurs threads peuvent mettre des choses, et dans laquelle plusieurs threads peuvent lire.

Python possède au moins deux classes de files d'attente, Queue.Queue y collections.deque Le premier semble utiliser le second en interne. Les deux prétendent être thread-safe dans la documentation.

Cependant, la documentation sur les files d'attente indique également :

collections.deque est une implémentation alternative implémentation de files d'attente non limitées avec des opérations atomiques rapides de type append() et popleft() rapides et atomiques qui ne ne nécessitent pas de verrouillage.

Ce que je ne comprends pas très bien : Est-ce que cela signifie que deque n'est pas totalement thread-safe après tout ?

Si c'est le cas, je ne comprends peut-être pas bien la différence entre les deux classes. Je peux voir que Queue ajoute une fonctionnalité de blocage. D'un autre côté, elle perd certaines fonctionnalités deque comme le support de l'in-operator.

Accéder directement à l'objet interne deque, c'est

x dans Queue().deque

thread-safe ?

Aussi, pourquoi Queue utilise-t-il un mutex pour ses opérations alors que deque est déjà thread-safe ?

Answer 1

deque est à l'abri des fils. Les "opérations qui ne nécessitent pas de verrouillage" signifient que vous n'avez pas besoin d'effectuer le verrouillage vous-même, l'option deque s'en occupe.

En regardant le Queue la source interne deque est appelée self.queue et utilise un mutex pour les accesseurs et les mutations, donc Queue().queue es no à utiliser sans risque pour les fils.

Si vous cherchez un opérateur "in", alors une deque ou une queue n'est peut-être pas la structure de données la plus appropriée pour votre problème.

Answer 2

(il semble que je n'aie pas la réputation de commenter...) Vous devez faire attention aux méthodes du deque que vous utilisez à partir de différents threads.

deque.get() semble être threadsafe, mais j'ai trouvé que faire

for item in a_deque:
   process(item)

peut échouer si un autre thread ajoute des éléments en même temps. J'ai obtenu une RuntimeException qui se plaignait de "deque mutated during iteration".

Vérifiez collectionmodule.c pour voir quelles opérations sont affectées par cette