アプリをユーザーの操作に応答させ続けるのに問題があります。したがって、メッセージ処理を複数のスレッドに分割したいと思います。
単純に複数のスレッドを作成し、それらすべての同じメッセージキューから読み取り、どのスレッドでも各メッセージを処理できるようにすることはできますか?
もしそうなら、これはどのように達成できますか?
そうでない場合は、この問題を解決する別の方法を提案できますか?
アプリをユーザーの操作に応答させ続けるのに問題があります。したがって、メッセージ処理を複数のスレッドに分割したいと思います。
単純に複数のスレッドを作成し、それらすべての同じメッセージキューから読み取り、どのスレッドでも各メッセージを処理できるようにすることはできますか?
もしそうなら、これはどのように達成できますか?
そうでない場合は、この問題を解決する別の方法を提案できますか?
メッセージポンプまたはUI要素と相互作用するスレッドを複数持つことはできません。そのように狂気があります。
ワーカースレッドにファームアウトできる長い処理タスクがある場合は、その方法で実行できますが、それらを管理するには、別のスレッドセーフキューを使用する必要があります。
これが将来の場合、まだリリースされていないVisualStudio2010でAsynchronousAgentsAPI(私が取り組んでいるもののプラグイン)を使用すると言います が、今日のツールで言うことは、特に作業を分離することですメッセージパッシングポンプでは、メッセージを識別し、その作業を処理する別のスレッドにメッセージを渡すために、できる限り少ない作業を実行する必要があります(必要なスレッドローカル情報がないことを願っています)。それを別のスレッドに渡すということは、ロックまたはロックフリーのいずれかのスレッドセーフキューに挿入し、他のスレッドがキューからアイテムをプルする(または直接プルする)ことを監視できるイベントを設定することを意味します。効率を上げるために、スレッドプールで「ワークスティーリングキュー」を使用することを検討できます。
これにより、UIスレッドから作業を取り除くことができます。UIスレッドに追加の作業(その作業の結果のペイントなど)を実行させるには、Windowsメッセージを生成してUIスレッドを起動し、結果を確認する必要があります。これは簡単な方法です。これを行うには、UIスレッドで実行する作業オブジェクトの別の「作業準備完了」キューを用意します。次のようなキューを想像してみてください。threadsafe_queue<function<void(void)>
基本的に、UIスレッドで空でないかどうかを確認し、作業項目がある場合はインラインで実行できます。作業オブジェクトはできるだけ短命にし、できればブロッキングをまったく行わないようにする必要があります。
動きがぎくしゃくした応答性がまだ見られる場合に役立つもう1つの手法は、スレッドコールバックが16ミリ秒を超えて実行されていないこと、およびUIでロックを取得したりI/Oを実行したりしていないことを確認することです。スレッド。これらの操作を識別するのに役立つ一連のツールがあります。最も自由に利用できるのは「Windowsパフォーマンスツールキット」です。
長い操作を処理するときに別のスレッドを作成します。つまり、シンプルに保ちます。問題は、実行しているコードに時間がかかりすぎることです。これは、別のスレッドが必要なコードです。