問題タブ [interlocked]

このコードはスレッドセーフですか？またはこのように言います：

GetIt（）を呼び出す方法はありますか？GetIt（）は2つの異なるスレッドに同じ番号を返します

それは可能だと思われInterlocked.Read()ますが、すべてを1つのブロックで使用またはロックすることになっていますか？

免責事項: 私の投稿は明らかに常に冗長です。タイトルの質問に対する答えをたまたま知っている場合は、以下の詳細な説明を読まずに、自由に答えてください。

このSystem.Threading.Interlockedクラスは、スレッドセーフなコードの記述を支援する非常に便利なメソッドをいくつか提供します。より複雑なメソッドの 1 つに がありますCompareExchange。これは、複数のスレッドから更新される可能性のある実行中の合計を計算するために使用できます。

の使用はCompareExchange少しトリッキーなので、いくつかのヘルパー メソッドを提供するのはかなり常識的な考えだと思いました。

さて、おそらく私はジェネリックに満足しているという罪を犯しているだけです（認めますが、これは多くの場合真実です）。しかし、上記のメソッドによって提供される機能を値のみに制限するのはばかげているように感じdoubleます (または、より正確には、サポートしたいすべての型に対して上記のメソッドのオーバーロードされたバージョンを作成する必要があります)。なぜ私はこれを行うことができないのですか？

Interlocked.CompareExchange<T>どうやらwhere T : class制約があるため、これを行うことはできません。理由がわかりません。つまり、accept 、、などのオーバーロードが既に存在するためかもしれません。しかし、それは正当な理由とは思えません。たとえば、私の場合、このメソッドを使用してさまざまな原子計算を実行できると非常に便利です。CompareExchangeInt32Int64DoubleAggregate<T>

私は同様の質問への回答を読んできましたが、まだ少し混乱しています...アベルには素晴らしい回答がありましたが、これは私が確信していない部分です:

...変数 volatile を宣言すると、アクセスごとに volatile になります。この動作を他の方法で強制することは不可能であるため、volatile を Interlocked に置き換えることはできません。これは、他のライブラリ、インターフェイス、またはハードウェアが変数にアクセスしていつでも更新できるシナリオ、または最新バージョンが必要なシナリオで必要になります。

Interlockedすべてのスレッドに対するアトミック操作の可視性は保証されますか?それとも、変更の可視性を保証するために値にキーワードを使用する必要がありvolatileますか?

これが私の例です：

更新:
私はスポーツが苦手で、元の例を変更したので、ここにもう一度示します。

私はしばらく VB.NET で単純なマルチスレッドを行ってきましたが、初めての大規模なマルチスレッド プロジェクトに取り掛かりました。Synclockより良い方法があるとは思わなかったので、私は常にステートメントを使用してすべてを行ってきました。

Classについて学んだばかりですInterlocked- それはすべてこのように見えます:

次の 1 つのステートメントに置き換えることができます。

これにより、すべてのロックが内部で処理され、番号が変更されます。これは、単純な操作に対して独自のロックを作成するよりもはるかに簡単です (長時間実行される操作やより複雑な操作には、明らかに独自のロックが必要です)。

メソッドを使用して同じことを達成できるのに、専用のロックオブジェクトを使用して独自のロックをロールする理由はありInterlockedますか?

サンプルを取るシステムがあります。これらのサンプルに関心のあるアプリケーションに複数のクライアント スレッドがありますが、サンプルを取得する実際のプロセスは 1 つのコンテキストでしか発生しません。サンプリングが完了するまで呼び出しプロセスをブロックしても問題ないほど高速ですが、複数のスレッドが要求を積み上げたくないほど遅いです。私はこのデザインを思いつきました（最小限の詳細に落とし込みました）：

これは、私が説明したシナリオで安全に使用できますか?

リソースへの排他的アクセスを提供すると同時に、他のクラスが読み取るロックの状態 (_isWorking) に関する情報を提供する方法を見つけようとしています。

これが私がこれまでに思いついたものです：

2 番目のスレッドは、スレッドが既にプロセスを実行していることを確認すると、メソッドを離れて何もしないため、正確にはロックとして機能しません。

これを行うのは正しい方法ですか、それとも目的により適した C# 3.5 構造はありますか?

そして、状態に関する情報を提供しながら、最初のスレッドが終了した後も2番目のスレッドがメソッドを実行する「実際の」ロックシナリオを実装する方法は?

私たちが持っている場合：

を呼び出すための最良の（もしあれば）方法InterlockedExchange、InterlockedIncrementおよびを必要とする他のインターロックされた関数LONG*はsome_var何ですか？

LONGどのWindowsでも32ビットであることが保証されているので、渡すだけでおそらく安全(long*) some_varです。しかし、私にはかなり醜いようで、安全であるという確認を見つけることができません。

longポータブルではないため、タイプをに変更することはできません。正確に32ビットタイプが必要です。

更新：移植可能な不可分操作を提供するライブラリのいくつかの研究は、誰もキャストについて気にしないことを示しました。いくつかの例：

Apache Portable Runtime（APR）：

atom_ops：

私は多くの優れたオブジェクト プールの実装を見てきました。例: C# オブジェクト プーリング パターンの実装。

しかし、スレッドセーフなものは常にロックを使用し、Interlocked.* 操作を使用しようとしないようです。

オブジェクトをプールに返すことを許可しないものを作成するのは簡単に思えます (Interlocked.Increments というポインタを持つ大きな配列だけです)。しかし、オブジェクトを返す方法を書く方法が思い浮かびません。誰かがこれをしましたか？

私はしばらくの間 C# を使用しており、最近、サイド プロジェクトに並列処理を追加する作業を開始しました。したがって、Microsoft によれば、int や float への読み取りと書き込みはアトミックです。

これらの原子性要件は、x86 アーキテクチャで問題なく機能すると確信しています。ただし、ARM などのアーキテクチャ (ハードウェア浮動小数点がサポートされていない可能性があります) では、これらの保証は難しいようです。

この問題は、「int」が常に 32 ビットであるという事実によってのみ、より重要になります。32 ビット書き込みをアトミックに実行できない組み込みデバイスが多数あります。

これは C# の根本的な間違いのようです。これらのデータ型の原子性を保証することは移植可能ではありません。

これらの原子性保証は、FPU や 32 ビット書き込みがないアーキテクチャでどのように実装されることを意図していますか?

Win32 プラットフォームでアトミック操作を提供するライブラリの代わりに、インターロックされた winapi 関数を使用することの利点と欠点は何ですか?

携帯性は問題ありません。