Linuxカーネル解読室 [Linux]
次の仕事はLinuxが関係してるそうなので、例によって積読になっていた本をあさる。
まだ一章のプロセススケジューリングのところを読んでるのだが、1つ気になることが。
schedule関数の頭で
prev = current
としている部分があったが、以下の点が気になった
・currentはどこから来たのか?
・currentがnullの可能性は無いのか?
ポインタはすべてnullチェックせよという教えに反するし、currentはグローバルなんだろうか。引数でもないし。
ただ、それまでの文章で、「アイドル時にはアイドル用プロセスが動く」とあるのでcurrentがnullであることはないんだろう。設計思想として、アイドル時にはアイドル用プロセスが動くようにしたことで、currentがnullであることは無くなった、が正解なのか?
あと、「currentを書き換えるのが誰か?」によってInterlockなどの同期の仕組みが必要になると思うが、そういうのもない。
こういうのって集団でプログラム作ってるとすごい危険だよなぁ。「どんなタイミングでも」currentが正常である前提でプログラム書いてしまう人が出てくるし。あえて強調したのは、どんなタイミングでも正常に変数がセットされていることは無い。当然だが初期化と終了時にはセットされてないことはある。マルチスレッドだと特に不完全な変数を参照してしまいがちになる。この場合はスケジューラーの話なので、複数のCPUで動かすことは無い前提なのかもしれないが、この手の同期が必要かどうかは設計思想に依存するので、実装における設計思想をもう少し記述してもらうとありがたいかなーと思う。まあ、基本概念の説明だけでも結構な量になってるからそこまでケアするのは大変だろうけれども。
まだ一章のプロセススケジューリングのところを読んでるのだが、1つ気になることが。
schedule関数の頭で
prev = current
としている部分があったが、以下の点が気になった
・currentはどこから来たのか?
・currentがnullの可能性は無いのか?
ポインタはすべてnullチェックせよという教えに反するし、currentはグローバルなんだろうか。引数でもないし。
ただ、それまでの文章で、「アイドル時にはアイドル用プロセスが動く」とあるのでcurrentがnullであることはないんだろう。設計思想として、アイドル時にはアイドル用プロセスが動くようにしたことで、currentがnullであることは無くなった、が正解なのか?
あと、「currentを書き換えるのが誰か?」によってInterlockなどの同期の仕組みが必要になると思うが、そういうのもない。
こういうのって集団でプログラム作ってるとすごい危険だよなぁ。「どんなタイミングでも」currentが正常である前提でプログラム書いてしまう人が出てくるし。あえて強調したのは、どんなタイミングでも正常に変数がセットされていることは無い。当然だが初期化と終了時にはセットされてないことはある。マルチスレッドだと特に不完全な変数を参照してしまいがちになる。この場合はスケジューラーの話なので、複数のCPUで動かすことは無い前提なのかもしれないが、この手の同期が必要かどうかは設計思想に依存するので、実装における設計思想をもう少し記述してもらうとありがたいかなーと思う。まあ、基本概念の説明だけでも結構な量になってるからそこまでケアするのは大変だろうけれども。
コメント 0