なぜセマフォの代わりにモニターを使うのですか？

私は現在、私の大学の同時プログラミングコースに参加しており、最近モニターの概念について話し始めました。相互排除の必要性については理解していますが、なぜモニターを使うのか分かりません。

私が理解しているように、モニターは常に1つまたはまったくプロセスがクリティカルセクションにないことを保証します。セマフォでそれを実現できます。さらに、セマフォを使用してモニターを実装します（またはモニターを実装するための少なくとも1つの可能性があります）。

では、なぜセマフォを備えたセマフォとまったく同じことを実装するのでしょうか？どのようなメリットがありますか？

それらはほぼ互換性があり、一方を他方から構築することができます。実装/推奨される言語依存性があります（たとえば、Javaには「synchronize」キーワードを使用して組み込みのモニターがあります）。ただし、セマフォは、次の理由と違いにより、モニターよりも「低レベル」のエンティティと見なされます。

モニターとセマフォの両方が同じ目的で使用されます–スレッド同期。ただし、モニターはロックの取得と解放のすべての詳細を処理するため、セマフォよりも使用が簡単です。セマフォを使用するアプリケーションは、アプリケーションの終了時にスレッドが取得したロックを解放する必要があります。これはアプリケーション自体が行う必要があります。アプリケーションがこれを行わない場合、共有リソースを必要とする他のスレッドは続行できません。

セマフォを使用する際のもう1つの違いは、共有リソースにアクセスするすべてのルーチンが、リソースを使用する前に明示的にロックを取得する必要があることです。これは、マルチスレッドを処理するルーチンをコーディングするときに簡単に忘れられます。セマフォとは異なり、モニターは必要なロックを自動的に取得します。[1]

投票数の多いスタックオーバーフローの回答、セマフォとモニターもご覧ください。違いは何ですか？公衆トイレや自転車スタンドによく似た印象的な類推があります。

今日の講義では、セマフォの代わりにモニターを使用する理由について最後に説明しました。

それは基本的にこれに帰着します：モニターとセマフォは同等に表現力があります。つまり、元々セマフォが使用されていたモニターの問題の解決策を見つけることができます。

さて、私たちはすでにそのことを知っていました。なぜセマフォの代わりにモニターを使用するのでしょうか。

個人の好み。通常、デスクトップアプリケーションはモニターを使用するため、ミスの可能性は少なくなりますが、トレードオフとして、相対的に肥大した構造になります。一方、セマフォは軽量な構造であるため、オペレーティングシステムでよく使用されますが、間違いの可能性は残ります。

モニターやセマフォを使用する必要があるかどうかは、状況的な決定であると結論付けることができると思います。リアルタイムシステムを構築する場合は、セマフォを使用することをお勧めします。オフィスプログラムを構築する場合は、モニターを使用することもできます。

たとえば、「センパフォアの小さな本」をのぞいてみてください。アレン・B・ダウニー。多くの同期の問題を記述して解決します。特に失敗したソリューションを確認すると、セマフォは非常に低レベルのメカニズムであり、非常に強力ですが、誤用が非常に容易であり、単純なミスはひどいコンセンサスを持っています（並行プログラムの固有の非決定論的操作によってさらに悪化します）。たとえば、相互排除の強制、間違ったセマフォの操作などを忘れがちです。モニターは、最も頻繁に使用されるケースに事前にパッケージ化されたソリューションを提供し、オブジェクト指向プログラミングのほとんどの利点をもたらします（つまり、モニターによって管理される変数をいじる唯一の方法は、その操作を通じてです）。欠点は、非オブジェクト指向言語に簡単に組み込むことができないことです。