ます、実行中のプロセスは時計からの割込みによって中 断されます。割込みルーチンを実行する前に現在のプログ ラム・カウンタ ( (C) をとっておかなけれはなりませんが、 並の CPU なら PC ( を含むレジスタ群 ) は自動的にスタッ ク上に退避されるようになっています。また、割込みによ って CPU はシステムモードになり、同時にスタック・ポイ ンタが切り替わるようになっているので、レジスタ群の退 避にはユーザーのスタックはそのままにしてシステムのス タック領域が使われるようになっています。ここで、退避 されるレジスタ群のなかにユーサープロセスのスタック・ ポインタが含まれていることを頭の隅にでも留めておいて ください。 この段階でプロセスのもちものはすべてセープできてい るので、 OS のコードは思う存分に資源を使えます。しか し、前回述べたようなメモリマッパの機能を備えたハ ウェアの場合はメモリのマッピングがもとのプロセスのま まですから、 OS 動作のためのマッピングに変えなければ なりません。とはいえ、このごろの CPU ( メモリマッパ ) は システムモードの場合だけ特別なマッピングを自動的に出 してくれるものがほとんどですから、難しいことは何もあ りません。たとえハードウェアがそうなっていなくても、 マッピング・テープルの 0 番をシステムのためにリザープ するなどして、 OS のためのメモリマッピングだけはすぐ に得られるようにしておくのが常套手段です。 さて、 OS にはいろいろやることがある ( と表向きにはい われていますが、実時間 OS などではスケジューリング以 外にやる仕事などほとんどないといっても過言ではありま せん : ー ) ) でしようが、ここでの肝心な仕事は次に実行する プロセスをみつけてそれを正しく再開することです。 次に動かすプロセスを決定することを、、スケジューリン グ (scheduling)" といい、その決定には待ち状態に入った 順番、優先度、休んでいる時間などをパラメータとするい くつかの有名 ( 常識的 ? ) な方法があります。しかし、僕と しては、 ・動いているプロセスはいつかは止まる ( 止められる ) 。 ・緊急度が高いプロセスはなんとしてでも優先して実行 しなければならない。 ・緊急ではないプロセスはいつか動けばまったく問題ない。 UNIX MAGAZINE 1990.12 ということから、緊急でないプロセスはいつかかならす実 行されるならどんな方式でもいいと思っています。 UNIX のプロセス・スケジューリングがかなり単純なラウンドロ ピン方式 ( 素朴なものです ) だということは有名です ( でも、 僕はソースを読んだことがないので実際のところは保証し かねます ) 。 で、 OS はひととおり動いたあとおもむろに次のプロセ スを再開します。そのときには、そのプロセスのレジスタ 群を復帰し、スタックをそのプロセスのものに切り替え、 さらにメモリマッパがあればマッピング・テープルもセッ トしなければなりません。ただし、スタック・ポインタも レジスタの 1 つですから、レジスタ群が正しく復帰できる のならスタック・ポインタをとくに意識して扱う必要はあ りません。 プロセス中断・再開の実装と小技 話が横道にそれてしまいますが、プロセスの中断・再開 のところを詳しくやりましようか。これはどちらかという と職人的な話で問題の本質とは離れるようですが、ハッカ ーというものはこういう部分をいちばん面白いと感しるよ うですし、実際、道を歩いていてこのあたりのことを質問 されたりするものですから。物事の本質なんて、こうした 一見しようもない小技のようなところに隠れているものか もしれません・・・ プロセスが時計の割込みで中断された場合、 CPU のハ ードウェアによってレジスタ群が自動的にシステムスタッ ク上に載ります。それをそのままにしておいてもいいので すが、それではなにかと作業しにくいのですぐにそのプロ セスの管理用構造体に移します ( 管理用の構造体はもちろ ん OS のなかにあるもので、プロセスの生成時に初期化し てあります ) 。 このとき、スタックはスタック・ポインタ相対でアクセ スします。 C なら、ローカル変数のポインタをとって、そ れにいくらか足してアクセスすることになるでしよう。で、 いくら足せばいいのかを計算するのは面倒くさいので、実 際には割込みルーチンですぐにワーキングエリアへコピー しておくのが安直でお手軽です。ここで、レジスタ群がど れだけあるのか ( どれだけセープするべきか ) やどのレジ スタがスタック上のどの位置にあるかは CPU のアーキテ 111

マジカル・ミステリー・ツアーいたしましょ・ クチャに依存しますから、いくら C で書いても別のアーキ テクチャのマシンへ移植するときには書き換えなけれはな りません。プロセス管理用の構造体の大きさやメンバーも おのすと影響を受けます。 プロセス中断には技といえるほどのものはありませんが、 中断したプロセスの再開は職人的ともいえます。スタッ ク・ポインタとプログラム・カウンタの値を変えながら飛 んでいくというのは、 CPU の作りによって多少の差はあ るものの、けっこうトリッキーでハッカーの心をくすぐる ものです ( 最近ではシステムスタックが別にとられるよう になったので、面白味が滂咸してしまいました ) 。 68030 版 Cinnamonl のプロセス再開は、 68030 の RTE (Return from Exception) 命令でおこないます。 RTE は、スタックトップにあるレジスタ群をドッカーンと全部 レジスタ群に復帰してリターンするというものです。 レジスタ群にはプログラム・カウンタやスタック・ポイ ンタも入っていますから、何も考えなくてもおしまいです。 もしここでシステムスタックとユーサースタックが分離さ れていないような CPU ( Z80 など ) を使っていれば、ユー ザー空間をどれだけ汚さすに作業できるかが腕の見せど ころで、ぎりぎりまでスタック・ポインタを切り替えずに 作業するところにハッカーや職人の技が発揮されます。も っとも、今ではこんなことを自慢できる CPU ははとんど ありません。プログラム・カウンタもスタックから取り出 してセットされるだけなので、、、リターン〃するというより はちょうどスタックに置かれた番地に、、ジャンプ〃すると いう感しになります。 ハッカーとしては、 RTE が受け付けるような形式でシ ステム・スタック上に偽のスタックフレームを作り、それ を 68030 がまんまとだまされて取り込み、「リターンした ぞ」とばかりに次のプロセスの実行にかかるのを見守るこ とになります。 RTE は CPU に依存していますから、この あたりもいくら C で書いたところでアーキテクチャ依存の コードとなります。また RTE などという命令は逆立ちし ても UNIX の C ではだませませんから、 asm ( ) のお世話 になるのが普通でしよう。 僕のようなマイコン小僧にとっては、このようにスタッ クをごそごそいしってそれを CPU に喰わせるというのは 1 ウインドウ端未の内蔵用に開発された実時間指向の OS 。詳細については、本誌 1989 年 10 月号「 Cinnamon オペレーティング・システム」を参照。 112 日常的な感覚なのですが、はしめに OS ありきの世界でや ってきた人間 ()S 小僧とでもいうんでしようか ? ) にはか なり危なく見えるようです。たとえは、 Cinnamon を実装 ( もちろん、今日の話題のプロセス・スイッチのあたりを含 む ) した同僚は当時からすでに十分ハッカーでしたが、 「 CPU はもっと複雑なステート (" さっきの割込みで、俺様 はこのへんに情報をセープしたぞなどという情報 ) を内部 で保持しているのではないか ? だったら、勝手にへんなも の ( 偽のスタックフレーム ) を喰わせるとゲリするんしゃ ないか ? そんなものを喰わせては、 CPU 様に対して失礼 ではないか ? 」と案していたものです。僕は「そんなケッ タイな CPU 作っても、誰も買わへんで。けど、モトローラ やったら何が起こっても不思議ではないな。たぶん大丈夫 やけど、注意してやろうか」と、真面目とも不真面目とも とれる返事をして励ましたのでした。 これとは関係のないことですが、「いらないもの ( 誰も使 ったことがないもの ) にさわるな」というのも僕の持論で す。実際、この禁を破って MSP(Master Stack Pointer) にさわった人もいますが、 68030 は気が狂ってしまったよ うです。 ICE もなかったので詳しいことは分かりません が、僕には CPU が間違っているようにしか思えませんで した。ちなみに、このとき使用していたのは XC68030 では なく MC68030 でした。 setjmp() 、プロセス、スタック さて、めでたくプロセスの中断と再開ができるようにな ったところで、プロセスの実体とレジスタ群の話に戻りま す。 ところで、レジスタ群をそっくりセープするというのは、 setjmp ( ) と同しではないでしようか ? setjmp() という のは、プログラム・カウンタやスタック・ポインタもセー プしておき、 longjmp ( ) したときにそれらをいっぺんに戻 すというものです。そうすれば、プログラム・カウンタは setjmp ( ) したところに戻るのはもちろん、スタックもちゃ んともとどおりに縮んでくれます。そして、それで必要十分 なのです。 プログラミング言語を作ろうとしたことがある方には分 かると思うのですが、スタックを縮めるというのは意外に 難しくて、インタープリタ言語のエラーの処理や Pascal UNIX MAGAZINE 1990.12

・ 0 あ 0 朝を物寺の朝 竹岡尚一 マジカル・ミステリー・ツアーいたしましよ④ プロセスを実行する実体の巻 ソフトウェア屋が世界を制覇する 最近では、 ASIC とかいうもので LSI がお手軽に作れる ようになっているようです。シリコン・コンパイラも実用 的に使えるものが増えていて、ほくも 88000 のキャッシ ュ・コントローラを作ったシリコン・コンパイラを見せて もらいました。驚いたことに、ほとんど C のように書いて おけば、 ALU が生成されてユニットがどんどんつながっ ていくというもので、もう呆れるばかりです。別な折に ASIC メーカーの方と話す機会があったのでいろいろ訊 いてみると、民生用電化製品向けの ASIC の世界でもつい 最近になってシリコン・コンパイラが使われるようになっ てきたのだそうです。では、真のハードウェアのプロはど うしているのでしようか ? そのあたりを訊ねると、今でも CAD に向かってゲートをつないでいる人はちゃんといる のだそうで、ひと安心した次第です。 でも、ハードウェアのプロ中のプロが大規模で複雑なハ ードウェアを ( もちろん CAD に向かって ) 作るとどうし ても 2 ~ 3 箇所は間違いがあるものなのに、シリコン・コ ンパイラでははしめたばかりの人が式を書き上げたら動い てしまったのだそうで、これには ASIC メーカーの人もび っくりしたようです。 図的言語が情報を把握し難いというのはよくいわれる ことなので、僕もべつに驚きはしませんでしたが、初心者 のような人が式を書くだけで LSI が作れるというのはシ ョックでした。これからは、アプリケーションやソフトウ ェア側の人がソフトウェアの都合で LSI をちょいちょい と作ってしまう時代が到来するのでしようか。それならそ れで、マイコン小僧にも LSI を作るチャンスがやってくる 110 わけでそれなりに楽しみですが、神聖 ( ? ) なハードウェア のプロの世界がまた侵されるのかと思うと、ロマンが減っ てしまうようでちょっと淋しいですね。 プロセスのほんとうの実体 ? ? 前回は「プロセスの実体」と題して話をしましたが、プ ロセスのメモリ管理についてしか言及しませんでした。あ れだけを、、実体〃といったのでは、良心が痛んで夜も眠れ ません ( 痛むだけの良心か残っているとしてですが :-P)O そこで、今回は、、プログラムを実行してくれている実体〃 ( なんという情けない日本語だ ) について話したいと思いま す。前回にもすこしだけ触れましたが、 ・スタック ・レジスタ ( プログラム・カウンタとスタック・ポインタは 必須 ) はプロセスの実体の構成要素である、ということです。 単一 CPU の時分割システムを 考える 時分割をおこなう場合、プロセスはどのように切り替え られるのでしようか ? こでは、プロセスの実体を直接考えていく代わりに、 並のマイクロ・プロセッサを ( 68020 や 80386 ーー今どき SPARC や MIPS でないものが並といえるだろうか ? ) 単一 CPU として使っているハードウェアでの時分割シス テムの実行の様子をみていきます。皆さんも OS や CPU になった気持で考えてみてください。 UNIX MAGAZINE 1990.12

0 ee Auspex カ材来、われわれの要求と予算に見合った小さ くて低価格のサーバー製品を発売するよう望ますにいら れない。このシステムのおかげで、きわめて高いスルー ブット値を得し、サーバーをまったく意識せすにロー カル・ディスクと同程度の個別的なデータ転玉度を得 ることができた。 Auspex サーバーは高額であるが、そ れに見合うだけの性能を示している。現時点では、 Auspex はネットワーク接続された多数の Sun ワーク 製品評価ーーー from UNIX REVIEW LynxOS あらゆる機能を備えたリアルタイム・モニターと豊富 な機能を備えたリアルタイム UN Ⅸは、過去 2 ~ 3 年 のあいだに着実に増加しつつある。リアルタイム・モニ ターと UNIX システムは、一定の時間内に確実に外部 イベントに応答しなければならないという点では同しだ が、リアルタイム・モニターはスタンドアローンの組込 みシステムに向いている。一方、さまざまな、、標準〃ュ ーティリティを備え、ネットワーク環境をサポートして いる UNIX は、リアルタイム・アプリケーションの開 発、テスト、実行に共通のプラットフォームを提供でき る。 こでは、 POSIX P1003.1 標準およびその拡張であ る P1003.4 リアルタイム標準 (Shane P. McCarron 「標準イ師力向 : リアルタイム拡張」本誌 1990 年 11 月号 参照 ) に適合したリアルタイム UNIX OS である LynxOSV1.0 をテストする。評価を始める前に、リア ルタイム・モニター、 UNIX およびリアルタイム UNIX の違いを簡単に説明して読者がそれぞれに描な環境に ついてより深く理解できるようにしよう。 UNIX 一般的にいって、 UNIX は大部分のリアルタイム・ア プリケーションには不向きである。多数のべンダーがリ アルタイム用の拡張を施したバージョンの UNIX(HP の HP-UX 、 Concurrent の RTU など ) を提供してい 30 ステーションをもつ顧客をターゲットにしている。多機 種間のネットワークにおける NS5000 の使用経験は、非 常に肯定的なものであった。はとんどすべての NFS べ ースのネットワークにおける大規模な中央サーバーとし て、われわれは強く NS5000 を推奨する。 「 The Auspex NS5000 FILESERVER 」 UNIX REVIEW 1990 年 8 月号より by Robert Bauer るが、残念ながらこれらの UNIX システムでは市販さ れている既製の UNIX ソフトウェアは動かない。これ らのシステムに不舞葮されたか、これらのシステムのために わざわざ開発されたアプリケーションが必要なのである。 UNIX のカーネルはプリエンプテイプではないので、 すべてのシステムコールが最高の優先度で実行される。 したがって、最低の優先度しかもたないプロセスからの システムコールでも、完了するかプロックされるまで実 行され続ける。システムコールが最高の優先度で実行さ れているために、外部イベントは UNIX にその時点で の活動を中断させることができす、 UNIX のほうは外部 のイベントに応答できないのである。この結果、イベン トが失われてしまったり、保証された時間内にサービス がおこなわれないなどの事態が生しる。 UNIX のプロセス覚醒方法は、リアルタイム・アプリ ケーションにとって非常にやっかいである。 UNIX はシ グナルを待っているすべてのプロセスを起こすので、シ グナル捕競争が始まってしまう。言い換えれば、その シグナルを待っているプロセスの覚醒は統計上でしか 保証されないのである。 また、 UNIX の公平なスケジューリング・アルゴリズ ムは、いかなるプロセスもほかのプロセスより多くシス テムを使用するべきではないという考えにもとづいてい る。これは、リアルタイム・アプリケーションの性質と は対極にある。リアルタイム・アプリケーションでは、 ある 1 つのプロセスが長時間にわたって休眠状態にある UNIX MAGAZINE 1990.12

系言語の大域脱出などになかなか苦労させられるもので す。僕は C の言語仕様の setjmp() や longjmp() をみて、 しかもそれがライプラリであることを知ったとき即座にそ の実装に思い当たり、エレガントさと簡潔さに感動しまし た。今でも、 C のいちばん偉いところは setjmp() と long jmp ( ) であると思っているくらいです。 その偉い setjmp() ですが、これはなぜプロセスになれ ないのでしようか ? もちろん、そういう意図で作られたも のではないからプロセスになれる必要はありませんが、 setjmp ( ) からプロセスが生まれないのは longjmp ( ) と プロセスのあいだに決定的な相違があるからです。それは、 longjmp() したときにスタックが縮んでしまい、 setjmp ( ) 以降にできたスタックは完全に捨てられてなくなって しまうことです。もし、 longjmp ( ) してもスタックを含む 環境全部か破壊されすに残ったとしたら、リスト 1 のプロ グラムのようなことが可能になるでしよう。 ます、 f( ) か呼ばれ、次に g( ) が呼ばれ、さらに longjmp (processl) して He110 〃と打ち、次には longjmp(proc ess2) して、、 WorId 〃と打ち、以降は、、 He110 〃と、、 WorId 〃 を交互に打ち出し続ける・・ こういうプログラムは、ハッカーなら誰でも一度は考え そうです。でも、 C ではこれは動きませんね。なぜなら、 f ( ) のなかから longjmp(scheduler,l); を実行したとた んに f( ) のスタック・フレームはきれいさつばりなくなり、 変数 processl の中身はまったく意味のない情報になって しまうからです ( 正確には processl のスタック・ポインタ が無意味になるだけです ) 。そして、みんなそれに気づいて 諦めるのです。 setjmp ( ) や longjmp ( ) は大域、、脱出〃の ためのもので、自由自在に飛ぶようには作られていないか らこれでいいのです。でも、もしこんなプログラムカ働く ならはもうちょっと頑張って汎用のスケジューラカ嘯けそ うですね。 では、こうした動きを可能とするにはどうすればよいで しようか ? そう、スタックがなくならなければよいので す。そして、この例よりもうちょっとましな使い方ができ るようにするには、スタックは伸びるようにもしなければ なりません。上の例だと、 processl は関数 g()( つまり process2 ) のスタックに押えられてスタックを伸はすこと ができませんからどうにも貧弱です。 こう考えてくると、スタックがなくならす、かつ自由に UNIX MAGAZINE 1990.12 リストー #include く stdio. h> #include く setjmp. h> jmp-buf scheduler,processl ,process2 ; switch(setjmp(scheduler) ) { maln() case 0 : case 1 : case 2 : case 11 : case 21 : f() ; break; g() ; break; longjmp(processl , ー 1 ) ; 10ngJmp(process2,—1) ; break; longjmp(processl , ー 1 ) ; break; break; if (setjmp(process2) ) { printf ("Wor1d\n") ; longjmp(scheduler, 21 ) ; longJmp(schedu1er,2) ; if (setjmp(processl) ) { printf ( " He110 \ Ⅱ " ) ; longjmp(scheduler, 11 ) ; longjmp(scheduler , 1 ) ; 113 式的に扱うために考えられたコンティニュエーション る方も多いでしよう。で、その Scheme には大域脱出を形 にも MIT の C-scheme が入っているので知っておられ をとり上げてみます。これについては、 GNU の配布テープ こで、 Scheme という Lisp の方言に分類される言語 スと無関係だとはいっていられないのです。 るでしよう : ー ) 。しつは、 setjmp() と longjmp ( ) はプロセ まいました。かわいそうしゃないか、と思われる向きもあ なさそうな setjmp ( ) や longjmp ( ) を引っぱり出してし さて、プロセスの話をしているというのになんの関係も 恐るべし continuation 占めていることがお分かりいただけたでしようか ? うことで、スタックがフ。ロセスの実体として大きな位置を たく別な場所に用意するのがいちばんよさそうです。とい 伸ばせるようにするには、スタックをプロセスごとにまっ

HP SoftBench プログラム・テパッガでのプログラム実行の様子 図ー ア 0 ム・デバ烹が第“ - を物 Fite ・朝 E 一応 Tr•ce 権単 プレーク第イントを設を ルハ城ー ( Ⅳ . F 億物 材・地 . 「 ( 維ー物 . 0. お 5 疉 h は物町日“・ ( 印 1 . ド工 ) : ′ ( ファイルカで・ません ) : ー“ール : ( ど ドプレーク・イント載 IO - 物し・ 07 0 、ー - 物「の・ 0 0 22 : 0 一 ー「・ 07 興 1. を - 物 t- ーめ・ 0 ? 物 0 イ第 0 馳 . ( の -- 物ゴ 0 ・に 純 . ←電 .3 い 0 ( い興 - - ′ 0 ・興物 3 : 0 第 0 0 耘」 4 : 0 “儺刈 - 動 . す 0 ・ 824 0k0 浦い 24 0 イ′盟 0 、ル ) い お ? : 0 メ网料北 物 : 0 、′応ⅱ費 国物メ 0 0 、 ( ′物 0 第 ( を物 11140 0 興Ⅸ料 0 韓 ) 3 : 0 ⅱ聞 . 御物 0 ” 0 0 、 1 日驂 -4 ・メ 0 0 ′ ) ン X 、 ウインドウに移ったり、プロセス ID やシグナル番号を調べ にデバッガが処理しているシグナルの状態まで、必要ならは すべてを同時に調べることができるのである。これらはそれ たりしなくても実行できる。 ぞれのウインドウに表示されるため、従来のター ミナノレベー プログラム・デバッガのユーザーはプロセス ID を知る必 スの HP ー UX デバッガのように表示スペースの大きさによ 要はほとんどない。これは、アプリケーションにシグナルを 送るときや、すでに実行中のプロセスをアドプトする場合も る制約を受けることはない。 同様である。プロセスの生成時に ID 番号を記憶しておくと もっとも大きな特徴の 1 つは、 HP ー UX デバッガとデバッ いうタスクや、プログラムの名称を用いてプロセスの ID 番 グ中のプログラムの I / O ストリームを別個のウインドウ・ペ 号を ( / bin / ps から ) 調べるというタスクは、いすれも自重加勺 インに分離したことである。これによって、ユーサーはデバ ッガのコマンドやプロンプト、出力などのまぎらわしい表示 に処理される。 の区別に煩わされることなく、プログラムが何を実行してい 標準の HP-UX シンポリック・デバッガは、プログラムの るのかを調べられる ( 言求もできる ) 。このような表示内容は 変数の値のモニター機能については最小限のサポートをして それぞれスクロールと編集ができるので、ユーサーは前の工 いるだけだ。各命令の実行後に値を表示するアサーションを ントリを見直したり繰り返し調べたりすることが可能にな 設定したり ( ただし、実行速度は遅くなる ) プログラムのなか の特定の位置で値を表示させるプレークポイントを設定す っている。 ることはできるが、それだけでは多大な推測 ( と退屈な作業 ) 付加価値 を要する。 HPSoftBench プログラム・デバッガでは、トレ プログラム・デバッガは HP SoftBench の分散型サポー ースしたい変数をユーザーが指定することが可能であり、い ト・メカニズムを使用して実装されているので、ユーザーは くぶん複雑なプレークポイントとアサーションを組にして、 よけいな作業をしなくても、プログラムのデバッグをはかの 単純ながら多くの場合に有用な変数トレース機能が実装され マシン上で実行させたり、分散したソースファイルを使用し ている。 たりすることができる。プログラム・テンヾッガは、 HP-UX ツーノ吏用の自動化 デバッガを対象マシン ( 実行可能ファイルが存在するマシ ン ) 上で起動するように取り計らうとともに、必要なプロセス HPSoftBench のツール統合アーキテクチャにより、各ツ 間コミュニケーションをすべて確立する。このデバッガで ールは要求メッセージと通知メッセージによって互いにコミ は、複数のプロセスがネットワーク上で分散処理されるよう ュニケーションをとることが可能となっている。現在の HP SoftBench ツールはかぎられた内容の要求メッセージしか な場合のデバッグはできないが、多くのユーサーの分散型デ 出していないが、プログラム・デバッガのようなツールを人 バッグへのニーズは満足する。 シグナルハンドラをもつアプリケーションのために、プロ 間ではなくプログラムによって完全に制御することは可能で グラム・デバッガは特別なウインドウを備えており、ユーサ ある。たとえば、ツールの作成者は HP Encapsulator を利 ーからシグナルの受信をモニターしたり、各シグナルを特別 用してスタティック・アナライサとプログラム・デバッガに 要求を出す高レベルのツールを作成することもできる。この に処理したり、あるいはアプリケーションに特定のシグナル を送れるようになっている。このような操作は、ターミナル・ ようなツールは、プログラムのデータ構造の参照と変更をモ 77 UNIX MAGAZINE 1990.12

連載 An lntroduction tO X Window System 中村眞 ネットワークの活用 ネットワークと X 何回も繰り返してお話ししてきたように、 X はアプリケ ーション・プログラムを実行する、、クライアント〃と、表 示やキーポード、マウスの入出力を司る、、サーバークから 成り立っています。 X におけるネットワークは、このクラ イアントとサーバーのあいだに存在するものですから、今 日のワークステーションとネットワーク主体の分散環境 下で上手に X を活用する方法を考えてみましよう。これま で書いてきたことと多少は重複するところもありますが、 おさらいも兼ねて解説します。 ワークステーションを使い始めたはかりのときには、ネ ットワークを利用するのは限られた場面でしようし、ウィ ンドウを使うといっても自分のワークステーションを中心 とするケースが多いようです。このような場合、ネットワ ークのためのワークステーションの基本的な機能 1 は活用 されてはいるが、遠ド融也との通信というよりも独立した ( 親 子の関係のない ) プロセスを結ぶ、いわゆるプロセス間通信 として用いられていることになります。 X 端末のユーサー は、ウインドウを使う際、知らす知らすのうちにネットワ ークを使っています。というのも X 端末自身ではクライア ント ( アプリケーション ) の実行はできないので、接続した ネットワーク上のどこかにかならすクライアント実行のた めの計算機が必要となるからです。それでも、利用し始め たときにはクライアントを実行している計算機は 1 つで す。 1 BSD UN IX のネットワーク機能実現のために用意された socket ライプラリ こで説明するようなプロセス間通信として です。ネットワーク実現のはか、 も活用されています。 UNIX MAGAZINE 1990.12 とくに必要がないかぎりあちらこちらの計算機を使う 必要はないでしようし、ウインドウ・マネージャーのポッ プアップ・メニューで新たなクライアントを起動する場合 も、そのウインドウ・マネージャーと同し計算機上での実 行が中心になりますからこれも自然ななりゆきといえます。 しかし、ネットワークを使い慣れるにしたがってネットワ ークを意識した X の利用法を考える必要が生してきます。 ネットワークの基本 ネットワークと X とは関連が深いものですから、利用、 それもとくに管理面を考えるとネットワークの基礎知識 が前提になります。ただし、ネットワークの利用や管理に ついてはそれだけで 1 冊の本が書けてしまうほど奥が深い ものです。そこで、 こではワークステーションでのネッ トワークの基本について簡単に触れるだけにとどめておき たいと思います。 ホスト名とは ネットワークに接続された計算機とお話をするには、そ れぞれを個別に認識する仕組みが必要です。それも、、、どこ の誰それ ' ′と一意に決まる名前を利用できなければなりま せん。 基本的なメカニズムでは、各計算機に固有の番号か割り 当てられており、これに人間が扱いやすい名前を付けるこ とによって個別名を実現しています。ワークステーション の世界で普及している TCP/IP では、 IP アドレスと呼ば れる番号で管理されています。また、この番号は個々の計 算機 ( ネットワークでの接続先という意味でソード〃と呼 ばれます ) を認識するために使われるはか、その数値の上位 139

NIX 語講座 桑原啓次郎 UNIX 歴史探訪 ( 2 ) 今回も、、歴史探訪〃の続きである。 という ( たいていのシステムでは書込み禁止になってい る ) 番地に値を書き込もうとするためだ。仮にその番地カ嘯 込み禁止になっていないシステムでも、奇数番地に int( 通 常は 32bit) を書き込むことは CPU によって禁止されて いることが多く、これもコアダンプの原因となる。 と、まあそんなことはどうでもいい。 core は、会話では 「 Shit ! This program dumped core again ! 」 ( ちえ、 coreC コア ] いつまたコアはきやがって ) のように dump を動詞として 使うのが正統的とされている。しかし、「 This stupid pro- 普通の英語では果物の芯、中心、中身、本質といった意 gram coredumped again ! 」 ( このバカ、またコアダンプ 味だが、 UNIX 界ではプロセスイメージのこと。 してやがんの ) のように coredump を 1 語として使うこ 「昔々、 LSI 式のダイナミックメモリ (D-RAM) が出現す ともできる。こういう言葉遣いができれば、 UNIX 界のべ るより前、コンピュータがトランジスタでできていたころ、 テランの雰囲気が醸しだされ、尊敬されること請合いであ 記憶装置としてはコアメモリが主流でした。これは筒型を る。さらにハッカーどうしの会話では、人間もコアダンプの した小さな小さな磁石 ( コア ) を格子状ににたくさん配置 して、磁石の穴に X 方向と Y 方向にそれぞれ 1 本ずっ電線 対象になり、「 Could you give me coredump on this matter? 」 ( この件、ちょっと俺にコアダンプしてくれな をとおしたような構造をしていました。穴に電線をとおす い ? ) と何かの説明を求めたりする。このように coredump 仕事は女工さんが 1 本 1 本手で月精込めてやったというこ とです。このため、いつのころからか UNIX 界ではこのコ が使えるようになると、君も本当のハッカーの仲間入りだ。 アメモリに蓄えられたビット列そのものを、、コア″と呼ぶ GCOS [ ジーコス ] ようになりました」 ( MHK 教養講座「メモリの変遷」より ) で、 UNIX には、プログラムが暴走したりして一般のプ GE の大型機用オペレーティング・システム。 GE という のは General Electrics という米国の〇菱みたいな会社 ログラムカ艚いてはいけない番地にデータを書こうとした で、電球から原子力発電所まで何でも作っている。昔、大 りすると、その時点で強制的にプログラムの実行を止める 型機が普及し始めたころ、この会社も独自の大型機を作っ 機能がある。これが起こると、通常はその時点のプロセスイ て専用の GCOS という OS を開発したにの GCOS は メージをファイルに掃き出し、あとで adb や dbx などと いったデバッガで調べられるようにしてくれる。このファ NEC の ACOS に引き継がれている ) 。それが、いったい UNIX とどんな関係があるのかって ? イルの名前は、コアのもっ歴史的業績を讃えて core に固 /etc/passwd というファイルはご存しだろうね ? これ 定されている。そして、掃き出す行為自体は core-dump と はシステムにユーザーを登録するためのファイルで、 1 行 呼ばれる ( dump はダンプカーのダンプ。廃棄する、という ごとに 1 ューザーの情報が入っている。たとえば、筆者の 意啝 1 語にして c 。 redump と書くこともある ) 。 コアダンプを試すには、次のようなプログラムを書いて 工ントリーは、 実行してみれはいい。 kuwa: fRyf6 : 65 : 10 : K Kuwahax 、 a: /home/kuwa: /bin/csh main(){ static int のようになっている。このヾ : 气コロン ) で区切られた 5 番 目の項目 ( 、、 K Kuwahara" の部分 ) が GCOS フィールドと呼 ばれている。古代 UNIX が GCOS と接続されて使われてい たぶん、はとんどのシステムでこのプログラムはメモリ たおり、何か GCOS に関係ある情報がここには書かれてい アクセス・エラーとなり、 たのだろうが真相は謎である。現在ではここに名前や電話 Segnentation fault (core dumped) 番号や所属を書くのが決まりとなっていて、 Mail コマン ドなどがここを読んで自動的に送り主の情報を付加するの のようなメッセージが表示されるだろう。 ls をとってみる に使われるのみである。まさに、栄枯盛衰のきわみといえ と、 core という名前のファイルが見つかるはすだ。 よう ( どこが ! ? ) ( くわはら・けいしろうバークレイ在住 ) このプログラムがコアダンプするのは、メモリの 1 番地 145 *p=(int * ) 1 ; UNIX MAGAZINE 1990.12

第 e $ & 第 0 ee 0 ce プロセスから抜け出すための安全な方法であることも分 かった。 コスト・ / ヾフォーマンス UNIX MAGAZINE 1990.12 もに供給されるマニュアルには該当する記述がない ) 。し いないコマンドが多数ある ( すくなくとも、システムとと 書かれている。残念ながら、ドキュメントに記載されて 較的完成度の高いものであるし、おおむね分かりやすく タイム・プログラマーはかならすしもそうではない ) 、比 UNIX のエキスパートであると想定しているが、リアル に入らない点があるが ( システムを使う人は誰であれ な製品となっていることが分かった。マニュアルには気 LynxOS は傑出した技術サポートに支えられて、堅実 総合謌面 くなる一方であるものと信したい。 グ・アルゴリズムを開発し続けている。この OS は、よ を抱え、その研究グループはよりよいスケジューリン Lynx は頻繁に改訂をおこない、優秀な技術スタッフ がかさむうえに複雑なものになってしまう。 をホスト環境から受け取る組込みシステム ) は、コスト 適なシステムになるであろう。別の方法 ( 、、プログラム〃 せれば、大規模なリアルタイム・アプリケーションに最 LynxOS をインテリジェントなセンサーと組み合わ ある。 SLIP を含む TCP/IP?NO ッケージの価格は 495 ドルで ランタイム版は 495 ドルである。 Ethernet ドライバと X ウインドウ開発パッケージの価格は 795 ドルで、その ーゲット・システムに対するライセンスが含まれている。 ROM キット版は 2 , 295 ドルであり、これには 2 つのタ ンは 995 ドルである。組込みアプリケーションのための 版は 1 , 295 ドルで入手できる。カーネルのみのバージョ カーネル、シェル、ユーティリティを含むランタイム ーのそれと比べてもきわめて安い。 UNIX の高い機能を備えていないリアルタイム・モニタ は 1 , 495 ドルときわめて安価である。この価格設定は、 パッケージを含む完全な LynxOS 開発システムの価格 カーネル、シェル、ユーティリティ、プログラム開発 かし、これらのコマンドはめったに使われないものであ り、興床をもった人には Lynx が説明してくれるはすで ある。 多数のデバイスを制御したり、通信が必要になったり するプロセス制御アプリケーションのためには LynxOS は傑出した製品である。しかし、データ・ロギ ング以外の低レベルの制御機能と測定機能のためには Lynx は大きすぎるシステムかもしれない。コスト・パフ ォーマンスからいえは、 Lynx システムと通信できる小 さなリアルタイム・カーネルのほうがはるかに優れた解 決カ怯だし、考えられる最悪の条件において正しい操作 がおこなわれることを実証するために必要な努力を軽減 できる。 Lynx は UNIX との完全な互換性を提供し、任意の タスクの優先度変更、カウンティング・セマフォの実装、 タイムアウト機能、かなりよくできた逆アセンプラなど、 重要かっ必要なリアルタイム用の拡張か施されている。 さらに、データの収集や配布をおこなうアプリケーショ ンのために、 LynxOS は連続ファイル作成機構を提供し ている。 LynxOS はもともと、 68000 プロセッサ・ファミリー をベースとしたシステムにリアルタイム機能を提供する ために開発されたものである。そして、さらに遡ればそ の起源はあきらかに 80386 にある。このシステムでは、 フラットなアドレッシングと本来は 68000 用に設計さ れた C コンパイラに 80386 用の変更を加えたものを使 うことによって生しる難しいセグメンテーションの問題 は考慮されていない。その結果、 C コンパイラによって 作成されたオプジェクト・コードにリンクできるアセン プリ言語ルーチンを開発するためのサポートはまったく 提供されこいない。もっとしアセンプラのプログラミ ングは、、死にかかった提去′′なのでこれはさほど大きな 問題ではなく、また Lynx の技術サポート担当者と相談 すれば解決できるであろう。 マルチューサー、マルチタスクの UNIX 互換 OS と しては、 LynxOS は驚くほど応答性のよいシステムであ る。これは割込みとタスク・ディスパッチ遅延が少ない ことによる。 Lynx には TCP / IP が組み込まれており、 ほかのネットワーク・インターフェイス (). 25 、 MAP 、 Ethernet) もサポートしているので、 4.2BSD 、 SVID 、 35

地 e $ & 0 ee 0 ce ァイル構造を使っているので tar フォーマットもかな り違う。 互換性の問題を解決するために、 Lynx は SystemV 互換の tar を提供している。これによって、 SystemV か ら Lynx ( あるいはその逆 ) の変換が可能である。出力 は、 Lynx 用の tar システムにパイプを通して流し込ま なければならない。これは比車知勺簡単でマニュアルにも 詳しく書かれているが、気がっかなければ混乱のもとに なりかねない。 性能 リアルタイム・プログラマーとしては、 Lynx が公称し ている芯時間が本当の数値なのかどうかを知りたかっ た。そこで、 PS / 2 上のシリアル・インターフェイス用デ バイスドライバを書いてみた。このデバイスドライバは、 入力されるすべての文字について待機プロセスにシグナ ルを送る。これは、割込みからタスク・ディスパッチま での遅延時間を調べようという考えにもとづくものであ る。 驚くべきことに、評者の 16MHz のマシンでは遅延は いかなる負荷条件のもとでも 300 s を切っていた ( 24 s 前後であることが多かった ) 。これは、われわれ が使用している普通の UNIX における lms 以上 ( もっ と悪いことが多い ) に比べてはるかに優れている。はかの 種類の外部イベントの場合、さして大きなオーバーヘッ ドをともなわすにイベントを確認する応答が送れるので、 割込み遅延時間は最悪の場合でも半分以下に短縮できる であろう。 タスク・ディスパッチ遅延時間はある瞬間におけるタ スクの優先度の関数なので、非常に変化が大きい。その タスクの優先度が最高であるならば、遅延時間はつねに 500 s よりも小さいことになる。これらの遅延時間は、 イベント指向のほとんどのアプリケーションにとって十 分なものだし、なんらかのチューニングを施せばさらに 改善できるであろう。 高速のデータ転送が必要な場合、 DMA の手法を使わ なければならない。 AT バスにも MicroChannel バス にも最高速度の転送に不合理な遅延があるので、転送を おこなうハードウェアは独自の DMA サイクルとアド 34 レッシングを生成しなければならない。 基本的なシステム遅延時間が LynxOS の仕様よりも 十分に小さいことを確認したあとで、コンソールにおけ るシステムの応答がどのていど早く低下するかを調べる ためのテストをおこなった。システムとともに供給され た Whetstone と Dhrystone のべンチマークを使って、 これらをバックグラウンド・タスクとして呼び出すスク リプトを書いた。驚いたことに、システムの応答性は急 激に低下した。しかしさらに調べたところ、コンソール で実行しているフォアグラウンド・タスクが遅くなって も、 PS/2 のシリアルポートに接続された端末での応答 はきわめて素早かった。 そこで、ますバックグラウンド・タスクがフォアグラ ウンド・タスクの関数としてスケジュールされているか、 コンソール・ドライバが過負荷になっているのであろう と考えた。この異常に関して Lynx に相談したところ、 後者が原因であることがわかった。コンソールはメモリ にマップされているので、画面への書込みはすべてディ スパッチされなければならないタスクによって処理され るのである。 バックグラウンド・プロセスが同時、あるいはほとん ど同時に画面に書込みをおこなう場合、書込みをキュー に入れるカウンティング・セマフォはコンソール操作に オーバーヘッドを加えはしめる。いったんそのようなタ スクが始まってしまうと、順番づけられたキューを維持 するためのオーバーヘッドは、メモリにマップされた画 面を操作するために必要なメモリ移動操作と結びついて コンソールの反応を遅くさせる。 シリアルドライバにはそのようなメモリ移動のオーバ ヘッドがまったくないので、その動作をずっと早く完了 できる。これは、動的に結合されたキューシステムによ くみられるオーバーヘッドの減少に役立つ。 Lynx は、この問題を仮想端末を使用して解決してい る ( X11 の実装は不要 ) 。というのは、 1 つの端末に報告 する複数のタスクを開始する場合、たいていはコンソー ルからおこなうからである。仮想端末に投げ、それをコ ンソールに投け返すことよって、プログラマーは体系的 にシステムと変更優先度を監視できるようになる。これ は、画面に送られるメッセージに影響をケえることなく 劇的に性能を向上させる。さらに、仮想端末は中断した UNIX MAGAZINE 1990.12