問題タブ [threadpool]

スレッド プール スレッドのを設定したCurrentCulture場合、スレッドが実行を終了してスレッド プールに戻されるとどうなりますか? デフォルトにリセットされますかCurrentCulture(それが何を意味するにせよ)、それとも私が設定した文化を保持しますか?

フレームワークがこれを防ぐためにスレッドをデフォルトの状態にリセットすることを望んでいますが、この効果に関するドキュメントが見つかりません。私が見つけた最も近いものは、ThreadPoolの MSDN ドキュメントからのものです。

スレッド プールがスレッドを再利用する場合、スレッド ローカル ストレージまたは ThreadStaticAttribute 属性でマークされたフィールドのデータは消去されません。したがって、あるメソッドによってスレッド ローカル ストレージに配置されたデータは、同じスレッド プール スレッドによって実行される他のメソッドに公開される可能性があります。

これは、スレッドが返されたときにスレッドがリセットされていないことを示しているようです。

これをテストするためにいくつかのサンプル コードを試しましたが、文化がリセットされたように見えますが、ThreadPool のスレッドの小さなサブセットしか使用していないと思うため、この動作を正しくテストしているとは確信できません。そのため、既にカルチャが設定されているスレッドをテストしているとは確信できません。

特定のコレクションを取得し、アイテムをコピーし（ItemクラスにはCopy（）メソッドが適切に定義されています）、アイテムにデータを入力し、入力されたコレクションをクラスのコレクションプロパティに返す、かなりプロセス集約的なメソッドがあります。

このメソッドは、要求に応じて、およびSystem.Timers.Timerオブジェクトの「Elapsed」イベントを介して2つの方法で呼び出されます。

現在、コレクション内の40のアイテムは、ほとんど時間がかかりません。button_clickなどによって「アドホック」に入力されるか、Timerオブジェクトによって入力されるか。

コレクション（1000個のアイテムを持つ別のMyClassオブジェクト）のサイズを大きくすると、予想どおりにプロセスに時間がかかりますが、合計で約6秒かかります。それは問題ありません。問題はありません。初期化時に呼び出されるか（form_load）、アドホックに呼び出される（button_click）と、約6秒続きます。

ただし、同じメソッド（コードの正確な行と同様）がSystem.Timers.Timerオブジェクトによって呼び出されています。そして、その経過には約60秒かかります（他の実行では、56秒、1分2秒、1分10秒...アイデアがわかります）。同じプロセスで10倍の長さです！

System.Timers.Timerオブジェクトがスレッドプールで実行されていることは知っています。これが理由でしょうか？スレッドプールの優先度が低くなっていますか、それともキューイング全体に時間がかかっていますか？

要するに、これへのより良いアプローチは何でしょうか？System.Windows.Forms.Timerを使用して同じUIスレッドで実行しますか？

ありがとう！

わかりました、いくつかの追加情報：

タイマー操作は、UIによって呼び出されているDLL内で発生しています。メインの「handler」クラス自体には、すべて同じイベントハンドラーにサブスクライブしているタイマーオブジェクトのコレクションがあります。ハンドラークラスの初期化は、次のように機能します。

私は実際にTimerクラスを継承して、それに'index'プロパティを与えました（eventArgsも同様です）。このようにして、1つのイベントハンドラー（tmr_Elapsed）内で、タイマーの対象となるMyClassオブジェクトを識別し、アクションを実行できます。

ハンドラークラスはすでに独自のスレッドで実行されており、カスタムイベントを発生させて、その操作に関する洞察を提供します。イベントはUI（UIコントロールのクロススレッドアクセスなど）で処理され、イベントが処理された時刻とともに表示されます。これは、「初期化」呼び出しと「アドホック」呼び出しの両方に当てはまります（これらの場合は問題ありません）。

実際の経過イベントは次のようになります。

発信キューが必要なメッセージ処理アプリケーション (電子メール) を作成しています。私がこれを設計した方法は、Executor Service と BlockingQueue に支えられたシングルトン キュー クラス ThreadedQueueSender を持つことです。さらに、javax.mail.Transport オブジェクトのスレッド プールを使用して、発信 SMTP サーバーへの接続を取得および解放します。

add(MimeMessage)このクラスは、ワーク キュー ( ) にメッセージを追加するメソッド を公開しますBlockingQueue。

クラスのインスタンス化時に、ExecutorServiceは固定数のスレッド (5 としましょう) に初期化されThreadPoolExecutorます。各スレッドのメソッドは、割り込みを検出したとき (が呼び出されたとき)run()にのみ終了する無限ループにあります。ExecutorService.shutdownNow()

この run メソッドはBlockingQueue.poll()、使用可能なメッセージがなくなるまでブロックせずにワーク キューからメッセージを取得するために使用します。次にTransport、接続プールからオブジェクトを要求し、接続を開き、取得したすべてのメッセージを送信し、接続を閉じて、Transportオブジェクトを返します。

これは機能しますが、アプリケーションの存続期間中に実行されるスレッドの数が固定されているため、ExecutorService を十分に活用していないと感じています。また、同時実行フレームワークに処理させるのではなく、自分でワーク キューを管理しています。他の人はこの機能をどのように実装しますか? 各受信メッセージを Runnable でラップしてから、送信ロジックを実行する方がよいでしょうか?

ありがとうございます。コメントをお待ちしております。

ライアン

最小スレッド数を設定したい。私は必要なworkerThreadsの数を知っていますが、completionPortThreadsについては、そのサイズがどうあるべきかを知っています（デフォルトでは、プロセッサの数と同じです）。0に設定できますか、それとも危険ですか? いつ使用されますか？

を使用して作成されたスレッドプールがあります

プールがアイドル状態になるまで待つことはできますか? これは、すべてのスレッドが実行されておらず、キューで待機しているものがないことを意味します。

Web を検索しましたが、すべての解決策がうまくいきません。たとえば、プールをシャットダウンしたくないので、 awaitTermination() は機能しません。getTaskCount() の方法も知っていますが、CPU を浪費するプールをポーリングし続けたくありません。

これは大規模なプロジェクトであり、プールで実行されているすべてのタスクを変更したくないため、タスクの連携に依存しないソリューションを探しています。だから、ラッチやバリアは私には効きません。

ThreadPool（Java 5 ExecutorService）を使用してIOを集中的に使用する操作を並行して実行し、パフォーマンスを向上させているTomcatで実行されているWebアプリケーションがあります。プールされた各スレッド内で使用されるBeanの一部をリクエストスコープに含めたいのですが、ThreadPool内のスレッドはSpringコンテキストにアクセスできず、プロキシエラーが発生します。プロキシの障害を解決するために、ThreadPoolのスレッドでSpringコンテキストを利用できるようにする方法に関するアイデアはありますか？

ThreadPoolの各スレッドを各タスクのスプリングで登録/登録解除する方法があるはずだと思いますが、これを行う方法を見つけることができませんでした。

ありがとう！

推奨されるベスト プラクティスは、アプリケーションのスレッドの現在のカルチャを設定して、リソース ルックアップで正しい言語を使用できるようにすることです。

残念ながら、これは他のスレッドのカルチャを設定しません。これは、特にスレッド プール スレッドの問題です。

問題は、最小限の余分な配管コードで、文字列リソース ルックアップをスレッド プール スレッドから正しくローカライズできるように設定するにはどうすればよいかということです。

編集：

問題は、文字列テーブルから生成されるこのコードです。

この場合の「resourceCulture」は、スレッド プール スレッドに対して正しく設定されていません。「ResourceManager.GetString("IDS_MYSTRING", correctCulture);」を呼び出すだけです。しかし、それは文字列が存在することをコンパイル時にチェックする利点を失うことを意味します。

文字列テーブルの可視性を public に変更し、リフレクションを使用して列挙されたすべてのアセンブリの Culture プロパティを設定することで修正できるかどうか疑問に思っています。

ある程度の CPU 時間が利用できるときに実行する重要度の低いタスクがいくつかあります。他のインポート タスクが実行されている場合は、このタスクを実行したくありません。つまり、通常/高優先度のタスクが発生した場合、重要度の低いタスクが完了するまで、重要度の低いタスクを一時停止したいと考えています。

実行する重要度の低いタスクがかなりの数 (50 から 1000) あります。そのため、タスクごとに 1 つのスレッドを作成したくありません。ただし、スレッドプールでは優先順位の指定が許可されていないと思いますよね?

これをどのように解決しますか？

ThreadPool図書館での使用は許容されますか？

ライブラリのユーザーも使用している場合は、明らかに不快な問題が発生する可能性があるためですThreadPool（ThreadPoolもちろん静的クラスであるため）。

コンベンションは何ですか？