問題タブ [thread-safety]

との 2 つのメソッドは、.NET 2.0 以降Thread.Suspend()では廃止されています。Thread.Resume()なんで？他の代替案と例は何ですか?

CStatusBar を使用して MFC にダイアログがあります。別のスレッドで、ステータス バーのペイン テキストを変更したいと考えています。しかし、MFC はアサートに文句を言いますか? それはどのように行われますか？サンプルコードは素晴らしいでしょう。

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

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

DLLを作成し、アイテムを「共有」（C＃では静的）として宣言すると、最初に呼び出されたときにインスタンス化され、その後、そのオブジェクト参照が単一の参照として存続することを知っています。

したがって、一度設定された共有文字列プロパティを宣言すると、同じ値を取得するために再度呼び出すことができます。そして、そのスレッドセーフは、アプリケーションドメイン内の主要な関心事です。

アプリケーションドメインの外部で何が起こるか。アセンブリをグローバルアプリケーションキャッシュ（GAC）に配置すると、インスタンスはいくつ存在しますか？

たとえば、GACされた.dllの「MyFileName」という静的プロパティ。

次に、GACされた.dllを呼び出す2つのアプリケーションがあります。「MyFileName」のインスタンスはいくつ存在しますか？アプリケーション1からMyFileNameへの変更は、アプリケーション2が使用する値にコピーされますか？

入力が複数のワーカー スレッド間で共有されている場合、スレッドセーフではないと思われるパッケージの改善を検討しています。TDD の原則に従って、最初に失敗するテストをいくつか作成する必要があります。これらのテストは、問題の評価に確実に役立ちます。

これは達成するのが簡単なことではなく、オペレーティングシステムがスケジューリングとさまざまな操作がインターリーブされる正確な順序を決定するため、素朴なマルチスレッドテストは非決定論的であることを認識しています. 過去にMultithreadedTCを調べて使用したことがありますが、これは役に立ちました。ただし、その場合、既存の実装が失敗した場所を事前に正確に知っていたので、それをカバーする優れた一連のテストを作成することができました。

しかし、問題が何であるかを正確に把握していない場合、潜在的な問題を引き起こす可能性が高いテストを作成するための良い方法はありますか? 他の人が役に立ったライブラリはありますか? 純粋主義者の観点から、マルチスレッド テスト ケースは、通常のシングル スレッド テストと同じ呼び出しとアサーションである必要があり、必要に応じて複数のワーカー スレッドでのみ実行する必要があると考えるのは正しいでしょうか?

ツール/ベスト プラクティス/哲学全般に関する提案は大歓迎です。

ツリービューをセーフスレッドで使用する方法に関する情報を探しています。これを経験した人はいますか、または研究へのオンラインリンクを知っていますか.

ありがとう

完全にスレッドセーフなshared_ptr実装を知っている人はいますか? たとえば、ブーストの実装はshared_ptr、ターゲット (refcounting) に対してスレッドセーフであり、同時shared_ptrインスタンス読み取りに対しても安全ですが、書き込みまたは読み取り/書き込みに対しては安全ではありません。

( Boost docsの例 3、4、および 5 を参照してください)。

shared_ptrインスタンスに対して完全にスレッドセーフな shared_ptr 実装はありますか?

奇妙なブースト ドキュメントは次のように述べています。

shared_ptr オブジェクトは、組み込み型と同じレベルのスレッド セーフを提供します。

しかし、通常のポインター (組み込み型) を と比較すると、通常のポインターsmart_ptrの同時書き込みはスレッドセーフですが、 への同時書き込みはそうでsmart_ptrはありません。

編集: x86 アーキテクチャでのロックフリーの実装を意味します。

EDIT2: このようなスマート ポインターの使用例は、現在の作業項目でグローバル shared_ptr を更新する多数のワーカー スレッドと、作業項目のランダム サンプルを取得するモニター スレッドがある場合です。shared-ptr は、別の作業項目ポインターが割り当てられるまで (それによって前の作業項目を破棄する) 作業項目を所有します。モニターは、ワークアイテムを独自の shared-ptr に割り当てることにより、ワークアイテムの所有権を取得します (それにより、ワークアイテムが破棄されるのを防ぎます)。XCHG と手動削除で実行できますが、shared-ptr で実行できると便利です。

もう 1 つの例は、グローバル shared-ptr が「プロセッサ」を保持し、あるスレッドによって割り当てられ、他のスレッドによって使用される場合です。「ユーザー」スレッドは、プロセッサの shard-ptr が NULL であることを確認すると、代替ロジックを使用して処理を行います。NULL でない場合は、プロセッサを独自の shared-ptr に割り当てることで、プロセッサが破壊されるのを防ぎます。

次の構造は、foo の要素が適切に配置され、サイズが適切に設定されているため、単語のティアリングが発生しないと仮定すると、スレッドセーフですか? そうでない場合、なぜですか？

注: 以下のコードは、私がやりたいことのおもちゃの例であり、実際の現実のシナリオではありません。明らかに、私の例で観察可能な動作をコーディングするより良い方法があります。

これは一見すると明らかに安全ではないように見えるので、安全であると考える理由を強調します。

1. foo の要素を変更しないか、MAGIC_VAL に設定するかの 2 つのオプションしかありません。
2. 更新中にスレッド 2 が中間状態の foo[i] を検出した場合、発生する可能性があるのは次の 2 つだけです。中間状態が <であるSOME_OTHER_NUMBERか、そうでないかです。< の場合SOME_OTHER_NUMBER、スレッド 2 も MAGIC_VAL に設定しようとします。そうでない場合、スレッド 2 は何もしません。

編集: また、foo が long や double などの場合はどうすればよいでしょうか? アラインメントなどは、foo の 1 つの要素を更新しても他の要素に影響を与えないようなものであるとまだ想定しているかもしれません。また、この場合のマルチスレッドの要点はパフォーマンスであるため、どのタイプのロックもこれを無効にします。

これは C# の詳細な質問です。

オブジェクトを持つクラスがあり、そのオブジェクトがロックによって保護されているとします。

ポーリング スレッドでそのプロパティをクエリできるようにしたい。また、スレッドがそのオブジェクトのプロパティをときどき更新することも必要です。また、ユーザーがそのプロパティを更新できる場合もあり、ユーザーはそのプロパティを表示できるようにしたいと考えています。

次のコードはデータを適切にロックしますか?

「適切に」とは、つまり、電話したい場合

または何でも、更新を行っている間、フィールドはロックされますか? 'get' 関数のスコープ内で equals 演算子によって行われる設定ですか、それとも 'get' 関数 (したがってロック) が最初に終了し、次に設定が終了し、次に 'set' が呼び出されてバイパスされますか?ロック？

編集：これは明らかにうまくいかないので、どうしますか？次のようなことをする必要がありますか?

多かれ少なかれ、コピーにしかアクセスできないことを確認するだけです。つまり、2 つのスレッドが同時に「get」を呼び出すと、それぞれが同じ Field1 の値で開始されます (右?)。意味のあるプロパティで読み取りと書き込みのロックを行う方法はありますか? それとも、データ自体ではなく関数のセクションをロックするように自分自身を制限する必要がありますか?

この例が理にかなっているように、MyObject はステータスを非同期的に返すデバイス ドライバーです。シリアル ポート経由でコマンドを送信すると、デバイスは独自の時間内にそれらのコマンドに応答します。現在、ステータスをポーリングするスレッド (「まだそこにいますか? コマンドを受け入れることができますか?」) と、シリアル ポートで応答を待機するスレッド (「ステータス文字列 2 を取得しました。すべて問題ありません」) があります。 )、次に、他のコマンド (「ユーザーがこのことを実行してほしい」) を受け取り、ドライバーからの応答を送信する UI スレッド (「私はちょうどそれを実行しました。それで UI を更新します」)。オブジェクトのフィールドではなく、オブジェクト自体をロックしたいのはそのためです。このクラスのすべてのデバイスが同じ動作をするわけではありません。