static各スレッドの値を格納する必要があるコンポーネントがあります。これは、ASP.NETだけでなく、多くのシナリオで使用できる一般的なコンポーネントです。

私は[ThreadStatic]自分の目標を達成するために属性を使用することを考えていました。すべてのリクエストが独自のスレッドで呼び出されると想定していたため、ASP.NETシナリオでも正常に機能するとします。

調査の結果、ASP.NETで使用する場合は注意が必要だと言っているScottHanselmanのこのブログ投稿を見つけました。[ThreadStatic]

ただし、ほとんどのコメント（投稿の下）は、リクエストが常に1つのスレッドで実行され、スレッドが同時に別のリクエストによって使用されないというスコットの書き込みに同意しません。それも私が信じていることですが、ここであなたの専門家について意見を述べたいと思います。

更新：私が予想したように、この質問に対するコミュニティの適切なアドバイスは、「それを測定して見る」ことでした。chibacityは、私のためにこれを行ったいくつかの本当に素晴らしいテストで答えを投稿しました。その間、私は自分のテストを書きました。そして、私が見たパフォーマンスの違いは実際には非常に大きかったので、それについてのブログ投稿を書くことを余儀なくされたと感じました。

ただし、属性は実際には無料ではなく、実際にはその魔法を機能させるためにCLRヘルパーメソッドに依存しているというハンスの説明も認める必要があります。ThreadStaticこれは、任意の場合に適用することが適切な最適化であるかどうかを明らかにすることにはほど遠いです。

私にとって良いニュースは、私の場合、それが大きな改善をしたように見えるということです。

私は（他の多くのものの中でも）いくつかの中型配列（〜50要素）をいくつかのローカル変数に対してインスタンス化するメソッドを持っています。

いくつかのプロファイリングの後、私はこの方法をパフォーマンスのボトルネックのようなものとして特定しました。メソッドの呼び出しに非常に長い時間がかかるわけではありません。むしろ、それは単に何度も、非常に迅速に呼び出されます（セッションで数十万から数百万回、これは数時間になります）。したがって、パフォーマンスを比較的わずかに改善するだけでも価値があります。

呼び出しごとに新しい配列を割り当てる代わりに、[ThreadStatic];とマークされたフィールドを使用できることに気づきました。メソッドが呼び出されるたびに、フィールドが現在のスレッドで初期化されているかどうかがチェックされ、初期化されていない場合は初期化されます。その時点から、同じスレッドでのすべての呼び出しで、その時点ですべての配列を実行できるようになります。

（このメソッドは配列自体のすべての要素を初期化するため、配列に「古い」要素があることは問題になりません。）

私の質問は単純にこれです：これは良い考えのように見えますか？ThreadStaticこのように属性を使用すること（つまり、ローカル変数の新しいオブジェクトをインスタンス化するコストを軽減するためのパフォーマンスの最適化として）に知っておくべき落とし穴はありますか？ThreadStaticフィールド自体のパフォーマンスはおそらく素晴らしいものではありませんか。たとえば、この機能を可能にするために、バックグラウンドで多くの余分な「もの」が発生し、独自のコストが発生しますか？

また、50要素の配列のように安価なもの（？）を最適化しようとするのは間違っていることも私には非常に妥当です。そうであれば、間違いなく知らせてください。しかし、一般的な質問は依然として当てはまります。

同じライブラリのさまざまなクラスで使用されるthreadstatic変数を使用するライブラリを作成しました。スレッド用に初期化されると、これらすべてのクラスが連携して、これらの変数を使用してタスクを実行します。

ここで、ASP.NETアプリケーションでこれと同じライブラリを使用する必要があります。threadstaticでは変数が単一のスレッドに対してグローバルになることはありませんが、これらはスレッド間で共有されることがわかりました。

良いアプローチに聞こえないので、関数に変数を渡すことは避けています。したがって、ライブラリを両方のタイプのアプリケーション（winforms + webforms）で使用できるようにするためのソリューション、つまり、threadstaticとsessionの代替が必要です。

図書館の辞書を使って自分の管理を実装してみませんか？誰が私（ライブラリ）、つまりデスクトップアプリケーションまたはasp.netを呼び出したのかを知り、その後、スレッドIDまたはセッションIDをそれぞれ使用して、辞書から変数を取得します。今のところ、それが可能かどうかはわかりません。

また、ASP.NETによるスレッド共有によってthreadstaticが誤動作するのを防ぐために、IISではなくexeによってホストされるこのライブラリ用にWebサービスが作成された場合はどうなりますか？

解決策を提案してください。

[ThreadStatic]属性はどのように機能しますか？コンパイラーがTLSの値を詰め込んだり取得したりするためにILを発行すると想定しましたが、分解を見ると、そのレベルでは実行されていないようです。

フォローアップとして、非静的メンバーに配置するとどうなりますか？開発者にその間違いを犯してもらいましたが、コンパイラーは警告さえ出さないのです。

アップデート

ここで回答された2番目の質問：静的C＃で変更されたThreadStatic

私は自分のコードの一部からサードパーティのコードのいくつかのレイヤーを介して呼び出しています。呼び出しは、自分が書いたコードを呼び出すことによって、ある時点で自分のコードに戻ってきます。

つまり、コード呼び出しチェーンは次のようになります。

残念ながら、サードパーティのコードに渡すものはその2番目のコードに与えられないため、コードが同じスレッドで実行されるという事実を除いて、最初の部分と2番目の部分を結び付けることはできません。

[ThreadStatic]それで、クラスの静的フィールドで単に使用することがこれに対する実行可能な解決策であるかどうか疑問に思いましたか？

コードはWebアプリケーションでも実行されるため、アクセスする必要のある値（オブジェクト）はユーザー/セッションごとに異なるため、静的フィールドを使用することはできません。

すなわち。私はこのようなことをします：

これに対する他の解決策はありますか？

ASP.Netのスレッド アジリティのため、ThreadStaticある要求から次の要求への静的プロパティ アクセスを分離するために Web アプリケーションで使用する適切なメカニズムではありません。

の多くの呼び出しと関連する null チェックなどを回避するために、HttpContext.Current.Items.Net フレームワークによって提供されるトリックはありますか? ASP.Net リクエスト コンテキスト?ThreadStaticHttpContext.Current.Items

注: ThreadStaticAttribute は、内部的に機能コードを持たない特殊なケースであり、その魔法が機能する前に JIT コンパイラによってチェックされることを認識しています。

私は小さなテスト プログラムを作成しましたが、lock {}ソリューションがロックフリーよりも高速に実行されるのに、[ThreadStatic]静的変数よりも属性が高いことに驚きました。

[ThreadStatic] スニペット:

ロック {} スニペット:

私のマシンでは、最初のスニペットに 4.2 秒かかりました。秒 - 1 秒速い 3.2 秒。ThreadStatic とロックなし - 1.2 秒。

[ThreadStatic]この単純な例の属性によって、プログラムの実行時間が大幅に増加するのはなぜでしょうか?

更新：大変申し訳ありませんが、これらの結果はDEBUGビルド用です。1つにはRELEASE、まったく異なる数値 (1.2; 2.4; 1.2) が得られました。数値はDEBUG（4.2; 3.2; 1.2）でした。

そのため、ビルドの場合、パフォーマンスの低下RELEASEはないようです。[ThreadStatic]

TransactionScope クラスがどのように機能して異なるメソッド呼び出し間でトランザクションを維持するのか (パラメーターとして渡す必要なし) を疑問に思っていましたが、この疑いに至りました。この質問については、2 つの考慮事項があります。

1

Telerik JustDecompile を使用して TransactionScope の実装を調べると、現在のトランザクションが System.Transactions.ContextData クラスの ThreadStatic メンバーに格納されていることがわかりました (以下のコード)。

CurrentData プロパティは TransactionScope の PushScope() メソッドによって呼び出され、最後のプロパティはほとんどの TransactionScope コンストラクターによって使用されます。

わかりました、私は彼らがそれを行う方法を見つけたと思います。

2

ASP.NET スレッドの切り替えが発生する可能性があるため、ThreadStatic メンバーを使用して ASP.NET (http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx) 内にオブジェクトを格納することがいかに悪いかについて読んだことがあります。ワーカー スレッド間で失われる可能性があります。

つまり、TransactionScope は ASP.NET では動作しないように見えますよね? しかし、Web アプリケーションでこれを使用した限りでは、トランザクション データが失われるという問題に遭遇したことは覚えていません。

ここでの私の質問は、「ASP.NET のスレッド切り替えを処理するための TransactionScope のトリックは何ですか?」です。

TransactionScope がトランザクション オブジェクトを格納する方法について表面的な分析を行いましたか? または、TransactionScope クラスは ASP.NET で動作するように作成されていませんでした。私はそれについて何の苦労もしなかった幸運な男と見なすことができますか?

.NET の「非常に深く埋もれた秘密」を知っている人は、それを説明してくれますか?

ありがとう

質問のタイトルはほとんどそれをすべて言います。セキュリティ コンテキストや ID トークンなどの伝播をキャンセルするために使用すると、 でマークされた静的変数[ThreadStaticAttribute]がめちゃくちゃになりますか?ExecutionContext.SuppressFlow()

つまり、一連のコンテキスト アイテムにスレッドの静的情報が含まれていますか? もしそうなら、必要なコンテキストの部分を指定する方法はありますか (つまり、ThreadStatics のみで、残りはありません)。

ASP.NETWebフォームコードビハインドに静的接続変数があります。ページ読み込みイベントでは、別々のスレッドでいくつかのメソッドを実行しています。各スレッドは、この接続オブジェクトのthreadstaticインスタンスを利用します。私がやりたいのは、ページのdisposeイベントで、その1つの接続変数のすべての静的インスタンスを一度にクリーンアップすることです。これが不可能な場合は、各メソッドの最後で接続を閉じる必要がありますが、可能であれば、すべてを1行のコードで処理したいと思います。