并发编程（十一）：Shared Memory 与 Message Passing——关系与组合使用 – ThinkerQAQ

目次

0. 前回の記事の続き

これまでの記事では、共有メモリとメッセージ パッシングという 2 つの同時コラボレーション モデルについてそれぞれ説明しました。

次に、それらの関係と、特定の同時実行要件に直面した場合にそれらを選択して組み合わせる方法について説明します。

1. 2 つのコラボレーション モデルの関係は何ですか?

共有メモリは共有状態に直接アクセスすることで連携し、メッセージ パッシングはメッセージを送受信することで連携します。両者は異なる方法でコラボレーションしますが、相互に排他的ではありません。

前回の記事で BlockingQueue と Channel を分析したとき、プロデューサーとコンシューマーはメッセージを通じてデータを交換しますが、通信コンポーネントは共有メモリを通じてキューのステータスを維持する必要があることがわかりました。

Javaで ArrayBlockingQueue 例えば：

Producer
    |
    v
ArrayBlockingQueue
    |
    +-- Array：存放消息
    |
    +-- ReentrantLock：保护队列状态
    |
    +-- Condition：队列为空或已满时等待
    |
    v
Consumer

複数のプロデューサーとコンシューマーが同時にキューに入れられたり、キューから取り出されたりする可能性があるため、 ArrayBlockingQueue ロックを使用してキュー操作を保護し、Condition を使用してキューが空または満杯になったときの待機と起動を調整します。

ランタイム経由でチャネルに移動 hchan バッファと待機キューを管理し、ロック、アトミック操作、Goroutine スケジューリング メカニズムを使用して通信を調整します。 CPythonの queue.Queue 次に、ミューテックスと条件を使用してキューの状態を保護します。

メッセージ パッシングは、基礎となる共有状態を排除しませんが、チャネルやキューなどの通信コンポーネントでのメッセージのハンドオーバーに必要な同期をカプセル化します。 前回の記事が最終的にミューテックス、アトミック、コンディション、メモリの順序に戻って、メッセージのハンドオーバーがアトミック性、可視性、および順序付けをどのように満たすかを説明したのはこのためです。

2. 2 つのモデルを組み合わせるには?

実際のプログラムでは、両方のモデルが一緒に使用されることがよくあります。

たとえば、タスク処理システムでは、複数のプロデューサーがタスクを送信し、複数のワーカーが並行して実行し、成功したタスクと失敗したタスクの数をカウントする必要があります。

Producer A ──┐
             ├──> Task Queue ──> Worker 1 ──┐
Producer B ──┘                └─> Worker 2 ──┤
                                            |
                                            v
                                     Shared Statistics
                                     (Mutex / Atomic)

ここ、メッセージ パッシングはタスクの引き継ぎを担当します: プロデューサーはタスクをキューに入れ、ワーカーはタスクを取り出して処理します。共有メモリは統計ステータスの更新を担当します: 複数のワーカーが Mutex または Atomic を介して統計データへのアクセスを調整します。

統計ステータスを実行ユニットによって一元管理したい場合は、ワーカーに処理結果を送信させることもできます。

Producer --> Task Queue --> Workers
                               |
                               v
                          Result Queue
                               |
                               v
                          Stats Owner
                               |
                               v
                           Statistics

現時点では、統計所有者のみが統計を変更し、ワーカーは統計に直接アクセスしなくなりました。

どちらのソリューションも正確性を保証できますが、それぞれ代償が伴います。共有状態を直接更新する方が簡単です。オーナーによる集中処理により、複数のフィールドとその制約の統一されたメンテナンスが容易になりますが、メッセージのハンドオーバーとオーナーのライフサイクル管理が増加し、シリアルボトルネックが形成される可能性もあります。

3. まとめ

この記事では、共有メモリとメッセージ パッシングの関係について、基本的な実装と実際のアプリケーションの観点から説明し、これら 2 つのコラボレーション モデルを組み合わせて使用​​する方法について説明します。

このシリーズの次の記事最終章。同時プログラミング シリーズ全体を確認し、まとめで締めくくります。

この記事は最初に ThinkerQAQ の個人ブログに公開され、同時に著者自身によって公開されました。オリジナルのテキストは継続的に改訂される可能性があります。最新版については私の個人ブログを参照してください。