リソースがビジー状態の場合に限り、スレッドとワーカーキューを生成する

Question

誰かがこれを正しく設計するのを助けることができます。

私のTCPコードでは、ワイヤに書き込もうとするSendMessage（）関数があります。私は、多くの同時リクエストが発生した場合にプロデューサ/コンシューマモデルに移動するようにコールを設計しようとしていますが、（最大のパフォーマンスのために）同時リクエストがない場合は、シングルスレッドのままです。

スレッド間でロックを移動する方法がないため、これを競合条件なしに設計する方法には苦労しています。

私がこれまで持っていることは（擬似コード化された）のようなものです：

SendMessage(msg) { 

    if(Monitor.TryEnter(wirelock,200)) { 

     try{ 
      sendBytes(msg); 
     } 
     finally { 
      Monitor.Exit... 
     } 
    } 
    else { 

    _SomeThreadSafeQueue.add(msg) 

    Monitor.TryEnter(consumerlock,.. 

      Task.Factory.New(ConsumerThreadMethod.... 
    } 
} 


ConsumerThreadMethod() { 

    lock (wirelock) { 

     while(therearemessagesinthequeue) 

       sendBytes... 

    } 

} 

任意の明白な競合状態？

EDIT：最後のものに欠陥が見つかりました。これについてはどうですか？

SendMessage(msg) { 

    if(Monitor.TryEnter(wirelock)) { 

     try{ 
      sendBytes(msg); 
     } 
     finally { 
      Monitor.Exit... 
     } 
    } 
    else { 

     _SomeThreadSafeQueue.add(msg) 

     if (Interlocked.Increment(ref _threadcounter) == 1) 
     { 
      Task.Factory.StartNew(() => ConsumerThreadMethod()); 

     } 
     else 
     { 
      Interlocked.Decrement(ref _threadcounter); 

     }  
    } 
} 


ConsumerThreadMethod() { 

    while(therearemessagesinthequeue) 
      lock (wirelock) { 
       sendBytes... 
      } 
     } 

    Interlocked.Decrement(ref _threadcounter); 
} 

だから、基本的には明らかなレース（必要な場合）のみ、これまで1つのスレッドを生成するための方法として

Answer 1

を連動カウンタを使用していないが、TryEnterは、いくつかの深刻なアイドル時間の原因です。私は実際に消費者スレッドを常に使用することが最良のソリューションだと考えています。少ししかない場合、オーバーヘッドは本当に小さくなります（正しく設計されていれば、消費者スレッドは動作していないときスリープ状態になります）。

コンシューマスレッドでwhileループを使用しているため、送信されたメッセージごとに新しいタスクを作成し、ロックの競合が大きくなりました。

EDIT：ノンブロッキングソケットを使用しているため、単一のコンシューマスレッドですべての送信要求を処理できるだけである必要があります。単一スレッドのスループットは、ネットワークよりも高くなります。より多くのコンシューマーがいる場合は、ミューテックスを使用してすべてをシリアル化せずに、同じソケットで2つのコンシューマー・スレッドが送信されないようにすることは難しいです。私は、シングルスレッドとマルチスレッドの切り替えは良い考えではないと思います。

現在の「マルチスレッド」ソリューションでは、すべての作業が同じミューテックスを使用して保護されているため、パフォーマンスが向上するわけではありません。これは、単一のスレッドよりも遅く、または遅くなります。