私は現在、優れたライブラリである.NETのメッセージベースのマルチスレッドにRetlangを使用しています。明示的なロックはもうありません。すべてのスレッドが独自のビジネスを行っており、アプリケーションの一部を管理し、メッセージを介して他のスレッドと通信しています。
ここで、独自のパブリッシャー/サブスクライバースレッドを持つことができるアプリケーションの機能を実装する必要があります。唯一の問題は、このスレッドが実際に実行する作業が非常に少ないことです。約10分ごとに発行元からメッセージを受信する予定です。メッセージを受信すると、それはいくつかの作業を行いますが、数百ミリ秒以上かかることはありません。
それで、99.9％の時間スレッドをスリープさせることが実際に良い選択であるかどうか疑問に思い始めました。この種の操作にはスレッドプールがありますが、メッセージを受信するスレッドを制御できないため、エラーが発生しやすい醜いロックを使用する必要があります。
私の質問は、スレッドをアイドル状態のままにして、大部分の時間を待つことは、リソースの面で本当に問題なのかということです。優れたメッセージベースのアーキテクチャを使用した後に共有マルチスレッドを使用すると、過去にさかのぼるような気分になります。さらに、ロックを備えたアプリケーションの唯一の部分になります。しかし、私は「ここで何か間違ったことをしているのだろうか」と考え続けています。このスレッドで。
編集：皆さん、ありがとうございました。すべての回答を読んだ後、別のスレッドはそれほど問題ではないと判断しました。私のアプリケーションは、メッセージベースのマルチスレッドのみで一貫性を保ちます。パフォーマンスに本当に問題がある場合は（ただし、そうではないはずです）、さらに調査します。