(第６回)再入について考える

あなたは 人目のお客様です．

突然だけど，Toppersの最新カーネルをちょっと興味本位で読んでみた． そしたらLinux用シミュレータの実装で，setjmp()/longjmp() を利用して スレッドのディスパッチをしていてびっくり． 使い方もほとんど同じ．うーん，誰でも考えることは同じなんだなあ．．． (けっこう良いアイディアだと思っていたのだが， 誰でも考えつくようなものってことか．．．)

さて，ここまではあまり難しいことは考えずにてきとーーーに作ってきていて， なんだこんなの楽勝じゃんっていうか， なにも考えなくてもよさそうに思えてしまうのだけど， 実際には排他とか再入とかいったことを考えなければならない．

たとえば 前々回の実装では， 複数のスレッドから何も考えずに fprintf() を呼び出していたが， これは問題は無いのか？

また前々々回の実装では， kz_send() によるメッセージ送信でも， スタック上に確保している文字列を平気で送ってしまっていた． これは問題は無いのか？

結論から言うとどちらも問題がある．というより，問題がある可能性がある． まあでも「問題がある可能性がある」というその時点で職業プログラマなら 「ほんとうに問題が無いのか？」を調査しなければならなくなる． つまり，扱いはバグと同じになってしまう．

たとえば fprintf() だが，複数のスレッドから呼ばれてしまっている． ということは，fprintf() の呼び出し中に別のスレッドがタイマ割り込みとかで ディスパッチして fprintf() が再度呼ばれる，ということがありうるわけだ． この際に，もしも fprintf() 関数の内部で

int fprintf(FILE *fp, const char *fmt, ...)
{
  static char buf[1024];
  ...

あるスレッドが fprintf() による処理中にタイマ割り込みが入り，別のスレッドが ディスパッチされ，そちらのスレッドでも fprintf() が行われてしまう． この際に上記バッファの内容は上書きされてしまうため，最初に動いていたスレッドが 再度ディスパッチされたときには，バッファの内容が書き変わってしまっている． 結果として，最初に動いていたスレッドからすれば，とつぜんバッファの内容が 壊れてしまって見えることになる．これはまんまバグに直結するが， 症状が症状なので，非常に原因を特定しにくいバグの原因になる．

このように，ある関数の処理中に再度その関数が(別スレッドなどから)呼ばれてしまう ことは関数の再入と呼ばれる．関数の内部で静的変数の書き換えをしていると， 上で説明したように，関数が再入された際に誤動作することになる．

プロセスモデルだと，仮想メモリ機構によってプロセス単位で資源が確保されるので このような問題は起きない(注:シグナル処理を除く．このためシグナルハンドラから ライブラリ関数を無闇に呼んではいけない)のだが， スレッドプログラミングではスレッドのディスパッチが頻繁に起きるのと， 資源は共通化されるので，このような再入はあたりまえのように起きることになる． で，いくつか対策はあるのだが，まず代表的な対策として

• 静的変数(グローバル変数などもダメ)は一切利用せず， ローカル変数のみ利用する．

関数を再入可能にするならば，その関数だけでなく，その関数の内部から呼ばれる ライブラリ関数も芋ヅル式に再入可能になっていないと意味が無い．よって 再入可能にするためには，関数単位でなくライブラリ単位での対処が必要になる． とはいっても最近のライブラリはスレッドでの利用を考慮して， ライブラリ全体として再入可能になっているものも多い． こーいうのは「このライブラリはスレッドセーフになっているため， スレッドプログラミングで利用することも可能である」 などと説明されることもある．

もうひとつの方法として，

• オブジェクト指向を導入し，スレッド単位でログ出力用のオブジェクトを作成し， 実際の出力時にはオブジェクトに対して出力処理を行う． (資源はオブジェクト単位で確保されるので，資源がぶつかることは無い)

• スレッドの構成や優先度を工夫することで，再入されることが無いような 設計にする．

• 共通資源のアクセス時には，割り込み禁止，優先度変更，セマフォの利用 などで排他を行う．

で，ここまではまあ対策の方法で思いつくものを書いてみたのだけど．．．

まず FreeBSD の fprintf() がスレッドセーフかどうかという点なのだけど， ちょっとよくわからない．こーいうのは実装によって異なるので， FreeBSD と Linux ではとーぜん違うことが考えられるし， まあ調べればわかることなのだけど，調べてないしよく知らん． またスレッドセーフでないとしても， 現状の実装では，上で説明したような優先度などの関係で， 構造的に再入が起きない，ということもあり得る． このへんはほんとはちゃんと検証しなければならないのだけど， 面倒なのでここでは検証していない． そーいう意味で，冒頭では 「問題がある」ではなく「問題がある*可能性がある*」という表現をしている．

でも「問題がある可能性がある」ということは，言い方を変えれば， 「問題が無いことを調べてはっきりさせるか，別の実装方法に変更する必要がある」 ということだ．

結局のところこれらの問題は，スレッド間で共通の資源をどうするかということ なのだけど，実は共通資源の扱いに関しては，一番良いというか， まあだいたいこーしとけば間違いは無いというまともな対策がある．それは，

• 共通資源をアクセスするための専用スレッドを作成し， その資源へのアクセスはそのスレッドに限らせる．

• 共通資源の管理はすべてOSにまかせる．

まず前者について説明しよう．fprintf() による表示をすべてのスレッドで 許可するのではなく，fprintf() を行う専用のスレッドを作成し， 各スレッドはメッセージの出力が行いたいならば，自分で fprintf() を呼び出すのでは なく，その専用スレッドにメッセージを投げて，出力を「お願いする」というものだ．

次に後者だが，これは簡単だ．そのサービスを行うためのシステムコールを作成し， OSに行わせる，というものだ．ただしこれをやるとOSがサービス過剰で肥大化しがちに なるので，注意と取捨選択が必要だ．

前者では共通資源の利用は専用スレッドにお願いしたが， 後者ではOSにお願いすることになる． いずれにしても，共通資源をアクセスするコンテキストはひとつに絞る， というのがミソになる．そもそも資源がひとつならば，それをアクセスするひとも ひとつであるべき(そしてそのひとにお願いするべき)という考え方だ．

ではここで，上記の前者，後者の設計で， 前回の fprintf() による文字列表示プログラムを書き換えてみよう． まず，以下のような設計にする．

• 文字列の表示用に outlog というスレッドを起動し，文字列を出力したい場合には outlog スレッドに kz_send() によってメッセージを送って「お願い」する．
• メモリ獲得・解放用に kz_memalloc()/kz_memfree() を追加する． 上記メッセージの送信時には，kz_memalloc()によってメモリを獲得する．

ここで，outlogスレッドになげるメッセージを kz_memalloc() によって獲得している (そしてoutlogスレッド側で kz_memfree() により解放している) という点に注目してほしい．冒頭で言及したように， 前々々回の実装では， スタック上に確保している文字列を送っていた． しかしこれは実は問題があって， たとえば文字列表示スレッドにデータとしてスタック上の文字列を送った場合， もしも文字列表示スレッドのほうが優先度が低くて，さらに送信もとのほうが 関数から抜けてしまったりすると，スタックが解放されてしまい， 実際の文字列表示の際にスタック上の文字列が残っているかどうか保証できない． ていうか，たまになんかおかしな文字列が表示されるとかいった， これはこれで原因が特定しにくいバグの原因になり得る． こーいうのはスレッドの優先度構成が変わったり， スレッド間のメッセージのやりとりの手順が変わったり， 関数の呼び出し構造を変えたり関数呼び出しを新たに追加したりすることで 突然発生したりするのでやっかいだ (なのでやはりこれも，冒頭では「問題がある」ではなく 「問題がある可能性がある」という表現をしている)． なので outlog スレッドに送る文字列データは静的なものにするか， kz_memalloc()によって確保したものにする(そして kz_memfree() 側で解放する)かの どちらかになる．しかし文字列データを静的なものにするとして， outlog スレッドを利用する立場(ユーザー側の立場)からすると，

char *p = "message"; /* これは静的領域なのでOK */
kz_send(outlog_id, strlen(p), p);

char p[] = "message"; /* これはスタック上なのでNG */
kz_send(outlog_id, strlen(p), p);

で，前者のような書き方はいいのだけれど，それを見て，何も考えずに 後者のような書き方をするひとが必ず出てくる． 複数人での大規模開発だとこーいうミスはすごくあり得る．

まあそいつの無知といってしまうとそこまでだし， 心配ならば仕様書に注意書きしておけばいいといえばそこまでなのだけど， みなさんはこーいうミスについて，どう考えるでしょうか？

こーいうミスに対して「そんなの，スレッド構成もちゃんと理解せずに， スタックを使ってしまう無知な輩が悪い」 「仕様書に書いてないのが悪い」「仕様書をちゃんと読まないのが悪い」 というのは簡単だし， 実際そーいうことを平気で言ったりする人もいたりするのだけど， ぼくのコーディング時のテーマは「いかに安全に書くか？(自分も，他人も)」 ということであり， (無知の人が無知のままでもいいとは思わないが)たとえ無知だとしても， それによりバグが出ることが予想されるような設計をわざわざすることもない． というか，そーいう設計は積極的に避けるべきだ． 近頃はどこでも開発サイクルはどんどん短縮化されているし，人の出入りも激しい． しかしソースコードの規模はどんどん肥大化している (数ヵ月で数10万行なんて，ザラだと思う)． そのような開発環境で，新しく参加したメンバーでも極力バグを出さなくてすむ， 注意しなければならない事柄を減らす，調べなければならない範囲を狭めるような 考慮というのは，非常に大切だ．

まあこのへんは個人的な考えになってしまうが，ここでちょっとぼくのバグに対する 考え方をだらだらと書いてみるけど，たとえば自動車の運転がうまいというのは， ハンドリングがうまいとか交差点でのコーナリングがうまいとか駐車車両よけるのが うまいとか加速がうまいとか単にクルマの操作がうまいとかそーいうことよりも， 周りの状況がきちんと見れて交通の流れを適切に先読みできる， あの車や歩行者はどうしたいんだろうとか，人の考えていることを読める (良い意味で読める，ということ．勝手に憶測して決めつけるということではない)， 危険を予測できる(駐車車両よけるのが下手ならば，そもそも駐車車両があるだろう ことを予測して，そこには行かないとかあらかじめ距離を取るとかができる)， 前や隣を走っているのがあまり運転のうまくない人でも，事故が起こらないように うまく位置取りができる(もしくはそういう位置取りをさせてあげられる)ように 流れを作れる，とかいったことだと思うのだな． あ，もちろんレースとかでなく，公道で，の話ね． だって公道では，前や隣を走っているのがみんな運転うまい人だとは限らない わけだし，ひょっとしたら初心者かもしれないわけじゃないですか． それでもしも事故ってしまって，万が一大怪我なんてしてしまったとしたら， もうどっちが悪いとか悪くないとか，運転がうまいとか下手だとかいった以前の 問題になってしまうわけです． で，プログラミングも共同作業であるわけで，同じことだと思うのですな．

スポーツでも，ファインプレーがあるうちはまだ２流で， １流はそもそもファインプレーなんぞしなくていいように流れを作る， というじゃないですか． 個人的には，そういう考え方と言うか，周りを見た(他人に優しい)書き方が できないうちは上級プログラマにはなれん！と思う． (言語を扱えるようになっただけでその言語をマスターしたと思ってしまううちは， まだまだ上級ではないというか，先は長いと思う)

ということで，ここでは文字列表示を依頼する側で kz_memalloc() により メモリ獲得し，outlog スレッドで kz_memfree() によるメモリ解放する， という設計にする．文字列表示のたびにいちいち kz_memalloc() して strcpy() するのが面倒だというならば，そのためのライブラリ関数を一個作ればいいだけだ．

で，結局やることは outlog スレッドの追加と kz_memalloc()/kz_memfree() の 追加ということになる．修正後のソースは以下．今回は outlog.c が追加されている．

• ソースコードはこちら

(2009/04/10 ライセンスに関する文書として，KL-01とLICENSEを追加． 詳しくは第43回を参照)

以下は前回からの差分．

• diff.txt

outlogスレッドのメイン処理は outlog.c にあり，以下のようになっている．

int outlog_main(int argc, char *argv[])
{
  char *p;
  while (1) {
    kz_recv(NULL, &p);
    fprintf(stderr, "%s", p);
    kz_memfree(p);
  }
}

サンプルプログラムによって動作確認する．

• main.c

int mainfunc1(int argc, char *argv[])
{
  char *p, *mes = "func1\n";

  while (1) {
    p = kz_memalloc(strlen(mes) + 1);
    strcpy(p, mes);
    kz_send(outlog_id, 0, p);

    kz_timer(100);
    kz_recv(NULL, NULL);
  }

  return 0;
}

なお outlog スレッドはログの表示用に今後も利用する． このように一般的に利用されるようなサービスに関してはスレッド化して， スレッドの機能として提供する，というのがKOZOSの方針でもある．

以下は実行結果．

% ./koz 
func1
func2
func3
func1
func2
func3
func1
func2
func1
func3
func1
func2
func3
func1
func2
func1
func3
^C
% 

• 戻る
• トップページに戻る