問題タブ [interlocked]

Javaでintをアトミックかつスレッドセーフに変更するにはどうすればよいですか？

原子的にインクリメント、テスト＆セットなど...？

私は、仲間の開発者 (それ以来去った) がこのコードに問題がないかどうか疑問に思っています。これと単純なロックを使用するだけでパフォーマンスに違いはありますか?

ロックがあればもっと簡単にできると思っていたのですが？確かに複数のスレッドで使用されるため、ロック/インターロックの使用が決定された理由です。

Interlocked を使用する必要があるジェネリック クラスを作成しています。

これはコンパイルされません。だから私は、MSDN がそのように使用しないようにアドバイスしているにもかかわらず、代わりに Exchange(Object, Object) を使用することを余儀なくされていますか?

Microsoft は、InterlockedCompareExchangeアトミック コンペア アンド スワップ操作を実行するための機能を提供しています。組み込みもあります。_InterlockedCompareExchange

x86 では、これらはlock cmpxchg命令を使用して実装されます。

ただし、これら 3 つのアプローチに関するドキュメントを読んでみると、整合要件については一致していないようです。

Intel のリファレンス マニュアルには、アラインメントについては何も記載されていません (アラインメント チェックが有効で、アラインされていないメモリ参照が行われた場合、例外が生成されること以外は)

接頭辞も調べましたがlock、具体的には次のように述べています

LOCK プレフィックスの整合性は、メモリ フィールドのアラインメントの影響を受けません。

(私のものを強調)

そのため、インテルはアライメントは無関係だと言っているようです。操作は何があってもアトミックになります。

_InterlockedCompareExchange組み込みのドキュメントにもアラインメントについては何も記載されていませんが、関数InterlockedCompareExchange には次のように記載されています

この関数のパラメーターは、32 ビット境界に揃える必要があります。そうしないと、関数はマルチプロセッサ x86 システムおよび非 x86 システムで予期しない動作をします。

それで、何が得られますか？命令が使用できないInterlockedCompareExchange486 より前の CPU でも関数が機能することを確認するためだけのアライメント要件はありますか? cmpxchg上記の情報に基づいている可能性が高いようですが、信頼する前に確認したいと思います。:)

それとも、原子性を保証するために ISA でアラインメントが必要なのですか? Intel のリファレンス マニュアルの間違った場所を探しているだけですか?

概要：

それは私には思われる：

1. 論理状態を表すフィールドを単一の不変の消費可能なオブジェクトにラップする
2. への呼び出しでオブジェクトの正式な参照を更新するInterlocked.CompareExchange<T>
3. 更新の失敗を適切に処理する

は、「ロック」構造を不必要にするだけでなく、並行性に関する特定の現実をかわし、結果として多くの新しい問題を引き起こす真に誤解を招くような構造にする一種の並行性を提供します。

問題のディスカッション:

まず、ロックを使用する際の主な問題を考えてみましょう。

1. ロックはパフォーマンス ヒットを引き起こすため、読み取りと書き込みには同時に使用する必要があります。
2. ロックはスレッドの実行をブロックし、並行性を妨げ、デッドロックのリスクを高めます。

「ロック」に触発されたばかげた動作を考えてみましょう。リソースの論理セットを同時に更新する必要が生じた場合、リソースのセットを「ロック」します。これは、関連付けが緩い専用のロック オブジェクトを介して行います。これは、そうでなければ何の役にも立ちません (赤旗 #1)。

次に、「ロック」パターンを使用して、一連のデータ フィールドで論理的に一貫した状態変更が発生するコードの領域をマークオフしますが、フィールドを同じオブジェクト内の無関係なフィールドと混合することで自分自身を撃ちます。それらをすべて可変のままにし、これらのさまざまなフィールドを読み取るときにロックを使用する必要があるコーナー (赤旗 #2) に追い込むことで、一貫性のない状態でそれらをキャッチしないようにします。

明らかに、その設計には深刻な問題があります。ロックオブジェクトの慎重な管理 (ロック順序、ネストされたロック、スレッド間の調整、何かをするのを待っている別のスレッドによって使用中のリソースのブロック/待機など) が必要なため、やや不安定です。コンテキスト。また、デッドロックを回避するのは「難しい」と言う人もいますが、実際には非常に簡単です。あなたのためにレースを走るように頼む予定の人の靴を盗まないでください!

解決：

「ロック」の使用を完全に停止します。 一貫性のある状態またはスキーマを表す、破損しない/不変のオブジェクトにフィールドを適切にロールバックします。おそらく、表示名と内部識別子を相互に変換するための辞書のペアであるか、値と次のオブジェクトへのリンクを含むキューのヘッド ノードである可能性があります。それが何であれ、それを独自のオブジェクトにラップし、一貫性のために封印します。

書き込みまたは更新の失敗を可能性として認識し、それが発生したときにそれを検出し、無期限にブロックするのではなく、すぐに (または後で) 再試行するか、別のことを行うかを状況に応じて決定します。

ブロッキングは、実行する必要があると思われるタスクをキューに入れるための簡単な方法のように思えますが、すべてのスレッドが専用でセルフサービス型であるため、システム全体を危険にさらすリスクを冒してそのようなことを行う余裕があるわけではありません。「ロック」を使用して物事をシリアル化するのが面倒であるだけでなく、書き込みが失敗してはならないふりをしようとすることの副作用として、スレッドをブロック/フリーズするため、スレッドが応答しなくなり、役に立たなくなり、他のすべての責任が放棄されます。自分の責任を果たすために他人を助けることが必要な場合があるという事実を知らずに、自分が以前にやろうとしていたことを達成するのを頑固に待ちます。

独立した自発的なアクションが同時に発生している場合、競合状態は正常ですが、制御されていないイーサネットの衝突とは異なり、プログラマーとして、「システム」(つまり、決定論的なデジタル ハードウェア) とその入力を完全に制御できます。 0 か 1 か?) と出力、およびシステムの状態を格納するメモリであるため、ライブロックは問題にならないはずです。さらに、多数のプロセッサが同時に動作している可能性があるという事実を解決するメモリ バリアを使用したアトミック操作があります。

要約する：

1. 現在の状態オブジェクトを取得し、そのデータを消費して、新しい状態を構築します。
2. 他のアクティブなスレッドがまったく同じことを行っており、あなたを打ち負かす可能性があることを認識してください。ただし、すべてが「現在の」状態を表す信頼できる参照ポイントを観察します。
3. Interlocked.CompareExchange を使用して、作業の基になった状態オブジェクトがまだ最新の状態であるかどうかを同時に確認し、それを新しい状態に置き換えます。それ以外の場合は失敗し (別のスレッドが最初に終了したため)、適切な修正アクションを実行します。

最も重要な部分は、失敗をどのように処理し、馬に戻るかです。これは、私たちがライブロックを避ける場所であり、考えすぎたり、十分なことをしたり、正しいことをしたりしません。ロックは、スタンピードに乗っていても馬から落ちることは決してないという幻想を作り出し、スレッドがそのようなファンタジーの土地で空想にふけっている間、システムの残りの部分はバラバラになり、クラッシュして燃えることができます.

では、CompareExchange と不変の論理状態オブジェクトを使用したロックフリーの実装では、「ロック」コンストラクトが実行できること (より安定した方法で) を達成できないことはありますか?

これはすべて、ロックを集中的に処理した後、私が自分で実現したことですが、別のスレッドで検索した後、ロックフリーのマルチスレッドプログラミングは何かを簡単にしますか? 、何百ものプロセッサを備えた高度に並列なシステムに直面するとき、高度に競合するロックを使用する余裕がない場合、ロックフリープログラミングが非常に重要になるだろうと誰かが述べています。

2つのWindowsプロセスには、同じ共有ファイルがメモリマップされています。ファイルがカウンターで構成されている場合、Interlocked*関数（などInterlockedIncrement）を使用してそれらのカウンターを更新するのは適切ですか？それらはプロセス間でアクセスを同期しますか？または、ミューテックスなど、より重いものを使用する必要がありますか？あるいは、共有メモリメカニズム自体が一貫したビューを保証するかもしれません。

言い換えれば、正規変数とInterlockedクラスでは解決できない揮発性変数を使用して何かを行うことはできますか？

ここにリストされているコードがあります: Threading and Sockets。

その質問に対する答えは、 で変更することでしisListeningたvolatile。私が指摘したように、その修飾子により、別のスレッドから変数にアクセスできました。MSDN を読んだ後、次の新しく作成されたスレッド プロセスから isListening を読んでいることに気付きました。

だから、今私の質問：

• 私volatileは基本的に変数に対して非スレッドセーフなリクエストを行っているので、推奨される方法はありますか? Interlocked クラスについて読んだことがありますが、これが自分のコードで使用するのに適しているかどうか疑問に思いました。Interlocked は何をしているかに似ていますlock(myObj)が、もう少し「才能」とコントロールがあります。lock(myObj)コードブロックを適用するだけでisListeningはうまくいかないことはわかっています。

• Interlocked クラスを実装する必要がありますか?

お時間をいただき、ご回答いただきありがとうございます。

2つのスレッドからアクセスしているオブジェクトがあります。1つのスレッドが、値を返すオブジェクトに対して長時間実行されるメンバー関数を呼び出します。2番目のスレッドは、その値を生成するために使用されるオブジェクトを更新します。

Interlock.Exchangeを呼び出して、最初のスレッドの実行中に2番目のスレッドのオブジェクトを置き換えると、次のようになります。1.古いスレッドの自己が元のオブジェクトへの参照を保持しますか。2.元のオブジェクトがガベージコレクションされるリスクはありますか？

これは常に「古い」を印刷することが保証されていますか？ありがとう。

私はロックレスデータ構造にかなり慣れていないので、演習のために（機能することを望んでいます）制限付きロックレス両端キューを作成しました（サイズ変更はまだありません。基本ケースを機能させたいだけです）。私が正しい考えを持っているかどうか、および/またはこれをどのように改善できるかについて、彼らが何をしているのかを知っている人々から確認を得たいと思います.