0

マルチスレッドで C++ で記述された Linux サーバー アプリケーションを保守しています。約 10 個のモジュールがあり、メッセージを渡す目的でそこに数十個の std::deques があります。アプリケーションは Producer-Consumer パターンを使用して、モジュール間でネットワーク パケットを渡します。

Producer-Consumer デザイン パターンは多くの状況でうまく機能しますが、私たちのアプリケーションには適していないと思います。以下の疑似コードのフロー チャットを参照してください。

   CSocketModule (for receiving and sending packets)
   CSockMod::ReceivePackWorkerThread --> CSockMod::Inque -->                    
   CSockMod::InqueWorkerThread --> CSomeMod::Inque -->
   CSomeMod::InqueWorkerThread --> Generates Response Packets -->
   CSomeMod::Outque --> CSomeMod::OutqueWorkThread --> //Optional
   CSockMod::Outque --> CSockMod::SendPackWorkerThread --> 
   Linux Kernel::TCP/UDP Layer

   For each module, there would be two std::deques for buffering 
   in/out pakets, two working threads for processing incoming and 
   outgoing packets respectively.

ほとんどすべての Inque と Outque は、実行時に 3 つ以上のスレッドによってアクセスされるため、これらのキューを同期するには、多くの pthread_mutex_locks が必要です。ただし、これらのロックにより、アプリケーションはシングル スレッド ソフトウェアのように動作します。サーバー アプリケーションとして、これは受け入れられない可能性があります。

一方、CSomeMod::Inque に 1000 個のパケットがあり、1000 番目のパケットがクライアントからの制御パケットである場合、クライアントは、CSomeMod::InqueWorkerThread が Inque で 999 個のパケットを処理するまで待機する必要があります。コマンドの制御が大幅に遅れる可能性があります。

では、Producer-Consumer パターンは私たちのアプリケーションには適していないのでしょうか? それとも、ここでこのパターンを使用することに誤解がありますか? 助けていただければ幸いです、ありがとう！

スティーブ

4

1 に答える 1

0

懸念事項に直接対処するために試すことができる 2 つの簡単な方法:

  1. std::deques と pthread_mutexes を、次のようなシングル プロデューサー、シングル コンシューマーのロックフリー キューに置き換えます。これ: http://www.boost.org/doc/libs/1_53_0/boost/lockfree/spsc_queue.hpp
  2. 必要に応じて、優先度の高いアイテム用に追加のキューを作成します。常にこれらのキューを最初に確認してください。

現在、これが実際に問題であるかどうかについては言及していません。いずれにせよ、プロフィール、プロフィール、プロフィール。

于 2013-06-02T09:31:26.313 に答える