並列実行モデル

ウィキペディア小見出し辞書

並列実行モデル

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/16 16:19 UTC 版)

「実行モデル」の記事における「並列実行モデル」の解説

現代では、並列プログラミングはますます重要なトピックになっています。並列実行モデルは、複数のタイムラインを伴うため、複雑になる傾向があります。並列実行モデルには、必然的に同期構造の動作が含まれます。同期構造には、別のタイムラインのアクティビティと比較して、あるタイムラインのアクティビティ間の順序を確立する効果があります。 たとえば、一般的な同期構造はロックです。 1つのタイムラインを考えてみましょう。タイムラインには、「ロックの所有権を取得する」同期構造を実行するポイントがあります。 Posixスレッドでは、これはpthread_mutex_lock(＆myMutex)になります。 Javaでは、これはlock.lock()になります。どちらの場合も、タイムラインはスレッドと呼ばれます。 CおよびJavaの実行モデルはシーケンシャルであり、タイムラインには「ロックの所有権を取得する」ための呼び出しの前に行われるアクティビティと、呼び出しの後に行われるアクティビティがあると記載されています。同様に、「ロックの所有権を放棄する」操作があります。 Cでは、これはpthread_mutex_unlock(＆myMutex)になります。 Javaでは、これはlock.unlock()になります。この場合も、実行モデルCおよびJavaは、ロックの所有権が放棄される前に1つのステートメントグループが実行され、ロックの所有権が放棄された後に別のステートメントグループが実行されることを定義しています。 ここで、2つのスレッドとも呼ばれる2つのタイムラインの場合を考えてみましょう。 1つのスレッド（スレッドAと呼びます）は、いくつかのステートメントを実行し、それらをA-pre-gain-lockステートメントと呼びます。次に、スレッドAが「ロックの所有権を取得」を実行し、次にスレッドAがA-post-gain-lockステートメントを実行します。これは、Aがロックの所有権を取得した後に実行されます。最後に、スレッドAは「ロックの所有権を放棄する」を実行します。次に、スレッドAはA-post-giveup-lockステートメントを実行します。 2番目のスレッドはスレッドBと呼ばれ、いくつかのステートメントを実行し、それらをB-pre-lockステートメントと呼びます。次に、スレッドBは「ロックの所有権を取得」を実行し、次にスレッドBはBがロックの所有権を取得した後にBポストロックステートメントを実行します。 これで、「ロックの所有権を取得する」と「ロックの所有権を放棄する」同期構造の並列実行モデルと言えます。実行モデルは次のとおりです。 「ロックの所有権がスレッドAからスレッドBに移る場合、A-post-gain-lockステートメントはB-post-gain-lockステートメントの前に来ます。」 以上です。 簡単そうですね。複雑なのは、実行モデルには、「ロックの所有権を放棄する」の実行が、他のタイムライン（スレッド）での「ロックの所有権の取得」の実行に影響を与える手段がないという事実に起因します。 。多くの場合、特定のハンドオフのみが有効な結果をもたらします。したがって、プログラマーは、あるスレッドがロックを放棄し、別のスレッドが次にロックを取得する可能性のあるすべての組み合わせを考え、コードで有効な組み合わせのみが許可されるようにする必要があります。 唯一の効果は、A-post-gain-lockステートメントがB-post-gain-lockステートメントの前に来ることです。他の影響は発生せず、他の相対的な順序に依存することはできません。具体的には、A-post-give-up-lockとB-post-gain-lockには相対的な順序が定義されていないため、多くの人が驚いています。ただし、スレッドAは所有権を放棄した後にスワップアウトされた可能性があるため、A-post-give-up-lockステートメントは、多くのB-post-gain-lockステートメントが終了したずっと後に発生する可能性があります。これは、ロックを設計するときに考慮しなければならない可能性の1つであり、マルチスレッドプログラミングが難しい理由を示している。 最新の並列言語は、実行モデルをはるかに使いやすいことに注意してください。スレッドモデルは、元の並列実行モデルの1つでした。これは、使用が難しいにもかかわらず、スレッドモデルが存続した理由を説明している可能性があります。