Queue.Queueとcollections.deque

複数のスレッドがデータを入れることができるキューが必要です。複数のスレッドがそこから読み取ることができます。

Pythonには少なくともQueue.Queueとcollections.dequeの2つのキュークラスがあり、前者は後者を内部的に使用しているようです。どちらもドキュメントではスレッドセーフであると主張しています。

ただし、キューのドキュメントにも次のように記載されています。

collections.dequeは、ロックを必要としない高速のアトミックなappend（）およびpopleft（）操作を備えた、無制限のキューの代替実装です。

私はまったく理解していないと思います：これは、結局、dequeが完全にスレッドセーフではないことを意味しますか？

もしそうなら、私は2つのクラスの違いを完全に理解していないかもしれません。Queueがブロッキング機能を追加していることがわかります。一方で、オペレーター内のサポートなど、いくつかの必要な機能が失われます。

内部の両端キューオブジェクトに直接アクセスするのは、

Queue（）。dequeのx

スレッドセーフ？

また、dequeがすでにスレッドセーフであるのに、なぜQueueはその操作にミューテックスを使用するのですか？

Queue.Queuecollections.dequeさまざまな目的を果たします。Queue.Queueは、さまざまなスレッドがキューに入れられたメッセージ/データを使用して通信できるようにすることを目的としていますcollections.dequeが、単にデータ構造として意図されています。だからこそQueue.Queueのようなメソッドを持っているput_nowait()、get_nowait()とjoin()のに対し、collections.dequeしません。Queue.Queueコレクションとして使用することを意図していないため、in演算子のようなものが欠けています。

つまり、複数のスレッドがあり、ロックを必要とせずにスレッドが通信できるようにしたい場合は、を探しQueue.Queueます。データ構造としてキューまたは両端キューが必要な場合は、を使用しますcollections.deque。

最後に、内部の両端キューにアクセスして操作するQueue.Queueことは火で遊んでいます-あなたは本当にそれをしたくありません。

あなたが探しているすべてがスレッド間でオブジェクトを転送するスレッドセーフな方法である場合、両方が機能します（FIFOとLIFOの両方で）。FIFOの場合：

• 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

詳細については、dequeスレッドセーフのために参照されるPythonチケットがあります（https://bugs.python.org/issue15329）。タイトル「どのdequeメソッドがスレッドセーフかを明確にする」

ここでの結論：https : //bugs.python.org/issue15329#msg199368

両端キューのappend（）、appendleft（）、pop（）、popleft（）、およびlen（d）操作は、CPythonではスレッドセーフです。追加メソッドの最後にはDECREFがあります（maxlenが設定されている場合）が、これはすべての構造体の更新が行われ、不変条件が復元された後で発生するため、これらの操作をアトミックとして処理しても問題ありません。

とにかく、100％確実ではなく、パフォーマンスよりも信頼性を好む場合は、ロックのようなものを入れてください;）

のすべての単一要素メソッドはdeque、アトミックでスレッドセーフです。他のすべてのメソッドもスレッドセーフです。のようなものはlen(dq)、dq[4]瞬間的に正しい値をもたらします。しかし、たとえば、他のスレッドも同じ側に要素を追加する場合dq.extend(mylist)、すべての要素mylistが一列に並べられるという保証はありませんが、通常、スレッド間通信や問題のタスクでは必要ありません。

だからdequeである〜20倍速くよりQueue（使用するdequeフードの下）、あなたは「快適」の同期APIを必要としない場合を除き、厳密（タイムアウト/ブロック）maxsizeobeyanceまたは、「これらのメソッドをオーバーライドします（_put、_GETを... ）他のキュー組織のサブクラス化動作を実装する場合、または自分でそのようなことを自分で処理する場合、ベアdequeスレッドは高速スレッド間通信に適した効率的な方法です。

実際、追加のミューテックスや追加のメソッド._get()などのメソッド呼び出しが頻繁に使用されるのは、Queue.py下位互換性の制約、過去の過剰設計、およびスレッド間通信におけるこの重要な速度のボトルネック問題に対する効率的なソリューションを提供するための注意の欠如が原因です。リストは古いバージョンのPythonで使用されていましたが、list.append（）/。pop（0）でもアトミックでスレッドセーフです...

notify_all()それぞれにdeque appendを追加すると、デフォルトの動作で達成される20倍の改善よりもpopleftはるかに悪い結果にdequeなりますdeque。

deque + notify_all: 0.469802
Queue:              0.667279

@ジョナサンは彼のコードを少し修正し、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()

collections.dequeは、ロックを必要としない高速なアトミックなappend（）およびpopleft（）操作を備えた、無制限のキューの代替実装です。 docs Queue

dequeスレッドセーフです。「ロックを必要としない操作」とは、ロックを自分で行う必要がないことを意味しますdeque。

Queueソースを見ると、内部両端キューが呼び出されself.queue、アクセサーとミューテーションにミューテックスを使用しているため、スレッドセーフでQueue().queueはありません。

「in」演算子を探している場合、デキューまたはキューは、問題にとって最も適切なデータ構造ではない可能性があります。

（コメントする評判がないようです...）異なるスレッドから使​​用する両端キューのメソッドに注意する必要があります。

deque.get（）はスレッドセーフであるように見えますが、

for item in a_deque:
   process(item)

別のスレッドが同時に項目を追加している場合、失敗する可能性があります。「反復中にdequeが変更された」と文句を言うRuntimeExceptionを受け取りました。

collectionsmodule.cをチェックして、これによって影響を受ける操作を確認してください