問題タブ [thread-local]

素朴に、私は ThreadLocal が値型への Thread の WeakHashMap のようなものであると予想していました。そのため、 ThreadLocal の値が実際には Thread のマップに保存されていることを知ったとき、私は少し戸惑いました。なぜそのようにされたのですか？値が ThreadLocal 自体に保存されている場合、ThreadLocal に関連するリソース リークは発生しないと思います。

明確化：私は次のようなことを考えていました

私が見る限り、これは、値が何らかの形で ThreadLocal 自体を強く参照している場合、スレッドが死ぬまで ThreadLocal も残りの値もガベージコレクションされないという奇妙な問題を防ぎます。(おそらく、これの最も悪質な形式は、値が参照するクラスの静的変数が ThreadLocal である場合に発生します。オブジェクトもそのクラスも収集できないため、アプリケーション サーバーの再デプロイで大きなリソース リークが発生します。)

私は変数を使用してThreadLocalいます（Clojureの変数を使用していますが、以下はThreadLocalJavaのプレーンの場合も同じです）。特定のコードパスが同じスレッドまたはで使用されるかどうかを確認できないという問題が頻繁に発生します。別のスレッド。私の管理下にあるコードの場合、これは明らかにそれほど大きな問題ではありませんが、多態的なサードパーティのコードの場合、シングルスレッド実行を想定しても安全かどうかを静的に判断する方法さえない場合があります。

これはsに固有の問題だと思う傾向がありますThreadLocalが、安全な方法でそれらを使用する方法についていくつかのアドバイスを聞きたいと思います。

リクエストオブジェクトを必要とするカスタムrender_to_responseメソッドがいくつかあり、それぞれにリクエストを渡すことができますが、代わりにリクエストオブジェクトをミドルウェアに保存してローカルスペースをスレッド化し、他の場所にアクセスしていますが、とにかく影響を受けますか？

Django の世界では誰もがスレッドローカルを嫌っているようです ( http://code.djangoproject.com/ticket/4280、http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser )。これに関するArminのエッセイを読みました( http://lucumr.pocoo.org/2006/7/10/why-i-cant-stand-threadlocal-and-others )が、そのほとんどはthreadlocalsに依存しているため、悪いですエレガントではない。

私は、theadlocals が物事を大幅に容易にするシナリオを持っています。（私は人々がサブドメインを持つアプリを持っているので、すべてのモデルが現在のサブドメインにアクセスする必要があり、リクエストからそれらを渡すことは価値がありません.コード。）

また、多くの Java フレームワークは threadlocals を多用しているようですが、それらのケースは Python/Django のものとどう違うのでしょうか?

スレッドとクラス インスタンスの両方にローカルな変数を実装する、プラットフォームにとらわれない優れた方法はありますか。つまり、T スレッドと I クラス インスタンスがある場合、その変数の TxI インスタンスがありますか? 私は D プログラミング言語バージョン 2 を使用していますが、言語にとらわれない優れた回答も役に立ちます。

以下にいくつかの制約を示します。

1. 同期を要求してはなりません。これにより、スレッド ID をメンバー変数としての変数参照にマッピングするハッシュ テーブルを持つことが除外されます。
2. ガベージ コレクションが必要な参照を保持してはなりません。これにより、クラス インスタンスによってインデックス付けされたスレッド ローカルの静的ハッシュ テーブルが除外されます。
3. 初期化は、効率のために遅延する必要があります。スレッドが特定のインスタンスの変数にアクセスしない場合は、その変数を作成しないでください。

こんにちは、私はこのようなクラス定義を持っています

そして、私はこれを他のクラスで行います1

今、私はclass2でこれを行います

dontIntercept ThreadLocal を設定したため、class1 が発生することはわかっています。私の疑問は、クラス2のものが起こるかどうかです? 私の論理では、JdbcInterceptor のインスタンスは 1 つしかないため、interrupt() へのすべての呼び出しで同じ状態を使用できるはずです。しかし、ThreadLocals はスレッドごとにローカルであると言われました。ここでいくつかの競合が見られます。これについて私を助けてください。

この質問から、Javaや.NETなどの高レベルの開発フレームワークでのスレッドローカルストレージについて疑問に思いました。

JavaにはThreadLocal<T>クラス（およびおそらく他の構造）がありますが、.NETにはデータスロットがあり、まもなくThreadLocal<T>独自のクラスがあります。（これもありますが、ThreadStaticAttributeメンバーデータのスレッドローカルストレージに特に興味があります。）他のほとんどの最新の開発環境では、言語レベルまたはフレームワークレベルで1つ以上のメカニズムが提供されます。

スレッドローカルストレージはどのような問題を解決しますか、またはスレッドローカルデータを含む個別のオブジェクトインスタンスを作成する標準のオブジェクト指向イディオムに対してスレッドローカルストレージはどのような利点を提供しますか？言い換えれば、これはどうですか？

これより優れていますか？

スレッドローカルストレージで単一のオブジェクトを使用すると、メモリ効率がわずかに向上し、割り当て（および構造）が少なくなるため、必要なプロセッサリソースが少なくなることがわかります。他に利点はありますか？

JDK5で実行される以下のピースコードがあります

JDK1.4で実行したいと思います。どのような変更が必要になるかアドバイスしてください

ACE スレッドを使用しており、各スレッドに独自の int メンバーが必要です。それは可能ですか？

私は、スレッドローカルストレージが優れているという回答にコメントしていましたが、私が想定していた例外に関する別の有益な議論を思い出しました

throw ブロック内の実行環境に関する唯一の特別な点は、例外オブジェクトが rethrow によって参照されることです。

2 つと 2 つをまとめると、メイン関数の関数キャッチ ブロック内でスレッド全体を実行すると、スレッド ローカル ストレージが吹き込まれませんか?

ゆっくりではありますが、うまく機能しているようです。これは小説ですか、それともよく特徴付けられていますか? 問題を解決する別の方法はありますか？私の最初の前提は正しかったですか？プラットフォームでどのようなオーバーヘッドがget_thread発生しますか? 最適化の可能性は？

これには、から派生した新しい例外クラスを定義しthread_exception_base、ベースを で初期化する必要がありget_thread()ますが、全体として、これは非生産的な不眠症に悩まされている日曜日の朝のようには感じられません…</p>

編集: GCC がinを3 回呼び出しているようです。編集：最初のウォークスルーで見逃したブロックを見つけるために、スタック、環境、実行可能形式への多くの厄介な内省。GCC がOS から呼び出しているため、これはプラットフォームに大きく依存しているように見えます。約 4000 サイクルのオーバーヘッド。クラス階層もトラバースする必要があると思いますが、それは制御下に置くことができます。pthread_getspecificget_threadcatchlibunwind