検索に移動この記事には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。適切な位置に脚注を追加して、記事の信頼性向上にご協力ください。(2019年3月)モニタ(Monitor)は、リソース(何らかのハードウェア機器や変数群)を共有する複数のタスクの同期を実現する手法である。プロセス間通信方式として使われた。競合状態を防ぐために仮定されるモニタ不変条件モニタ・プロシージャは何かをする前にロックをかけ、処理が完了するか、ある条件を待つことになるまでそれをかけておく(条件については後述)。各プロシージャがロックを解放する際に不変条件が真であることを保証するなら、競合状態となるようなリソースの状態は各タスクからは見えないということになる。単純な例として、銀行口座のトランザクションのためのモニタを考える。反映されていなければならない」ということになる。これはコード自身には書かれていないが、通常コメントに記載されるだろう。Eiffelのような言語は不変条件のチェックを取り入れており、ロックはコンパイラによって追加される。これはプログラマがロックとアンロックをいちいち書かなければならない言語よりも安全で信頼性が高い。条件変数[編集]ビジーウェイト状態となるのを防ぐため、プロセスは互いにそのイベントを通知する手段を持っている必要がある。variable)で実現する。モニタが処理を進める際にある条件が真になっていなければならないとしたとき、対応する条件変数上で待つ。待つにあたってロックを解放し、そのプロセスは実行可能な状態ではなくなる。別のプロセスがその後その条件を真にした場合、条件変数を使ってその条件を待っているプロセスに通知する。通知されたプロセスは再度実行可能状態となってロックを獲得し、処理を続行できる。以下のモニタは条件変数を使ってプロセス間通信チャンネルを実装している。この通信チャンネルは一度に1つの整数しか格納できない。}}ある条件上で待ち状態となる際にロックを解放させられるため、待とうとするプロセス(スレッド)は実際に待ち状態となる前にモニタ不変条件が真であることを保証しなければならない。上の例では通知する側にも同じことが言える。初期のモニタの実装では、条件変数が真となったことを通知された待ち状態のプロセスは即座にロックを獲得して処理を再開するため、条件変数は真であり続けることが保証されていた。このような実装は非常に複雑でオーバーヘッドも大きい。任意のプロセスを中断できる一般的なスケジューリング方式とも相容れない。そのため、条件変数の実装や意味論が研究されてきた。最近の実装では、通知してもいきなり制御が奪われることはなく、待ち状態のプロセスを単に実行可能状態にする。通知を行ったプロセスはロックを保持し続け、モニタ関数を抜けるときにロックを解放する。この方式の副作用として、通知を行う際にモニタ不変条件が真であることを保証する必要がなく(ロックを保持しており、他のプロセスは動けないため)、待っていたプロセスは再度条件が真であるかチェックしなければならない。戻ってくるまでに別のプロセスが動作して条件変数を再び偽にする可能性がある。ように書き直して処理を続行する前に再度条件変数をチェックしなければならない。ある条件変数で待っているプロセス群全てを実行可能状態にする実装もある。複数のプロセスが何らかの記憶装置に空きができるのを待っている場合などに有効である。いうのも記憶装置上の領域を解放した場合、その解放したサイズと待っているサイズがどう対応するかはスケジューラにはわからないため、とりあえず全部を実行可能とする必要があるためである。アントニー・ホーアのアイデアに基づいて最初にモニタを考案し実装した。その後ホーアが論理的フレームワークを構築し、本来のセマフォと能力的に等価であることを示した。Smalltalkその他、多数の言語およびライブラリ外部リンク[編集]この節に雑多な内容が羅列されています。事項を箇条書きで列挙しただけの節は、本文として組み入れるか、または整理・除去する必要があります。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。