1. 概要

並列プログラミングまたは並行プログラミングの作業を開始するとき、通常、最初に遭遇するのは、2つの並行（または並行）実行が同じリソース（変数など）にアクセスしようとしたときの問題です。 Mutex は、この問題を解決するための最も簡単なソリューションの1つです。 次のチュートリアルでは、それがどのように機能し、どのように使用するかを説明します。

2. Mutexの説明

Mutexes が解決策であるという正確な問題は何ですか？ 5人の開発者とスクラムマスターとの午前中のスクラムデイリーミーティングを想像してみましょう。 そのうちの1人はコーヒーを飲んでいて、完全に目覚めるまで話すことができません。 もう1人は、会議に参加するのではなく、デスクに戻ってSQLクエリを終了したいと考えています。 残り（3人全員）は会議の目的を理解し、彼らが何をしたかについて話すことに興奮しているので、彼らは同時に話し始めます。

これは混乱に終わり、誰も何も理解しません。 スクラムマスターはステップアップして、開発者の1人にボールを渡し、「ボールを持っている人だけが話すことができます！」と言います。 その時点から、彼らはお互いを理解し、会議を迅速に終わらせることができました。

それについて考えると、SMはシステムのクリティカルセクションを定義することで状況を解決しました。適切に管理しないと、それがどこにつながるかがわかるため、「クリティカル」という言葉を理解します。 開発者（俳優）は、話すことができ、それを待たなければならない他の人に合図するためのツールとしてボールを使用しました。 言い換えれば、ボールは開発者が話すことを相互に排除しました。 この命名は非常に一般的であるため、人々は省略し始めました： Mutex （ Mutual Exclusion ）。

3. どこで使用しますか？

この概念はさまざまな状況に適用できます。主な目標は、常にクリティカルセクションを定義できるようにすることです。

  • 書き込みおよび読み取りアクセスで共有メモリにアクセスする複数のスレッド
  • 共通のリソース（プリンターとカメラ）にアクセスする複数のプロセス

Mutex の一般的な実装の1つは、 Lock で、取得（クリティカルセクションに入る）および解放（クリティカルセクションから出る）できます。

4. プロパティ

前述のように、クリティカルセクションは、一度に1人のアクターにのみアクセスできることが保証されています。システムの設計が不十分な場合、1人のアクターのみが作業できる1つの大きなクリティカルセクションになってしまう可能性があります。他のすべては常にMutexが解決されるのを待たなければなりません。

これは順次実行と変わらないため、並行プログラミングを選択してもパフォーマンスは向上しませんでした（考えてみれば、スクラムの例はそのようなものでした）。 これは、クリティカルセクションの定義の重要性を示しています。 システムを設計するときは、並列実行の恩恵を受けることができるように、共通のリソースを識別してローカライズする必要があります。

もう1つの一般的な問題は、デッドロックです。 楽しみのために、スクラムチームが、開発者が完全に終了した場合にのみボールを渡すと決定したが、彼は同僚からの情報を必要としていると仮定しましょう。 何が起こるのですか？

  • ボールを持っている人（「DevA」）が「DevB」から質問して答えを待つ
  • 「DevB」（ボールなし）は答えを知っていますが、ボールが話せるようになるのを待ちます
  • 「DevA」は完全に終了するまでボールをパスできず、答えが必要です

 

この状況に対する解決策はありますか？ 残念だけど違う。 システムが永久にハングするか、Deadlockにあります。

デッドロックは、特に複数のロックがあるシステムで発生する可能性があります。 デザインにデッドロックがないことを確認するには、各アクターで同じ順序でロックを取得する必要があります。

同様の現象は、catch-22の状況でも表されます。

5. 結論

この記事では、 Mutexes の定義とプロパティを要約し、それらを使用するとどのような問題が発生する可能性があるかを確認しました。 Mutexとは異なる方法でアクター間の相互作用を解決しようとするいくつかのデザインパターンがあることに注意することが重要です。 問題を理解することは、その問題に最適なソリューションを設計できるようにするために重要です。