Queue.Queue

Question

主たる課題は、データ または他のリソースを共有 調整スレッドです。その目的のために、 スレッドモジュールは、 ロック、イベント、条件変数、 およびセマフォを含む 同期プリミティブの数を提供します。

これらのツールは強力ですが、 という小さなエラーが発生すると、再現が困難な という問題が発生する可能性があります。したがって、 タスク タスクの優先アプローチは、 スレッドのリソースにすべてのアクセスを集中させてから、キューモジュール を使用して、 他のスレッドからの要求でそのスレッドにフィードすることです。 を使用するアプリケーションスレッド間のキューQueue.Queueオブジェクト 通信と調整は、より簡単に設計でき、より読みやすく、 信頼性が高いです。

それは、基本的には、スレッド間通信と調整のためQueue.Queueを使用することを述べて、代わりになど、セマフォ、ロック、などの強力なツールの

私の質問はの欠点何であり、提案された方法？代わりに、より強力なツールを使用する必要があります。その理由は何ですか？

編集

明確にするために、私は、セマフォが何であるかを知っています。私はPythonのドキュメンテーションがなぜ "強力なツール"の代わりにQueue.Queueメソッドを使うことを示唆しているのか不思議に思っていました - 私は単にドキュメント自身の言い回しを使用しています。

Answer 1

私はセマフォとロックを「より強力な方法」と考えているかどうかはわかりません。

キューは、一般に高次の抽象化です。つまり、セマフォとロックを使用してスレッドセーフキューを構築できます。

あなたのアプリケーションに応じて使い分ける場所はどれですか。キューはスレッドとプロセス間で「仕事」を渡すのに適しており、重要なセクションや共有リソースを保護するためにはセマフォ/ロックが適しているため、一度に1つのスレッドしかアクセスできません。

Answer 2

Take a look at the source code for Python's thread-safe queue。キュークラスは、3条件とロック、から正しくという便利な抽象概念を構築します。

私はコーディネートが最も難しい問題ではないと言います。共有状態のマルチスレッドでは、最も難しいのはスレッドが「共有する」ことを妨げることです。スレッドが誤って互いのデータを共有したり、踏ん張りしたりするため、常に非決定論的な振る舞いを見なければなりません。

スレッドをまったく使用しないことをお勧めします。あなたはheisenbugsを追跡するのに十分な時間を費やさなかったと感じるときに、より低いレベルのツールを使用すべきですが、単純なキューを使用して逃げる方法があれば、それを手に入れてください。