プロセスその16
Windowsの方はどうか? というと、流石にInside Windowsにはここまでの詳細な記述はない。特にQuantum終了時の処理については全く記述が無いが、Kernelそのものを記述するのでなければこれは不要という事なのかもしれない。
まぁそうは言いつつも、色々興味深い部分はある。まず「タイムスライス管理」(上巻P398)を見ると、10ないし15msの割り込み毎にThreadの持つQuantum値を減らしている。これはどちらかというとVMSの方がトリッキーなのであって、VAXのADD命令とBRANCH命令を組み合わせたほうが高速に処理ができたから足し算をインプリメントしたのであって、マルチプラットフォームを前提としたWindowsではセオリー通り持ち時間を引いていって0以下になったらContext Switchingを開始、を素直にインプリメントしたのだろう。むしろ大きな差に感じるのは、スレッドの持つQuantumがわずか6(Windows Serverでは36)で、しかも1回のタイマー割り込み毎に3づつ減らされる事だ。つまり原則として、Windows XPとか2000だと、20msec毎にThread Context Switchingが発生している計算になる。もっともこれについては、「タイムスライスブースト」(上巻P401)にも有る様に色々例外があるので、平均的なQuantum Tickはもう少し長いのかもしれないが、それでもVMSの様な200msに比べるとだいぶ短い。
理由の一つは、やはり管理単位がProcessではなくThreadだからであろう。一般論としてThreadはProcessに比べて処理の粒度が細かいし、システム全体のThreadの数そのものがProcessよりもだいぶ増える。従って均等にCPUを割り当てるためには、どうしてもQuantum Tickを短くせざるをえない。また、Context Switchingに要するオーバーヘッドが相対的に小さくなっていることもあるだろう。例えばVMSにおけるSCH$QENDの処理の中で、
- Process実行時間リミットに達したか(これはProcess毎に使える実行時間が制限されている場合のみ、行われる)のチェック
- 必要ならプロセス削除
- 可能ならWorking Set Adjastmentの開始
といった事は、WindowsにおけるThreadレベルでのContext Switchingには必要ない(ただしProcess Levelではこうした処理がどこかで必要になるわけで、結果としてThread LevelとProcess Levelの2段構えのContext Switchingが必要になるから、トータルのオーバーヘッドはむしろ増えているのだろうが)から、Quantum Tickが短くなっても、それに反比例してオーバーヘッドが増えるというところまで行っていないと考えられる。このあたりが、スケジューリング頻度変更の理由だろうと思われる。
共通点はほかにもあって、やっぱりスケジューリングはタイマー割り込みで行われる(これに関してはまぁほかに適切なContext Switchingの方法が事実上ないから、当然なのかもしれないが)とか、Wait StateだとQuantumの値が減らされてゆくといったあたりは、実に良く似ている。
その一方、新機能もいくつか目立つ。先にちょっと触れたタイムスライスブーストは、Foreground Processという概念そのものが無い(Interacriveか、Batchかという違いはVMSにもあるが、これとForeground/Backgroundは同一とは言いにくい)VMSには考えられない(*1)仕組みである。
(*1)厳密に言えば、VAXもGUI付きのVAX Stationと呼ばれるシリーズが登場したことで、概念的にはForeground/Backgroundという概念そのものは発生したが、まだ当時はWindow Systemの内部の話であって、OSには反映されていない。これは、やはりGUIは使えるが、OSと完全に切り離されているUnix/Linuxでも言えることである。このあたり、OS内部にWindow Systemそのものを統合してしまったWindowsのアプローチが正しいのかどうなのか、個人的には非常に微妙に感じる。
