地震によって外部電源を喪失した後、1号機では非常用復水器 (IC) が自動起動した。非常用復水器は、原子炉内の蒸気を格納容器外のプール内の細管へ導いて冷却し、再び原子炉内へ戻して注水する原子炉冷却装置で、ポンプなどの動力を必要とせず自然循環によって動作する。非常用復水器にはその構造上、電源喪失時に一旦自動で弁が閉じ作動を停止する安全装置が付いているのだが、1・2号機中央制御室の現場作業員はICの運転経験がなく、誰もそのことを認識していなかった。政府事故調の報告によれば、津波により全電源を喪失した際に、ICの4つの弁の内、格納容器外側にある弁2・3は閉止し、格納容器内側の弁1・4は閉止動作途中に動力源となる電源を失って「中間開」の状態となった。電源喪失後、中央制御室の制御盤は表示が消えてICの操作ができなくなっていたが、18時18分頃、一時的にバッテリーが回復して弁2・3が閉じていることを示したため、作業員は安全装置がはたらいて弁が閉まっていたことに気付き、制御盤で開操作を行った。しかし、作動中に発生するはずの蒸気を目視で確認できなかったため、「空焚き」により非常用復水器が破損し放射性物質が外に放出される可能性があるという誤った懸念を抱き、18時25分頃再び弁3を閉じてICを停止させた。実際には非常用復水器は空焚きによって破損することはないのだが、現場作業員はそれを理解していなかった。その後、制御盤の表示灯が再び消灯しそうになり、消灯すれば再起動できなくなると考え、21時30分頃に再度弁を開き、その後表示灯が消えて操作できなくなった。こうした操作にも関わらず、1号機ICによる冷却機能はほとんど発揮されなかったとみられる。弁1・4が中間開の状態で十分に蒸気がICへ流れなかった可能性があり、津波到達以降は作業員の弁開閉操作が原子炉に与えた影響は小さかったとみられる。免震重要棟（地図）の対策本部でも、電源喪失によってICが自動停止した可能性を指摘する者はいなかった。18時18分頃弁を開く操作をしたことが報告されたが、それまでICが停止していたことには注意は向けられなかった。18時25分頃再び停止させたことは対策本部に十分伝わらず、対策本部ではICが作動していると認識されていた。そのため、3月11日夕方から夜にかけては、対策本部ではRCICの運転状況が不明だった2号機が最も危険だと認識され、1号機の注水が停止し炉心露出が始まっているという危機意識はなかった。一方、国会事故調は、1号機ICについて、安全装置により自動停止したのではなく、炉心損傷によって早期の内にICの蒸気管に非凝縮性の水素ガスが充満し、そのために自然循環が阻害され、ICが機能喪失していたと推測している。
ビジーウェイト状態となるのを防ぐため、プロセスは互いにそのイベントを通知する手段を持っている必要がある。モニタはこれを条件変数（condition variable）で実現する。モニタが処理を進める際にある条件が真になっていなければならないとしたとき、対応する条件変数上で待つ。待つにあたってロックを解放し、そのプロセスは実行可能な状態ではなくなる。別のプロセスがその後その条件を真にした場合、条件変数を使ってその条件を待っているプロセスに通知する。通知されたプロセスは再度実行可能状態となってロックを獲得し、処理を続行できる。以下のモニタは条件変数を使ってプロセス間通信チャンネルを実装している。この通信チャンネルは一度に1つの整数しか格納できない。monitor channel {  int contents  boolean full := false  condition snd  condition rcv  function send(int sent) {    if full then wait(rcv)    contents := sent    full := true    notify(snd)  }  function receive() {    var int received    if not full then wait(snd)    received := contents    full := false    notify(rcv)    return received  }}ある条件上で待ち状態となる際にロックを解放させられるため、待とうとするプロセス（スレッド）は実際に待ち状態となる前にモニタ不変条件が真であることを保証しなければならない。上の例では通知する側にも同じことが言える。初期のモニタの実装では、条件変数が真となったことを通知された待ち状態のプロセスは即座にロックを獲得して処理を再開するため、条件変数は真であり続けることが保証されていた。このような実装は非常に複雑でオーバーヘッドも大きい。また、任意のプロセスを中断できる一般的なスケジューリング方式とも相容れない。そのため、条件変数の実装や意味論が研究されてきた。最近の実装では、通知してもいきなり制御が奪われることはなく、待ち状態のプロセスを単に実行可能状態にする。通知を行ったプロセスはロックを保持し続け、モニタ関数を抜けるときにロックを解放する。この方式の副作用として、通知を行う際にモニタ不変条件が真であることを保証する必要がなく（ロックを保持しており、他のプロセスは動けないため）、待っていたプロセスは再度条件が真であるかチェックしなければならない。特にモニタ関数に if test then wait(cv) という文があったとき、この wait(cv) から戻ってくるまでに別のプロセスが動作して条件変数を再び偽にする可能性がある。そのため、この文を while test do wait(cv) のように書き直して処理を続行する前に再度条件変数をチェックしなければならない。ある条件変数で待っているプロセス群全てを実行可能状態にする実装もある。例えば、複数のプロセスが何らかの記憶装置に空きができるのを待っている場合などに有効である。というのも記憶装置上の領域を解放した場合、その解放したサイズと待っているサイズがどう対応するかはスケジューラにはわからないため、とりあえず全部を実行可能とする必要があるためである。条件変数の実装例を以下に示す:conditionVariable{  int queueSize = 0;  semaphore lock;  semaphore waiting;    wait(){     lock.acquire();     queueSize++;     lock.release();     waiting.down();  }    signal(){     lock.acquire();     if (queueSize > 0){        waiting.up();     }     lock.release();  }}