メモリ保護されていない世界
いくら言っても通じないので無駄なのですが。
例えば,あの火星の裏まで飛んでいったというVxWorksですら,仮想メモリによるプロセス間のメモリ保護はおこなわれていません。というかスレッド型OSですからプロセスなんてありません。いや厳密に言えばあります,知りたい人は調べてください。使用実績もね。
μITRONも同じです。4.0くらいでMMUによるメモリ保護は登場していますが,ゲンジツのシステムで使っているのはミドルウェアメーカだけじゃないですか?
メモリ保護されていない環境の恐ろしさをいくら説明しても理解されないのが悲しいです。
例えば,自前のアプリケーションはバッチリ書いてあるとします。しかし,メモリ空間が同一である限り,システムコールやいわゆるドライバルーチンが「出来心で」変なアドレスにアクセスした途端,自前アプリのどの変数が突然書き換えられても誰にも分かりません。デバッガでおいかける?それは正解です。ただし全システムのバイナリを対象に追いかけてくださいね。その再現性が半年に1回だったらどうします?
仮想メモリ機構で保護されていれば安心だというのも相当の楽天家です。
システムコールやドライバルーチンにメモリポインタを渡す仕様が1個でもあれば,とんでもない災厄に巻き込まれる可能性があるのです。auto変数で宣言したchar buf[10]; このbufをシステムコールに渡したら,相手がどんな無茶苦茶してくるか分かったものではありません。この10バイトの範囲以外にあふれ出して書き込みをおこなうかもしれません。それはOSやドライバのバグです。しかし誤動作するのはあなたが書いたアプリケーションです。
この根本的な問題についてもう少し真剣に考えるべきです。あまりにもメジャーなOSや環境でのプログラミングがあまりにも当たり前になりすぎました。大勢の人が使うものは鍛えられ,バグも修正されています。特に標準ライブラリなどはOSよりも価値が高いかもしれません。
ではマイナーな環境やOSはどうでしょうか。printfなんて怖くて使えません。しかししょっちゅうバージョンアップ通知が来ます。いくら受け入れテストしても間に合いませんね。自分のアプリがそこそこ動けばOKとする?なんとも呑気な業界ですね。うらやましいです。
だからこそごみためまんはユニットテストの考え方に飛びついたのです。OSのシステムコールや標準添付のライブラリにテスト一式が付いておれば文句は言いません。再帰テストがいつでも可能ですから。
しかし付いていない場合も多くあります。そのときは自分で書きます。アプリの再帰テストも自分で書きます。だったら統一してテストを書けるに越したことはありません。
出荷後にバグが出たら大変などと言いながら,テストを再帰的におこなわない連中のいかに多いことか。モジュールの依存関係があるのに,手前のテストが済んだ後に依存先の不具合を摘出したら手前のテストをやり直すのが常識でしょう?しかし悲しいかな分業の弊害かこれもなおざりです。同一モジュール内においても不具合摘出によるエンバグ対策が皆無です。
おおっとテストの話ではありませんでした。
とにかく,メモリ保護されていようがされていまいが,やるべきことは同じです。メモリ保護されていれば,そのやるべきことを手抜きした結果が多少マシなだけです。はっきり言えば,メモリ保護の有無はOSや環境の性能に関する優劣に関係なんかありません。
まず手元を見てください。マルチスレッドアプリケーションではプロセス内でメモリ保護されていません。これは「妙な挙動をする」「Windowsのスレッドはおかしい」などという風評が出る原因かもしれません。しかしそれはプロセスやスレッドのについての無理解が遠因のひとつです。排他制御がどうのこうのはほとんど関係ありません。
Unix系ならpthreadです。しかしそんな環境依存のものを使わずにプロセスでいいじゃないですか。Windowsよりもコンテキストスイッチが優秀なんでしょう?そうすればメモリ保護の恩恵も受けられます。もちろんそこに慣れた人がWindowsのスレッドプログラミングにイキナリ飛び込めばトラブルメーカになるのは当然です。そして始まるWindows叩きでしょ?
もういちど書いておきます。手元を見てください。WindowsやらLinuxは確かにプロセス間メモリ保護の恩恵のもとで動作します。プログラミングも容易です。ユーザモードのアプリケーションがバグってもOSは滅多に停止しません。しかし,てめぇで書いたマルチスレッドアプリケーションや,OSが提供する共有メモリ機能を用いたアプリケーション内ではメモリ保護は機能しないのです。そこで求められるスキルは30年も40年も前の環境と相変わらず同じものです。配列へのアクセス用のインデクスは慎重に慎重を重ねて取り扱う,ポインタの中の初期化を徹底的に注意する。
そんなばかげたことから開放されるためには,.NETのような仮想化技術が必須となるのです。そしてここに書いてあるような基本的な議論すら忘れている方々を駆逐するためにもそれは必要とされるのです。
組み込み分野においては,実行時リソース不足のためにまだ時間が必要でしょう。いつか終わる予定の技術に若者を投入したって仕方がないじゃないですか。組み込みは時代の最先端なんかじゃありませんよ。デスクトップ業界で使い古された技術を焼きなおして小さな箱に押し込めて抱き合わせで売りさばいているだけの業界です。
あなたがジジィなら,大昔に大型コンピュータで装置や機械制御をおこなっていた時代のことを思い出しているかも知れません。当時は最先端でしたが,「組み込み」ではありませんでした。マイコン登場以後,組み込み業界とは陳腐化したコントローラや開発環境の墓場としてしか機能していないのです。
もし組み込みという世界に宝の山があるのであれば,いずれ誰がその大陸の大部分を支配するかおわかりのはずです。
りんくる:
スレッドの歴史について
ごみためのランキングはこちら。
| 固定リンク
「プログラミング」カテゴリの記事
- VS MS-Word Highlighter2013(2015.07.08)
- テストマシンと環境(2004.02.08)
- Eclipse on Debian(2004.03.02)
- VSSで普通のファイルを管理する その2(2004.06.21)
- WTL7.5をVC6で使ってみる(2004.06.23)
コメント