ごみため(ー日ー膳！)

よろしいですか。逐次スケジューリングそのものが、そもそも間違いなのです。

逐次スケジューリングが必要となるのは、現実世界では飛び込み作業あるいは割り込み作業です。

しかも複数タスクに分割可能なフクザツなタスクを割り込ませるとなると、それまでの予定通りのタスクは非常に大きな影響を受けます。

当たり前のことですが、単位時間にこなせる仕事量、つまりタスク量には上限があります。例えば1日にある工場のライン100人でこなせる仕事量は決まっています。残業したら伸ばせるというようなことを考えるのは阿呆な経営者です。

時間外手当は割り増し料金なのですから、同じ単価の仕事を割り込ませるだけで赤字なのです。

また、割り込みや予定外の作業に備えて、余裕を持たせてラインを回すのもまた間抜けのやることです。例えば90％の負荷率なら10人にはタダ飯を食わせていることになるからです。

まぁきっちり100％というのもなかなか机上の空論であることは認めなければなりませんがね。

つまり毎日毎日滞りなく、100人で100人分の仕事を回せるように段取りするのがラインの責任者、あるいは管理者の仕事なのです。

そのラインの設計において、優先度スケジューリングが役に立ちますか？たちゃしませんよ。

ではそのラインで割り込み作業を押し込むために優先度スケジューリングが役に立ちますか？たつわけ無いですよね。そもそもそんなスケジューリングで日常業務を回していないのに、割り込み作業だけ優先度で管理したって意味が無いのです。

嗚呼、私は何が書きたかったのでしょう。風呂に入っている間に忘れてしまいました。たぶんこういうことです。

CPUパワーをギリギリまで引き出したいのなら、よほどきっちりと設計しなければならない。そしてそこではスケジューラは何の役にも立たない。どちらかというとスケジューラに頼らないか、自前の簡易スケジューラの方が、無駄なオーバーヘッドを避けることが出来るかもしれない。

きっちりした設計というのは、いきなり全体にクロックラインを引くようなものです。

おそらく中規模以上のシステムでは、こんな開発をしているのではないでしょうか。機能や階層別にチームを分け、それぞれ別々に実装する。リソースの共有や競合が生じるチーム間では排他制御の機能を用いて適切に排他をおこなう。

そんなものはぜんぜんダメだということです。排他制御をおこなうということは、誰がいつどのリソースにどれくらいの頻度でアクセスするか全く把握していないか、あるいは把握することを放棄してしまっていることとほとんど同じだからです。排他制御にお任せ？ちゃんちゃらおかしい話です。

OSのカタログには排他制御のシステムコールのオーバーヘッドの小ささや割り込みハンドラのレイテンシの小ささが強調されています。しかしそんなものはまやかしなのです。

ベテランさんならこの話を読んで、ニヤリとするはずです。