semaphore - セマフォについて

Question

「オペレーティング システムの概念」(ご存知の方向け) でセマフォについて読んでいますが、この一節を読むまではセマフォを完全に理解していると思っていました。

セマフォの重要な側面は、それらがアトミックに実行されることです。2 つのプロセスが同じセマフォで同時に待機操作とシグナル操作を実行できないことを保証する必要があります。

また:

ハードウェアが特別なアトミック命令を提供しない場合は、クリティカル セクションの問題に対して任意のソフトウェア ソリューションを使用できます。ここで、クリティカル セクションは待機手順と信号手順で構成されます。

Signalこの文章は、Wait操作はアトミックでなければならないという面を指しています。セマフォの全体的な目的は、クリティカル セクションで常に 1 つのプロセスのみを許可することだと思いました。別のアルゴリズム (ベーカリー アルゴリズムなど) を使用する必要がある場合、なぜセマフォも必要なのですか?

私の質問が紛らわしいかもしれません。もしそうなら、それは私にはまだ主題が漠然としているだけなので、質問することさえ少し難しいです.

説明を読んでみたい...

Answer 1

セマフォとミューテックスの区別に問題があると思います。バイナリセマフォはミューテックスと同じ方法で実装できますが、実際には異なる目的で使用されます。セマフォはリソースを保護しますが、ミューテックスはコードのブロックを厳密に保護します。区別はしばしば微妙です。

セマフォを使用すると、セマフォのカウントなどのバリエーションが発生するため、1つのプロセスのみがリソースにアクセスできるという考えが常に正しいとは限りません。1つのプロセスまたはスレッドへの書き込みをブロックしたいが、複数からの読み取りを許可したい場合があります（リーダー/ライターロック）。

このテーマに関するウィキペディアの記事をご覧になることをお勧めします。実は結構いいです。
http://en.wikipedia.org/wiki/Semaphore_(programming）

Answer 2

原子性は、相互排除を実装する方法です。コードのクリティカル セクションに入るスレッドを一度に 1 つだけにしたいとします。どうやってそれをしますか？さて、「ロック/ロック解除」インジケーターがあります。また、スレッドがコードのクリティカル セクションに入る前に、インジケーターを「ロック解除済み」から「ロック済み」に変更するようスレッドに強制します。

しかし、2 つのスレッドがインジケーターが「ロック解除」されていることを認識し、同時に「ロック」に切り替え、コードのクリティカル セクションを同時に実行するのを防ぐにはどうすればよいでしょうか? その答えは、「ロック解除」から「ロック」への切り替え操作はアトミックでなければならないということです。つまり、2 つのスレッドの両方が正常にインジケーターを「ロック済み」に変更できないように、すべて同時に実行する必要があります。

Answer 3

これは、セマフォの使用ではなく、セマフォの実装について話しているものです。ハードウェアがセマフォなどのアトミック操作をサポートしている場合、ユーザーがSignal/を呼び出すときにそれらが使用されますWait。ハードウェアがそれをサポートしていない場合、セマフォの実装自体が同じ機能を保証する他の方法を見つけます。

Signalこのようなサポートのないシステムは、およびを呼び出すときに時間がかかることを除いて、これはユーザーには透過的Waitです。（また、すべてではないにしてもほとんどの最新のハードウェアプラットフォームは、セマフォの不可分操作をサポートしています。）

相互排除が必要な場合、それを取得するために使用するメカニズムはアトミックである必要があります。

Answer 4

セマフォをナイトクラブの用心棒と考えてください。一度にクラブに入ることができる専用の人数があります。クラブが満員の場合は誰も入場できませんが、1 人が退席するとすぐに別の人が入場する可能性があります。

これは、特定のリソースのコンシューマーの数を制限する方法にすぎません。たとえば、アプリケーション内のデータベースへの同時呼び出しの数を制限します。

ソース：

Answer 5

クラスの教授にこれと同じ質問をしたところ、彼の答えは「セマフォをハンマーと考えてください。ハンマーがあれば、それを使って多くのことを実行できますが、ハードウェアまたはソフトウェア ソリューションのアトミック サポートを使用すると、ピーターソンやベーカリーなどの相互排除には制限があります。」