問題タブ [thread-local]

Linuxカーネルモジュールでスレッドローカルデータを作成することは可能ですか?

モジュールを呼び出す各プロセス/スレッドのデータを保存する必要があります。スレッド ローカル データを使用する簡単な方法はありますか、それとも現在のプロセスの pid をキーとして使用するハッシュ マップを作成する必要がありますか?

Javaと並行性について質問があります。

'a'というThreadLocal変数があるとしましょう。そして、CachedThreadPoolを使用して新しいスレッドを取得します。スレッドが再利用されると、ThreadLocal変数'a'はどうなりますか？同じ値を維持しますか（同じスレッドであるため）、または空で開始します（スレッドが新しいかのように）？

私のDAOクラスでは、への参照がありEntityManagerます。EntityManagerを使用してスレッドセーフにアクセスしたいThreadLocal。

これまでのところ、私の試みはNullPointerExceptions になっただけで、まともな例を見つけることができないようです。

誰かが私に例を提供したり、正しい方向に向けたりできますか?

update : BalusC の提案を試してみましたが、JSF と JAX-RS Web サービスを同時に介して DAO にアクセスすると、まだエラーが発生します。

私は C3P0 を使用しているため、クローズド接続が問題になる理由がわかりません。

update2 : BalusC の最後のコメントは私の問題を解決したようです:At least, you should not have a single instance of the DAO class shared throughout the application. Create a new one on every request.

ThreadLocalの get() メソッドと initialValue() メソッドが同期されているコードを見つけました。

これらのメソッドを同期させる用途が見つかりませんでした。私が間違っている場合は修正してください。

-クリシュナ。

.Net 4. ThreadLocal<> は IDisposable を実装します。しかし、Dispose() を呼び出しても、保持されているスレッド ローカル オブジェクトへの参照は実際には解放されないようです。

このコードは問題を再現します:

スレッド ローカル データには、ラージ オブジェクトへの参照が格納されます。参照が手動で null に設定されていない場合、GC はこれらの大きなオブジェクトを収集しません。タスク マネージャーを使用して、メモリ消費量を観察しました。また、メモリ プロファイラを実行します。ガベージを収集した後のスナップショットを作成しました。プロファイラーは、リークされたオブジェクトが GCHandle によってルート化され、ここに割り当てられていることを示しました。

これは ThreadLocal<> 設計の欠陥のようです。さらにクリーンアップするために割り当てられたすべてのオブジェクトを保存するトリックは醜いです。それを回避する方法についてのアイデアはありますか？

MSDN から次のように指定します。

正規表現オブジェクトは、任意のスレッドで作成でき、スレッド間で共有できます。

パフォーマンスのために、クラスを使用するときにスレッド間でインスタンスを共有しない方がよいことがわかりました。RegexThreadLocal

スレッド ローカル インスタンスで約 5 倍高速に実行される理由を説明してください。

結果は次のとおりです (8 コア マシン上)。

ソースコード：

を使用してIDisposableを実装する場合、ThreadLocal内に保持されているメンバーをどのように破棄することになっていますかThreadLocal<T>？T

ILSpyによると、ThreadLocalのDispose（）メソッドとDispose（bool）メソッドは次のとおりです。

ThreadLocalが子メンバーに対してDisposeを呼び出そうとしているようには見えません。内部で割り当てられた各スレッドを参照する方法がわからないので、処理できます。

次のコードでテストを実行しましたが、クラスが破棄されることはありません

ThreadLocal は、Tomcat でリークするように、Glassfish サーバーでメモリ リークを引き起こしますか? なんで？ http://wiki.apache.org/tomcat/MemoryLeakProtection

これは、負荷テスト中にTomcatNIOコネクタをテストするときに思い浮かびました。私はThreadLocalを利用し、さらにSpringを使用しています。これは、いくつかの場所でそれも利用していることを知っています。

NIOコネクタには接続ごとのスレッドがないため、クリーンアップされる前にThreadLocalオブジェクトが別のスレッドと共有された場合、バグを見つけるのが非常に困難になる可能性があるのではないかと心配しています。ただし、これは私が見つけた文書化された警告ではなく、これについて警告している他の投稿も見つからなかったため、これは問題ではないと思います。NIOコネクタは、実際の要求を処理するスレッドには影響しないと思います。

この仮定に進む前に、私はいくつかの具体的な証拠を見つけることを望んでいました。

AFAIKは、g ++とclの両方がコンパイラ固有のTLストレージをサポートしています...したがって、C ++ 11 TLSは、現在サポートされているものとは異なるのでしょうか。

スレッドローカルストレージ（TLS）は、特定のマルチスレッドプロセスの各スレッドが、スレッド固有のデータを格納する場所を割り当てることができる方法です。動的にバインドされた（実行時の）スレッド固有のデータは、TLS API（[TlsAlloc]、[TlsGetValue]、[TlsSetValue]、および[TlsFree]）によってサポートされます。Win32とVisualC++コンパイラは、既存のAPI実装に加えて、静的にバインドされた（ロード時の）スレッドごとのデータをサポートするようになりました。

また、VS11のサポートは部分的にリストされています。g ++の場合、GCC4.7でもありません