えんじにぃーあぶろぐ

あまり長い文章は好きではないので、長い時間をかけないで読める、簡単な内容を目指すエンジニアのブログです。

Linuxのしくみを読み始めました。

さて、

 

 

 

先日よりlinuxのしくみを読み始めました。

下記の本ですね。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

 

 

 

 

最近自分が何に興味あるかなと考えたところ、今は

 

 

「仕組み」

 

 

に興味がある、という結論に至りまして最近読み始めました。

 

職場で最近はメモリ管理など、

低レイヤを意識することが増えたのが恐らく原因ですね。

 

とは言ってもGoも勉強していきたいのでうまくやっていく必要がありますが。。。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

読んでいて、「お?なるほど!確かに」というところがあったので、

メモがてらブログに記載しておきます。

 

 

 

 

 

第4章のプロセススケジューラの話なんですが、

 

実験で1コア(論理CPU(CPUとして認識されているもの、ここではコア))

で、1プロセス・2プロセス・4プロセスを実行して、

CPU内部ではどのようにプロセスが実行されているかの実験です。

 

詳しくは本の中身を呼んで頂ければいいのですが、

簡単に結論だけ書くと、

 

・ある瞬間に論理CPU上で実行されているプロセスは1つのみ

・動かし方は、複数プロセスを順番に1つずつ動かして、

 1周したら最初のプロセスに戻り動かす(ラウンドロビン方式)

・各プロセスはほぼ等しい時間間隔(タイムスライス)で動いている

・全プロセス終了時間はプロセス数に比例して増加(2つなら2倍、4つなら4倍)

 

 

という感じでした(手元のUbuntuでも実行して確認済み)

 

また、このプロセスが切り替わる仕組みを

コンテキストスイッチ」と呼ぶ。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

知っていたことではありましたが、手元で動かして確認したことがなかったので

新鮮な感じで学べました。

 

また下記の内容が一番「なるほど!」と思ったことなのですが、

 

コンテキストスイッチはいかなるコードの実行中であっても、

タイムスライスが切れると容赦なく発生する。

なので、hogehoge関数の次にhugahuga関数があったとしても

hugahuga関数の前に別プロセスが動くかもしれないので、 

必ずしもその順番で実行されるわけではない。

 

ということでしたね。

 

なので、

処理に思った以上に時間がかかっている場合は

 

・処理自体に問題がある

コンテキストスイッチが発生して他のプロセスが動いた可能性がある(NEW)

 

という可能性がある、という観点を新しく身につけることができました。。。

 

 

これまでの見方とは別の観点がある。

これを発見できただけでもこの本買った価値ありました!

 

しかもまだまだ本の最初の方なので、学ぶことはもっとありそうです…。

 

是非皆様もお買い求めください。

 

 

続きを読むぞー!