スレッド ローカル ストレージの初期値に関して、MSDN で矛盾を見つけました。 このページには次のように書かれています。

スレッドが作成されると、システムは TLS に LPVOID 値の配列を割り当てます。これらは NULL に初期化されます。

これにより、同じインデックスに対して TlsSetValue を呼び出したことのないスレッドから有効なインデックスを使用して TlsGetValue を呼び出すと、null ポインターを取得する必要があると考えるようになります。

ただし、このページには次のように記載されています。

スレッドが TlsGetValue を呼び出す前に TlsSetValue を呼び出すことを確認するのは、プログラマの責任です。

これは、TlsSetValue で明示的に初期化されていることが確実でない限り、TlsGetValue から返された値に依存できないことを示唆しています。

しかし、2 番目のページでは、次のようにも言って、null への初期化の動作を同時に強化しています。

TLS スロットに格納されたデータは、まだ初期値を持っているか、スレッドが TlsSetValue 関数を 0 で呼び出したため、値が 0 になることがあります。

したがって、データが null (または 0) に初期化されるという 2 つのステートメントと、値を読み取る前に明示的に初期化する必要があるという 1 つのステートメントがあります。実験的には、値は自動的に null ポインターに初期化されるように見えますが、運が良かっただけなのか、常にそうなのかどうかを知る方法はありません。

DLL_THREAD_ATTACH に割り当てるためだけに DLL を使用しないようにしています。次の行に沿って遅延割り当てを行いたいです。

これは信頼できる安全なパターンですか？または、スロットを読み取ろうとする前に、各スレッドのスロットを明示的に初期化する必要がありますか?

更新:ドキュメントには、TlsAlloc が割り当てられた index のスロットをゼロにすることも記載されています。そのため、スロットが以前にプログラムの別の部分で使用されていたかどうかは関係ないようです。

のドキュメントはorg.apache.catalina.core.ThreadLocalLeakPreventionListener言う

スレッドローカル関連のメモリリークを回避するために、が停止しているLifecycleListenerときにエグゼキュータプール内のスレッドの更新をトリガーするA。Context

ThreadLocalメモリリークを正確に防ぐにはどうすればよいですか？コンテキストが停止したときに、ThreadLocalのメソッドを明示的に呼び出しますか？remove()

私の知る限りThreadLocal、ハッシュマップとして実装されています。マップキーは、ThreadLocalインスタンス自体への参照です。マップ値はスレッドローカル値です。

以下にリンクされている Niklas Frykholm による非常に素晴らしいブログ投稿を読んでいるときに、私は頭を包み込むことができない何かに出くわしました。

http://bitsquid.blogspot.nl/2012/01/sensible-error-handling-part-1.html

このコードは私を混乱させました：

コードは、単純なスタックとして使用される文字列の配列へのスレッド ローカル ポインターを定義します。私がよく理解していないのは、クロスプラットフォームの方法で配列を初期化して破棄する方法です? また、これは dll 境界でどのように機能しますか?

Thread-Local Storage と のどちらにデータを格納するのHttpContext.Current.Itemsが効率的ですか?
これは、マスター データ/パラメーターを Web アプリケーションに保存するためのものです。
両方の方法でデータを配置するためのコードは次のとおり

です。 1. System.Web.HttpContext.Current.Items

2.TLS

ありがとう....

pthread TLS を使用して一種の「スレッド ローカル シングルトン」を実装しましたが、この場合、どのように (そしていつ) pthread_key_t を削除できるか疑問に思いました。現在のように、TLS キーによって使用されるメモリは決して解放されないからです。 d.

これの使用目的は、A がプライベート コンストラクターのみを持ち、ThreadLocalSingleton<A> が A のフレンドであると仮定して、A をスレッド ローカル シングルトンにする ThreadLocalSingleton<A> からクラス A を派生させることです。

ああ、また、その実装に問題はありますか。重要なことを見落としていませんか？

私はJavaベースのWebアプリに取り組んでおり、現在ログインしているユーザーを追跡するためにThreadLocalを使用しています。これで、通常は問題なく動作します。ただし、セッション タイムアウトが発生し、システムが (ThreadLocal データから) 変数にアクセスしようとすると、ランダムな値 (他のログイン ユーザーの値) が返されます。理想的には、null 値を返す必要があります。ここで何が起こっているのか混乱しています。

Valgrind は、次のコードでリークされたブロックを報告しています。明らかに、スレッドごとに 1 つです。

コンパイラのバージョン:

GCC ビルド オプション:

プログラムのコンパイル オプション:

valgrind バージョン:

Valgrind オプション:

valgrind 出力の末尾:

コンストラクタとデストラクタは、スレッドごとに 1 回実行されました。

ノート：

• 作成されるスレッドの数を変更すると、リークしたブロックの数はスレッドの数と一致します。
• コードは、GCC がそのように実装されている場合、リソースの再利用 (つまり、リークされたブロック) を許可するような方法で構造化されています。
• valgrind スタックトレースから、thread_local.cc:34 は次の行です。thread_local Foo foo;
• sleep_for() 呼び出しのため、プログラムの実行には約 10 秒ほどかかります。

このメモリ リークが GCC にあるのか、設定オプションの結果なのか、それともプログラムのバグなのか、考えはありますか?

複数のホスト アプリケーションで実行され、boost::thread ライブラリ バージョン 1.53.0 を使用して独自のスレッドを維持するプラグインを開発しています。

Mac 上の特定のアプリケーションでプラグインを実行すると、 を呼び出すときに null アクセス エラーが発生しますboost::condition_variable::timed_wait()。呼び出しスタックの一番上にあるのはpthread_getspecific()、ブースト スレッド ライブラリ内から呼び出される への呼び出しです。

timed_wait()の呼び出しに置き換えると、同じ動作になります。内部で呼び出されるとboost::this_thread_sleep()例外がスローされます。pthread_getspecific()

このアプリケーションは、この種の動作を示す唯一のアプリケーションです。プラグインを他のホストで実行すると、期待どおりに動作します。

pthread の経験はあまりありませんが、ホスト アプリケーションによって設定されたいくつかのプロパティが原因で例外が発生するに違いないと思います。ここで何が起こっているのかについて、より良い考えを持っている人はいますか?

ありがとう！

マクロを介してアクセスされるすべてのスレッドに一意のポインターを格納する必要があります。シングルトンと静的な thread_local std::unique_ptr オブジェクトでこれを解決する必要があると思いました。コードの簡略版は次のとおりです。

main.cpp

yay.hpp

yay.cpp

これを gcc 4.8.1 でコンパイルすると:

私は得る：

clang からより多くの情報が得られることを期待していましたが、clang 3.4 では問題なく動作します。

プログラムを実行すると、期待していた結果が得られます。

ここで何が間違っているのかわかりませんが、静的な thread_local unique_ptr オブジェクトを持つことはできませんか? int や「ネイキッド」ポインターなどの単純な型で機能します。

編集：

これは、 http: //gcc.gnu.org/bugzilla/show_bug.cgi?id=55800に関連するバグである可能性があります。

編集2:

回避策 1: 1 つのファイルを clang でコンパイルする (yay.cpp)

回避策 2 (恐ろしく、移植性がありません): 最初に yay.cpp をアセンブリにコンパイルし、追加します。

アセンブリ ファイルへ、オブジェクト ファイルへのコンパイル、残りとのリンク

ブースト スレッド固有のポインターを使用して、その特定のスレッドのみのグローバル データを格納しています。以下は、誰かが GetInstance() を呼び出したときに返すシングルトンです。

私の質問は、通常のポインター アクセスと比較して、スレッド固有のポインター (m_tspConnectionManager.get();) を取得するのにかかるおおよその時間です。

以下のコードを使用しました (ここで .get() メソッドを 2 回呼び出します)。完全な関数を実行するのに約 3 秒かかりました。

さて、上記のコードを .get() メソッドを 1 回だけ呼び出すように変更したところ、約 1.9 秒かかりました。

したがって、.get() メソッドを呼び出さないだけで、パフォーマンスが 1.1 秒向上することがわかりました。どうやって利益を得るかを理解しようとしてきましたか？ 注:このゲインは、GetInstance() 関数を何度も呼び出すことの全体的なゲインである可能性があります。ここでは、単一のコール ゲインを理解しようとしています。