問題タブ [threadstatic]

これが私のコードです：

これは ASP.NET Web アプリ内のモジュールにあるため、すべてのメンバーは定義上共有/静的です。ここでの私の目標は本質的に怠惰です。私はどこでも接続を使用するので、使用するたびに新しい接続オブジェクトを淡色表示にするのではなく、スレッドごとに新しいインスタンスとして機能するように、スレッド静的なプロパティを 1 つ持つことは理にかなっています。

これは、同じページを 2 つの別々のブラウザーにロードすることを決定するまでは機能していたようです。これを行うと、接続オブジェクトが既に使用されていることを示す例外がスローされます。

インスタンス タイプがスレッド セーフであるとは限らないという Microsoft の記事を読みました。この場合、このプロパティとそのフィールドがスレッドセーフであることを確認するにはどうすればよいですか?

編集:混乱しているのは、このコードがページ読み込みイベント内で機能することです:

これらの .LoadData() メソッドはそれぞれ別のスレッドで実行され、すべて上記の GlobalConnection プロパティを参照します。最初は ThreadStatic 属性なしですべてを書きました。エラーが発生した後、GlobalConnection プロパティを ThreadStatic にすると、問題は解決しました。これが本番環境にロールアウトされると、この Web アプリは複数のユーザーによって使用されます。これが、2 つの Web ブラウザーで同じページを開くように促した理由です。そこには2つの別々のスレッドがあると思っていましたが、おそらくそれについては間違っています。

「ロギングコンテキスト」を追跡する機能を備えた、自分で作成したロギングフレームワークがあります。[ThreadStatic]プラグ可能な戦略フレームワークがありますが、私が最も頻繁に使用するのは、変数のコンテキストを追跡するThreadStaticバリアントです。マルチスレッドワークフローでのログコンテキストの問題を解決しようとしています。目標は、共通のスレッドを共有するすべてのメソッドとクラスにわたるすべての呼び出しのすべてのログエントリに、同じコンテキスト情報を記録させることです。各スレッドは理論的には独自のThreadStatic変数を取得する必要があるため、アイデアは簡単に思えました。

実際には、ThreadStaticデータは実際にはスレッド間で共有されているようです。これは、スレッドについて私が理解しているすべてに反します。各スレッドがスレッドコンテキストをクリアしたときに追跡する追加のログエントリをスローするまで、問題が何であるかを理解するのに苦労していました（すべてのスレッドはメインループで実行されます...最初に、必要なメッセージがあれば受信すると、コンテキストが初期化され、finally句の最後でリセットされます。）次のログはCONSISTENTです。

[2011-12-15 16：27：21,233] [DEBUG] [TPI.LTI.Eventing.GroupCreatedNotificationHandler：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：324]：（ContextId = 184e82dd-152b-4bb5- a2c6-3e05b2365c04; TransactionId = 1a11130e-e8dd-4fa1-9107-3b46dcb4ffd6; HandlerName = GroupCreatedNotificationHandler; HandlerId = WORKDEVELOPMENT.1）ツール「0967e031-398f-437d-8949-2a17fe844df0」のイベントを http：//tpidev.pにプッシュします。 com / tpi / lti / service /event ..。

[2011-12-15 16：27：21,259] [DEBUG] [TPI.LTI.Facades.LTIFacade：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：299]：（ContextId = 184e82dd-152b-4bb5- a2c6-3e05b2365c04; TransactionId = 1a11130e-e8dd-4fa1-9107-3b46dcb4ffd6; HandlerName = GroupCreatedNotificationHandler; HandlerId = WORKDEVELOPMENT.1）ツールインスタンスguid 0967e031-398f-437d-8949-2a17fe844df0のLTIツールインスタンスの取得：

[2011-12-15 16：27：21,318] [DEBUG] [TPI.LTI.Facades.LTIFacade：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：299]：（ContextId = 184e82dd-152b-4bb5- a2c6-3e05b2365c04; TransactionId = 1a11130e-e8dd-4fa1-9107-3b46dcb4ffd6; HandlerName = GroupCreatedNotificationHandler; HandlerId = WORKDEVELOPMENT.1）ツールインスタンスguid0967e031-398f-437d-8949-2a17fe844df0のLTIツールインスタンスが見つかりました。

[2011-12-15 16：27：21,352] [DEBUG] [TPI.LTI.Facades.TPIFacade：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：299]：（ContextId = 184e82dd-152b-4bb5- a2c6-3e05b2365c04; TransactionId = 1a11130e-e8dd-4fa1-9107-3b46dcb4ffd6; HandlerName = GroupCreatedNotificationHandler; HandlerId = WORKDEVELOPMENT.1）「http://tpidev.pearsoncmg.com/tpi/lti/service/event」でのTPIへのイベントの公開..。。

[2011-12-15 16：27：21,428] [DEBUG] [TPI.LTI.Eventing.GroupCreatedNotificationHandler：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.2_Thread：301]： [LOG]ロギングコンテキストをリセットしています!!

[2011-12-15 16：27：21,442] [DEBUG] [TPI.LTI.Eventing.GroupCreatedNotificationHandler：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.2_Thread：299]：キューで保留中のメッセージはありません。GroupCreatedNotificationHandler.WORKDEVELOPMENT.2ハンドラーが待機しています...

[2011-12-15 16：27：22,282] [DEBUG] [TPI.LTI.Facades.TPIFacade：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：301]：イベントがTPIに公開されました。

[2011-12-15 16：27：22,283] [DEBUG] [TPI.LTI.Eventing.GroupCreatedNotificationHandler：TPI.LTI.Provisioning.Handlers.GroupCreatedNotificationHandler.WORKDEVELOPMENT.1_Thread：301]：プロバイダーからの応答を受信しました：

この特定のケースでは、1_Threadと2_Threadの2つのスレッドがあることがわかります。1_Threadのすべてのログエントリの先頭に含まれることになっているコンテキストデータをイタリック体で示しています。ロギングコンテキストがリセットされる2_Threadのポイントを太字にしました。その後、1_Threadのコンテキスト情報はすべて失われます。これまでの数十のテストでは、ロギングコンテキストが別のスレッドでリセットされた後、すべてのスレッドのコンテキスト情報が失われます。

ThreadStaticを誤解していますか？私は2001年からC＃コードを書いていますが、これまでこの動作を経験したことはありません。.NET 4には新しいThreadLocal<T>クラスがあるようですが、それがとにかく内部でThreadStaticを使用しただけで、同じ問題が発生するのか、それとも機能が異なる（そしてできればより確実に）のかはわかりません。この問題に関する洞察大変感謝しております！ありがとう！

[ThreadStatic] フィールドに状態を保存する asp.net mvc3 アプリケーション (IIS7 上) で独自の IoC メカニズムを使用しているため、HttpApplication.BeginRequest、HttpApplication.EndRequest、および (単一の)関連するリクエストは同じスレッドで実行されます。

その仮定は正しいですか？

ヒントとコツの投稿を読んでいて、これまでやったことのない C# のことを試してみようと思いました。したがって、次のコードは実際の目的には役立たず、何が起こるかを確認するための単なる「テスト関数」です。

とにかく、私は2つの静的プライベートフィールドを持っています:

ご覧のとおり、ThreadStaticAttributeとvolatileキーワードをテストしています。

とにかく、次のようなテストメソッドがあります。

この関数から返されると予想されるのは、次のような出力です。

しかし、私が得ているのはこれです：

出力の後半の「半分」は期待どおりです (これは、ThreadStatic フィールドが私が思ったように機能していることを意味すると思います) が、最初の出力のいくつかは前半の「半分」から「スキップ」されているようです。

さらに、前半の「半分」のスレッドは順不同ですが、Start(); を呼び出してもすぐにスレッドが実行されないことは理解しています。代わりに、OS の内部制御が適切と思われるスレッドを開始します。 編集: いいえ、そうではありません。実際には、脳が連続した数字を見逃しているためだと思っていました。

ですから、私の質問は次のとおりです。出力の最初の「半分」で数行が失われる原因は何ですか? たとえば、「thread 3 setting threadInt to 84」という行はどこにありますか?

ThreadStaticAttribute今朝、C# の記憶をリフレッシュしていたところ、次の行が飛び出しました。

この属性をそのまま使用し、派生させないでください。

この行は .Net Framework のすべてのバージョンのドキュメントにあり、この問題に関する Microsoft 独自のコード分析では、属性が属性の階層の一部になるように設計されている場合にのみ、属性を封印しないままにしておく必要があると述べています。

そのため、ThreadStaticAttributeクラスは現在ではなく、以前も存在していたようには見えませんsealed。なんで？

ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple) の WCF サービスがあります。ThreadStatic 変数を使用してデータを取得したいと考えています。

同じまたは異なる operationContracts に対する 2 つの並列要求が同じスレッド サーバー側で処理される可能性があるのではないかと心配し始めます。これが発生すると、ThreadStatic 変数がオーバーライドされるためです。 )

同じ ServiceBehaviour と maxConcurrentCalls="2" でスパイク サービスを作成しました。その後、wcf クライアントが 50 の並列リクエストでサービスを呼び出しましたが、私の心配は発生しませんでした。ただし、これは 100% の証拠ではありません。

少し早いですがお礼を！

WCF サービスが参照するライブラリの 1 つは、ThreadStatic 変数を使用します。サービス メソッドは、各呼び出しの開始時にその値を設定します。これが安全かどうか疑問に思っています。つまり、呼び出し全体で 1 つのスレッドだけが排他的に使用されることを保証できますか? または、呼び出しが 1 つのワーカー スレッドで開始され、別のワーカー スレッドで終了する可能性はありますか? または、ワーカー スレッドを別のメソッド呼び出しにスワップしてから、再び元に戻すことはできますか?

ConcurrencyMode.Single と InstanceContextMode.PerSession のデフォルトを使用しています。

編集

これまでに見つけた唯一の情報は、次のブログ投稿です。このブログ投稿では、呼び出しが複数のスレッドによって処理される可能性があると述べています。

http://blogs.microsoft.co.il/blogs/applisec/archive/2009/11/23/wcf-thread-affinity-and-synchronization.aspx

この人は正しいですか？マイクロソフトからの決定的な情報はありますか?

WCFサービスがあり、次の（簡略化された）クラスがあります。

おそらく、それはかなり自明のコードです。WCFサービス全体にシングルトンは必要ありませんが、1回の操作呼び出し中にのみ必要です。PerOperationSingletonの1つのインスタンスが破棄された場合、同じWCF操作中に新しいインスタンスを作成しても安全です。

問題は、_hasInstance変数を1つのWCF操作に対してのみ有効にする方法がわからないことです。[ThreadStatic]については知っていますが、ASP.NETとWCFは、操作が単一のスレッドで実行されることを保証するものではなく、別のスレッドに転送される可能性があると聞いています。

_hasInstance = trueがスレッドプールに移動して、他の操作がプールからそのスレッドを選択した場合に誤って検出されることは絶対に避けたいです。

WCF操作が別のスレッドに移動する場合、_hasInstance変数が設定されていれば、「true」値を保持するようにします。

また、パフォーマンスに影響を与えたり、後でデバッグして解決するのが難しい問題が発生したりすることを避けるために、WCFサービスのグローバル設定を変更したくありません（高度なASP.NETおよびWCFトピックに十分に精通しているとは感じません） ）。

クライアントがさまざまな理由で.NETセッションを無効にするように要求したため、セッションに_hasInstanceを保存することもできません。

PerOperationSingletonクラスを実際に環境に依存しないようにしたいと思います。WCFやASP.NETについては何も知らないはずです。

WCF操作の呼び出し全体で_hasInstance変数を静的にし、他のWCF操作に影響を与えないようにするにはどうすればよいですか？

[ThreadStatic].NET フレームワークのさまざまな場所で使用され、さまざまな機能にアンビエント コンテキストを提供します (たとえばTransaction.Current、これは に使用されTransactionScopeます)。

残念ながら、これはスレッド ジャグリングを行う機能 (ASP.NET、async キーワード コード) がスレッドを切り替えるが、 をコピーしないことを意味TransactionScopeしTransactionScopeます。

スレッドの切り替え中に状態を正しくコピーする別のメカニズムCallContext.LogicalGetData(詳細はこちら) があります (少なくとも .NET 4.5 では)。TransactionScopeよりもこれを使用した方が良いように思えます[ThreadStatic]。

を使用している機能が[ThreadStatic]、下位互換性を必要とする既存の機能ではなく、今日作成されたものである場合、それらは を使用して作成されCallContext.(G|S)etLogicalDataますか?

マルチスレッドの乱数発生器を自分で作成しました

ただし、Next() を起動すると NullReferenceException がスローされますが、これは理解できません。そのような ThreadStatic フィールドの初期化はどういうわけか禁止されていますか?

フィールドが毎回初期化されているかどうかを確認できることはわかっていますが、それは私が探している解決策ではありません。