大地震が起きた

いつ大地震がおきてもおかしくないという報道は以前からされていましたが、3/11にとうとう起きました。
私は会社の３Ｆのオフィスにいたのですが、縦ゆれがした時点でやばい地震だと感じて机の中にもぐりこみました。
オフィスは長時間揺れました。こんな大きく揺れて、続いた地震は生まれて初めてでした。
避難訓練は会社で最近実施したのですが、みんな本当に起こったぞみたいな感覚で移動していました。
夜通しオフィスで電車が動くのを待ち本日のお昼に家につきました。

災害伝言板も無事稼動されました。
災害伝言板が稼動されるときって災害が起きてしまうときなのでとても嫌なときなんだけど、ただシステムが有効に使われるという意味ではいいときなんだよねなんて、なんか複雑で微妙な会話をしたときを思い出しました。

マスコミでもよく報道されますが、災害時は電話で連絡しようとしてもかからなくなってしまうときが多いです。連絡の代替手段でインターネットを活用して掲示板を用意し安否を書き込んでもらうというというのがこのサイトの目的です。前の阪神淡路大震災がきっかけでDoCoMoがはじめたこのシステムは他のキャリアにも導入されいまでは完全に公共システムの働きをしているようです。今ではTwitterなどいろいろ連絡する手段はあるようですが、あて先手段として強力な電話番号をキーにしたい場合はどうぞ。

福島の交換局もこういう震災のときに特に役立つのだなと思いました。



さすがに坂井さんのもくもく会は中止でした。

スレッド実現に必要な観点と用語

●システム・コール…OSに対するサービス要求
●スケジューリング…次に動作すべきスレッドの選択
●ディスパッチ…選択されたスレッドの再開処理
●コンテキスト情報（コンテキスト）…スレッドの処理中断時に保存が必要なＣＰＵの状態のこと
●コンテキスト切替え（コンテキスト・チェンジ）…スレッドのディスパッチのためにそのスレッドのコンテキストを新たに読み込む処理のこと
●アプリケーション・プログラム（ユーザ・アプリケーション）…OSの上でタスクとして動作するプログラム
●ユーザ・スレッド…スレッドとして動作するアプリケーション・プログラム
●コア（カーネル）…アプリケーション・プログラムを除いたOSとしての機能の中核部分



スレッド実現に必要な観点を以下の示してみます。

並列に動作している…3つのスレッドを同時に動作させているとはいえ、実際にはＣＰＵは１つしかないので、３つのプログラムがまったく同時に処理されているというわけではありません。ＣＰＵが動作を切替ながら、３つのプログラムを動かしています。しかし一見すると、まるでＣＰＵが３つあって、それぞれのプログラムをそれぞれのＣＰＵが独立して実行しているかのように見えます。このためこの３つのスレッドは「並列に動作していいる」などと表現します。

割込み処理の応用…割込み処理は、現在の処理内容を一時中断して別の処理を行うというものなので、現在の処理の中断と保存という機能を本質的に持っています。割込み処理をそのまま応用すれば、レジスタの値の保存などにより、スレッドのコンテキストの保存が行えます。

今まで触れてきた割込み処理は割込みにより中断された処理に戻るだけでしたが、この際に、レジスタの復旧を行っています。これは割込み前のレジスタ値を復旧するという処理ですが、これを応用して、スレッドのコンテキストとして保存されているレジスタ値を復旧するという処理を行えば、そのスレッドをディスパッチできます。

割込みハンドラからはスレッドのコンテキストの保存が行われ、さらに「スケジューリング」され、新しい動作可能になったスレッドのコンテキストを復旧することで新しいスレッドが「ディスパッチ」されて動作再開します。このようにＯＳは割込みハンドラの延長にある「処理ルーチン」であると考えることもできます。

OSの制御下…アプリケーションをＯＳの制御下におくことができず、アプリケーション・プログラムにバグがあった場合にシステム全体に影響を与えてしまいます。

処理を強制的に中断する機能をベースにする…スレッドの切替えはそのスレッドを中断させることであり、スレッドの動作に支配されない必要があります。たとえば、ライブラリが呼び出す方式では、あるスレッドにバグはあった場合に、そのライブラリが呼ばれなくなって挙動がおかしくなってしまうかもしれません。

タスクとスレッド

先ほどは以下のサービスを並列に実現する方法を模索しました。
1.LEDを点滅させる
2.1sに1回、液晶パネルに時刻表示を行う
3.シリアルからのコマンドに応答する

実行する処理をサービスの単位で区切ってみることにします。というか既に３つに区切られていますが。。
これらのサービス単位をここではタスクと呼ぶことにします。

また、キーワードになっているスレッドについてです。
プログラムをタスクごとに独立して動作するできるようにする仕組みをスレッドと呼ぶようです。

具体的に独立しているとは以下のようなプログラム実装イメージができることのようです。
たしかに【問題点】の内容は実装イメージ中には含まれていないようです。
①他の機能へ処理を明け渡すために、時間のかかる処理に対して中断・再開といった記述を追加する必要がある。
②プログラムが複雑化するとバグが出やすくなる。要はメインの処理に集中しにくくなる。

本番の実装が楽しみです。

int main()
{
....kz_start(start_threads,...);
....return 0;
}

int start_threads()
{
....kz_run(led_main,"led",1,...);
....kz_run(timer_main,"timer",2,...);
....kz_run(command_main,"command",3,...);

....while(1)
....{
....asm volatile("sleep");
....}
....return 0;
}

int led_main()
{
....while(1)
....{
........kz_recv(...);
........led_turn();
....}
}

int timer_main()
{
....while(1)
....{
........kz_recv(...);
........write_time();
....}
}

int command_main()
{
....while(1)
....{
........kz_recv(...);
........command_exec();
....}
}

【関数ごとに方向性の内容確認】
・kz_run()
スレッドを生成します。
引数として関数のポインタを渡すとスレッドを作成し、その関数の実行を開始します。引数には他にスレッド名、スレッドのスタックサイズなどを渡します。
戻り値は、生成したスレッドＩＤ番号です。これをスレッドＩＤと呼ぶことにします。

・kz_start()
最初のスレッド（初期スレッド）を生成します。
スレッド生成はkz_run()で行いますが、これはシステムコールであるためスレッドからしか実行できません。そのためひとつめのスレッドを「スレッド生成用スレッド」としてkz_start()で生成し、そのスレッドからkz_run()によって本来必要なスレッドを生成していきます。またこの「スレッド生成用スレッド」を今後は「初期スレッド」と呼ぶことにします。引数の意味はkz_run()と同じです。
スレッド生成後はそのスレッドの動作に入るので、この関数が戻ってくることはありません。このため戻り地はなしにしています。