Abraham Silberschatz、Peter B. Galvin、Greg Gagneによるオペレーティングシステムの概念より
5.8.3セマフォを使用したモニターの実装
ここで、セマフォを使用した監視メカニズムの可能な実装を検討します。モニターごとに、aセマフォ
mutex
(1に初期化)が提供されます。プロセスは、モニターに入る前にwait(mutex)
を実行し、モニターを離れた後にsignal(mutex)
を実行する必要があります。シグナリングプロセスは、再開されたプロセスが終了または待機するまで待機する必要があるため、追加のセマフォ、
next
が導入され、0に初期化されます。シグナリングプロセスは、next
を使用して自身を一時停止できます。整数変数next count
も、next
で中断されたプロセスの数をカウントするために提供されています。したがって、各外部関数F
は、wait(mutex); ... body of F ... if (next count > 0) signal(next); else signal(mutex);
モニター内での相互排除が保証されます。
セマフォmutex
は1に初期化されるので、モニター内に存在できるプロセスを最大1つに制限するために使用されますか?
セマフォnext
は、next
で中断されたプロセスの数を意味します。これらのプロセスは、next
ですべてモニター内で中断されていますか?
上記の2つの質問に対する答えが「はい」の場合、それらは互いに矛盾しますか?
いいえの場合、モニターは実際どのように機能しますか?
ありがとう。
セマフォミューテックスは1に初期化されているため、モニター内に存在できるプロセスを最大1つに制限するために使用されますか?
はい。
セマフォnextは、nextで中断されたプロセスの数を意味します。これらのプロセスは、次にすべてモニター内で中断されていますか?
はい、一部はnext
で、一部はmutex
で一時停止されています。 next
で一時停止されているものは、モニター内にあります。これは、mutex
での待機をパスし、実行するためにその相互排他を使用したという意味です。モニターが提供するロックの安全性(原子性)内の条件のテスト。ただし、後で譲るように選択されているため、next
キューではなくmutex
キューで中断されます。
これはオプション機能です。条件によってクライアントが譲らない場合、mutex
で待機しているクライアントのみが存在します。条件が原因でクライアントが譲歩する場合は、wait
の元のmutex
をまだ渡していないクライアントよりも優先されます。 (スレッドは条件が原因で発生するため、スリープ中にモニターを事実上解放し、ウェイク時に再取得します。ただし、優先順位を失うことはありません。たとえば、next
キューではなく、mutex
キューにいます。)
上記の2つの質問に対する答えが「はい」の場合、それらは互いに矛盾しますか?
いいえ、next
キューは別の目的を持っており、ロックを取得したスレッドが単にロックを解放するのではなく譲ることを選択したときにオプションで使用されます。
別の text は、これを幾分明確に述べています:
5.8.3セマフォを使用したモニターの実装
•モニターの可能な実装の1つは、セマフォ「mutex」を使用してモニターへの相互排他アクセスを制御し、プロセスがモニターの「内部」に入った後にプロセスが自身を一時停止できるカウントセマフォ「次」(条件変数と組み合わせて) 、以下を参照してください。)整数next_countは、次のキューで待機しているプロセスの数を追跡します。外部からアクセス可能なモニタープロセスは、次のように実装されます。
•セマフォを使用して条件変数を実装することもできます。条件xの場合、セマフォ「x_sem」と整数「x_count」が導入され、どちらもゼロに初期化されます。次に、待機メソッドとシグナルメソッドが次のように実装されます。 (この条件へのアプローチは、モニター内で一度に1つのプロセスのみがアクティブになるようにするために、上記のシグナルアンドウェイトオプションを実装します。)