トップ «前の日記(2006年11月18日) 最新 次の日記(2006年11月20日)» 編集
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|10|12|
2009|02|03|06|07|10|11|12|
2010|01|02|03|04|07|09|10|11|12|
2011|01|03|04|05|06|07|08|10|
2012|01|06|08|09|10|12|
2013|01|02|03|04|07|09|11|12|
2014|01|03|04|05|06|09|
2015|04|
2016|01|08|
ここは旧えびめもです。えびめも2に移行します(2016/12/1)

2006年11月19日

ポストLinuxに向けて

Linuxで30年食えるわけではないだろうからポストLinux時代にも通用するかどうかを、知識や技術習得のふるい分けの判断材料にすると良いと思います。Linuxのデバイスドライバモデルを勉強するにしても、ただ漫然とLinuxの仕組みを勉強するのでは真に自分のスキルにはなりません。例えばLinux-2.6系の割り込み処理を勉強するときに、割り込みという特殊状態(スレッドの外)で処理するのは古い処理系の考え方であり、なるべくスレッドの内側に処理を持ってくるやりかたが今風なコンピュータアーキテクトなのだなと、その理由を探求しながら、
Linuxの勉強を通してLinuxに依存しない技術を
習得すると良いと思います(勉学中の方へ)
■古典的アークテクチャ
 
プロセス処理
      ↓
      割り込み発生→割り込みルーチン           -----
                      ↓                        ↑
                    受信/送信などの処理         長くかかると、タスク切り替えの
                    (けっこう長いかもしれない)リアルタイム性が低下する
                      ↓                        ↓
プロセス処理に戻る←RETI(割り込み復帰)         -----
■最近の流行
 
プロセス処理
      ↓
      割り込み発生→割り込みルーチン           -----
                      ↓                        ↑
                    I/O処理スレッドを起こす    短くて済む
                      ↓                        ↓
プロセス処理に戻る←RETI(割り込み復帰)         -----
 
 
 
        I/O処理スレッド                        スケジューリングが可能である
        while(1){
                割り込み発生まで待つ
                受信/送信などの処理
        }
このように割り込み契機で発生するI/O処理をスレッド化することで(1)スケジュールの対象に出来る、(2)待ちに入れる ようになります。割り込み処理実行によるタスク切り替え周期の性能悪化を減らすのが目的です(iTronなどのRTOS技術者からみればあたりまえのことでしょうけど)。
今後もしばらくはノイマン型コンピュータ全盛となるとおもいますが、コアがマルチ化され、プログラムもスレッド化され並列処理的に考えることが要求されてきます。並列に処理をする訓練をつむと技術職からマネージャ職に移っていっても「人的並列処理」的な視点で見れるようになるかもしれません(んなわけないか)