12
  1. .NET クラス System.Net.CookieContainer はスレッドセーフですか? --更新:ターンキー対応--
  2. 非同期リクエスト中に変更される変数 (つまり、HttpWebRequest.CookieContainer) に対してスレッドセーフを確保する方法はありますか?
  3. スレッドセーフクラスを強調する属性はありますか? --更新: MSDN でスレッドセーフについて説明されている場合、おそらくその属性はありません --
  4. すべての .NET クラスはスレッド セーフですか? --更新:マークが答えた--

マルチスレッド コードの非同期リクエストで CookieContainer を使用するため、これらの質問をします。また、ロック内に非同期リクエストを入れることはできません。F# のように、読み取り専用の "変数" (または不変型) を使用する必要があるのではないでしょうか?

4

5 に答える 5

6

いいえ、すべての .NET クラスがスレッド セーフであるとは限りません。実際、そうする必要がある人はほとんどいません。一般に、静的メンバーはスレッドセーフであるべきですが、それだけです。

不変/半不変のオブジェクトは、自動的にスレッド セーフになります (これには XslTransform などが含まれます)。また、スレッド セーフであることが期待できるいくつかの変更可能なケース (スレッド化されたコンテナーなど) があります。MSDN には、各クラスのスレッド セーフが記載されています。

Cookie コンテナーがスレッドセーフであるとは期待していないため、おそらくこれを自分で同期する必要があります。

（更新しました）

あなたの2番目のポイントについて。正確にどの変数を考えていますか？独自のローカル状態変数は、非同期リクエスト中に直接更新されないため、リクエストを準備するときと応答を処理するときにアクセスを同期するのはあなた次第です。最も一般的には、Monitor- つまり

lock(syncLock) {
    // prepare request from (synchronized) state
    req.Begin{...}
}

そしてコールバックで

lock(syncLock) {
    // ...read values from request...
    // ...update local state...
}

は単なるsyncLockロック オブジェクトです (おそらくインスタンスに対して保持されます)。

private readonly object syncLock = new object();
于 2008-12-28T15:07:46.207 に答える
5

馬の口から：

スレッドセーフ

この型の public static (Visual Basic では共有) メンバーはすべて、スレッド セーフです。インスタンス メンバーは、スレッド セーフであるとは限りません。

編集：

インスタンス メンバーを変更するアクションをロックすることができます。

于 2008-12-28T14:51:36.600 に答える
4

私が見るように (リフレクターの助けを借りて)、CookieContainer は内部的にロックを使用してそのメンバーにアクセスするため、ドキュメントにもかかわらずスレッドセーフである必要があります。

ちなみに、パブリック静的メンバーはまったくありません。そのため、ドキュメンテーションは単なる標準的な通知を提供しているように思えます。

于 2015-04-02T13:45:24.333 に答える
2

注意点として、WebページはHTTP応答の一部として変更されたCookieリストを送信します。応答が送信された後にCookieContainerを変更しても、何も実行されません。存在しなくなったページ要求のCookieコレクションを変更するだけです。

于 2008-12-31T17:47:54.293 に答える
0

.NET フレームワークのすべての静的クラスは、Microsoft によってスレッド セーフであることが保証されています。

これは、Reflector を使用して確認できます。

于 2008-12-28T16:35:30.460 に答える