私は非同期アプリケーション (私は CCR を使用しています) のトラブルシューティングに関する理論を持っていますが、誰かが私の論理を確認できるかどうか疑問に思っています。
デフォルト数のスレッド (つまり、コアごとに 1 つ) を使用する CCR ベースのマルチスレッド アプリケーションが、指定された 2 倍のスレッドを使用する同じアプリケーションより遅い場合、コードのどこかでスレッドがブロックされていることを意味しますか?
どう思いますか？これは、スレッドが誤ってブロックされているかどうかを検出するための迅速かつ有効な方法ですか?
「遅い」とはどういう意味ですか？
ブロックされたスレッドを自動的に検出する場合は、おそらくそれらのスレッドがハートビートを送信する必要があります。ハートビートは、ある種のモニターによって監視されますが、オプションは限られています。
最小限のスレッドでシステムを流動的に保つために、I/Oを処理するタスクを可能な限り簡潔に保つことがわかりました。I / Oから別のポートにデータを送信するだけで、それ以上の処理は行われません。したがって、データは、可能な限り高速にデータを取得するタスクに干渉することなく、制御された方法で処理するために他の場所にキューに入れられます。考えるべき共有状態がある場合、この処理はインターリーブのExclusiveGroupで発生する可能性があります...そして便利な副作用は、排他的タスクがディスパッチャーのすべてのスレッドを拘束することは決してないということです（ただし、おそらくもっと厄介な方法があると思いますCCR APIでこれを管理する方法）
If this is the case, that means that your threadpool is being exhausted (i.e. you have 2 threads but you've async pended 4 IOs or something) - if your work is heavily IO bound, the rule of "one thread per core" doesn't really apply.
スレッドがブロックされているかどうかを簡単に確認する方法は、ブロックしている可能性のある操作を実行する前に現在のシステム時間を取得し、次に操作を実行して、経過した時間を確認することです。たとえば、メッセージの到着を待っている間に、メッセージの到着を待ってスレッドがブロックされた時間を測定します。
処理するメッセージが常に十分にある場合を除き、スレッドはメッセージの待機をブロックします。より多くのスレッドがあれば、より多くの潜在的なメッセージジェネレータ(設計によって異なります) があるため、メッセージの受信を待機しているスレッドは、準備ができている可能性が高くなります。
スレッドが待機する必要がないように、常に十分なメッセージが存在することを保証できない限り、CPU に対して 1 つのスレッドだけでは少なすぎます。