連載 / シェルの魔術ー① 図 8 ハーミッションの 9 文字を分解 . 1 TWX 図 9 所有者 r ー X 所有グループ r ー X その他 ミッションの 3 文字をさらに分解 通常ファイル / 、一ミツンヨ / す。参考にしてください。 読取り可能 書込み可能 TWX ー実行可能 ティレクトリ 捜索可能 書込み可能 読取り可能 さきほどの図 4 の 2 番目の項目にも出てきたパーミッ ションとは、具イ勺には何なのでしようか。簡単にいうと、 この 9 文字はファイルへのアクセス制御を表すものです。 つまり、ファイル ( の実体 ) の内容を、、、誰 " が、、どのよ うに " 扱えるかを示しているのです。 図 8 に、この 9 文字を分解した様子を示します。この 図から分かるように、最初の 3 文字が所有者に対する制限 を、次の 3 文字が所有グループに対する制限を、最後の 3 文字がその他のユーザーに対する制限を表します。 r や 、、 w " カ俵示されている部分は、該当する操作か許可されて いることを示しています。一方、、、一 " か表示されている場 合は、該当する操作カ午可されていません。 それでは、この 3 文字をもうすこし詳しくみてみましょ う。図 9 に示すように、これは通常のファイルとディレ クトリて若干意味が異なります。 通吊ファイルのパー : " ぐ 、ノ / ョン ます、通常のファイルの場合をみてみましよう。ファ イルが、、言翹り可能 " というのは、そのファイルの内容を 閲覧できることを指します。たとえば、 2001 年 8 月号で は次のようなコマンドを実行しました。 $ ls f i le . 1 $ cat file . 1 kore ha file 106 取 0 nakami これは、 cat コマンドを使って file. 1 というファイルの 内容を表示しています。つまり、このファイルは閲覧可能 であるわけです。 そして、ファイルが、、書込み可能 " というのは、そのフ ァイルを上書きしたり、修正した内容を保存できることを 指します。 残るもう 1 つの、ファイルが、、実行可能 " とは、、、その UNIX MAGAZINE 2002.5 起動されるわけです。しかし、 sample. sh は馬翹り不可ですか のスクリプトですから、 sample. sh を引数として /bin/sh が インタープリタか実行されます。今回の場合は Bourne シェル スクリプトを実行する際には、そのスクリプトを引数として Bourne シェルのスクリプトで書いてみます ( 図 12 ) 。 ります。たとえば、上記の sample と同様のプログラムを ただし、スクリプトの場合は読取り可能である必要があ 同じように結果が出力されています。つまり、答は、、でき して、そのファイルを指定して実行してみると、図 10 と プログラムを実行可能、かっ言翹 ( り不可にしています。そ 図 11 を見てください。 chmod で、さきほどの sample 合、そのファイルを実行することはできるのでしようか ? ところで、実行可能なファイルか読取り不可である場 くなったわけです。 ラーになっています。つまり、このファイルは実行できな しようとしても、 permission denied" と出力さ工 ますれこの状態でさきはどと同じように sample をテ 所有者、所有グループ、その他のすべてからなくなってい x が の結果は ls コマンドて市忍できます。たしかに、 こでは実行を不可能にする操作をおこなっています。そ ます。 chmod コマンドについては次回に説明しますが、 次に、 chmod コマンドでノヾーミッションを変更してい 定して実行することができました。 可能であることが分かります。実際に、そのファイルを指 最初の状態では、、 x " か表示されていることから、実行 プログラムです。 という文字列を標出力に出力し、終了するだけの簡単な sample ・ sample というファイルは、実行すると、 す。例をみてみましよう ( 図 10 ) 。 ファイルを指定して実行することができる " という意味で

連載 / シェルの魔術ー① 図 10 ファイルの実行 ( 可能→ ) $ ls ー 1 sample —rwxr—xr—x 1 moley moley 5857 Mar 10 02 : 28 $ . /sample sample ・ $ chmod —x sample $ ls ー 1 sample 1 moley moley 5857 Mar 10 02 $ . /sample ・ /sample : permission denied 図 11 実行可有まかっ読取りのファイル $ chmod + x-r sample $ ls ー 1 sample —wx——x——x 1 moley moley 5857 Mar 10 02 : 28 sample $ . /sample sample . : 28 sample sample —wx——x——x 1 moley moley 41 Mar 10 02 : 48 sample. sh $ ls ー 1 sample . sh $ chmod —r sample. sh s 五 e11 script no sample ・ $ . /sample. sh —rwxr—xr—x 1 moley moley 41 Mar 10 02 : 48 sample. sh $ ls ー 1 sample. sh 図 12 実行可肯まかっ読取りのファイル ( スクリプトの場合 ) ←実行できている ←実行可能、かっ読取り不可になった ←実行できない ←実行可能であることが分かる ←実行できた ッションを変更 ←、 x" がなくなった ←実行できない ←実行可能、かっ読取り不可 ←実行できている $ . /sample . sh /bin/sh: Can 't open . /sample . sh ら、「 sample. sh の中身が見られへんで」というエラーが発生 します。 ァイレクトリのパー : 、、ぐ 、ノ / ョン ディレクトリ・ファイルの内容は、登録されているファ クトリ・ファイルの内容が閲覧できる " ということです。 した。つまり、ディレクトリか第翹えり可能とは、、、ディレ 思い出してください。ディレクトリ自体もファイルで 取り可能 " とはどういうことでしようか。 内容か閲覧可能という意味でしたが、ディレクトリが、読 ましよう。通常のファイルの場合、、、言翹てり可能 " はその 次に、ディレクトリのパーミッションについてみてみ イル名ですから・・ もう分かりますれディレクトリ か第翹り可能とは、、、そのディレクトリに登録されている ファイル名の一覧を見ることができる " という未です。 図 13 に例を示します。最初、 testdir は言翹可能な ので、 ls コマンドでディレクトリにあるファイルの一覧を ー ~ ー - - ーー一一 ~ ーー表示する一ごとができます。しかし、 chmod コマンドで読 UNIX MAGAZINE 2002.5 取り不可にすると、一覧を表示できなくなりました。 ディレクトリが、、書込み可能 " の意味も難しくないでし よう。ディレクトリ・ファイルに書込みが可能、すなわ ち、、新しいファイル名を登録できる " ということです ( 図 さて、残る 1 つです。通常のファイルであれば、、実行 可能 " でしたが、ディレクトリの場合は、、捜索可能 " 8 とい う未になります。これは、そのディレクトリに登録され ているファイルにアクセスできる、という意味です。なん だかよく分かりませんれ例をみてみましよう。 図 15 を見てください。最初、 testdir は捜索可能なの で、ディレクトリに登録されているファイルの状態を取得 できます。次に、 chmod コマンドで艘索不可にしていま す。この状態でも、 testdir は言翹り可能なので、 ls コマ ンドで求されているファイル名の一纜を取得できていま す。ところが、それらのファイルの状態を表示しようとす 14 ) 。 8 可能 " ということもあります。 107

連載 JavaServer Pages—O 図 7 同時アクセスがするとアクセス数の里を誤る ① 1 人目のアクセスカウンタ値 readCounter() count 十十 saveCou nter() カウンタ値 ② 2 人目のアクセス -1- CV 1 -1 ・ワ」 CV readCounter() count 十十 ー saveCounter() 2 2 図 8 排他里を追加した Counter2 クラスの getValue() public int getVa1ue ( ) int count このとき、 2 人目のアクセスによる処理が readC 。 unt ー er() を実行し終えたとします。 1 人目のアクセスによるカ ウンタ値はまだアクセスカウンタのファイルに保存されて いないので、 2 人目がアクセスしたときも readCounter() カ芍区す値は、、 1 " です。したがって、、、 count 十十 " を実行 したあとの 2 人目のカウンタ値も 2 です。 このように、 getVaIue() か 1 司時に実行されると、タイ ミングによっては複数の人に同じアクセスカウンタ値を表 示してしまいます。 さらに、 1 人目がアクセス数をファイルに保存するとき には正しく、、 2 " 呆存されますが、 2 人目はもともと正し いアクセス数を取得できていないので、ファイルにも誤っ は、 synchronized のプロックに入るときに、 object が た値である、、 2 " を保存します。 ロックされていないかどうかを卩十ヾ、 このように、図 5 のコードでは、同時アクセスが発生し ・ロックされていなければ、ロックして、、排他的に実行 たときにアクセス数をカウントしそこねる可能生がありま されるコード " を実行 す ( 図 7 ) 。 ・ロックされていればロックカ埆早除されるまで待つ synchronized というように重川します。 この不具合を解決するためには、 1 人目のアクセスカワ これを利用して、 getVaIue() メソッドを書き換えてみ ァイルからアクセス数を読み出してふたたびファイルに保 ましよう。図 8 は、アクセス数を読み込む readCount- 存するまで、 2 人目のアクセスがファイルからアクセス数 er() から、保存する saveCounter() の呼出しまでを排他 を読み出さないようにする必要があります。 的に処理するように書き換えたコードです。 ーー級にこのような処理 ( 里と呼ばさまざまな synchronized でロックするオプジェクトは、 1 人目の 手法があります。 Java ではオプジェクトをロックして排 アクセスでも 2 人目のアクセスでも、同一のものが参照さ 他処理を寒見する方法を言言」として提供しています。 れるオプジェクトであればなんでもかまいません。ここで は、、、 this " オプジェクト、すなわち jsp:useBean で生成 synchronized ( 0 り ec の { した ac オプジェクトを使いました。 排他的に実行されるコード ただし、 ac オプジェクトが page スコープなどの叩ー synchronized (this) { if ( (count=readCounter() ) くの { count 十十 ; saveCounter (count) ; return count ; 125 UNIX MAGAZINE 2002.5

連載 / シェルの魔術ー① 図 16 同じファイルを別々のディレクトリに登録して捜索可能 / 不可を操作 $ chmod + x testdir $ 1 Ⅱ testdir/sample $ ls ー 1 sample —rwxr—xr—x 2 moley $ testdir/sample sample. $ . /sample sample . $ chmod —x testdir $ testdir/sample moley 5857 Mar 10 02 : 28 sample ←ディレクトリ testdir にあるファイルを カレント・ディレクトリにも登録 testdir/sample : permission denied $ . /sample sample . ・ディレクトリに登録されているファイルの実行 体を消すという操作は UNIX にはありません。 ての本名がなくなると実体も消えるのです。ファイルの実 にはファイルの本名を消すことになります。そして、すべ イル名は別物です。ファイルを削除するというのは、実際 しつこいようですが、 UNIX ではファイルの実体とファ 考えれば、なぜこのパーミッションがないかが分かるで れません。しかし、 UNIX におけるファイルの仕組みを ようなパ ッションがあるので、不思議に思うかもし ミッションがありません。 Windows 2000 などではこの ところで、通常のファイルには、、削除不可 " というパー 削除禁止のパーミッションは ? ます ( 図 16 ) 。 ば、ファイルの実体か 1 司ーであっても操作することができ リにも本名か登録されている場合、そのファイル名を使え 作に景些を与えます。したがって、捜索可能なディレクト 名が登録されているディレクトリの状態だけが、以 .- ヒの操 状態とは無関イ系だということです。つまり、そのファイル 注意すべきなのは、これらは対象となるファイル自体の ・ディレクトリへのカレント・ディレクトリの変更 ←実行できる ←実行できる ← testdir を捜索不可にする ←実行できない ←実行できる には、そのファイル名が登録されているディレクトリの こノションを書込み不可にするしかありません。 とはいえ、ファイルごとに削除禁」 1 : かできないのはすこし 不便です。そこで、 UNIX ではアプリケーションがファイル ミノンヨンを不忍することで、この問題を鮹夬しようと のノ、一、い、 しています。これを利用すれば、ファイル自体の属性を物ムみ 不可にすることで、誤って削除されるのを、ある程度 " は防げ ます。 例として、ファイルを削除するための代表的なコマンド、 rm の場合をみてみましよう。書込み不可に設定されたファイル file .1 を rm コマンドを使って削除しようとすると、 rm : remove ' file . 1 ' overriding mode 0444 ? などといれて、すぐには削除できません。 しかしこの場合も、一 f オプション付きで rm を実行したり、 上記の間・に対して、 yes" と答えると、削除することができ てしまいます。 ☆ 今回は、ファイルのパーミッションについて説明しま UNIX を使うとき、ファイルは一時も欠かせないもの です。そして、すべてのファイル ( の実体 ) は、所有者や 所有グループ、 ッションという属性をもっていま さきほど説明したように、 ッションはファイル の実体に属するものです。したがって、ファイル自体の属 性として、ファイル名の削除を禁止することはできないの このよっな理由から、ファイル名の削除を禁止するため UNIX MAGAZINE 2002.5 す。これらをよく理解して使いこなせば、 UNIX をより ・こ使えるようになるでしよう。 次回は、ファイルのパーミッションの変更や、新規に ファイルを作成するときのパーミッション、さらにユー ザー・プライベート・グループについてとりあげます。 ( もりしま・なおと奈良先端秤物支術完大学 ) 109

し inux のプートプロセス 図 13 セグメント・セレクタの形式 lndex 表 1 セグメントのタイプ 引 RPL 番号 0 1 2 3 4 5 6 7 せん。しかし、これくらいて音を上げてはいけません。ま だまだ序のロ、三段目、プロテクトモードのセグメント・ ワールドはさらに複雑になります。 図 13 にセグメント・セレクタの構成を示します。下位 2bit の RPL はメモリイ矍機能が参照するデータで、これ については次回に詳しく説明します。 テープルのインデックス値は上位 13bit でオ旨定し、こ れを 8 倍するとテープルのバイトオフセット位置カ球め られます ( デスクリプタの大きさが 8 バイトだからです ) 。 しかし、実際はセグメント・レジスタの下位 3bit をマス クするだけで、オフセット位置カ球められるようになって います。 図 13 のすべてのビットが 0 のセグメント・セレクタに は、、、セグメント・レジスタを無効にする " という特別な 意味があります。たとえは、 0 を代入した ES レジスタ を使ってメモリにアクセスしようとすると、 CPU はプロ グラムの実行を停止して割込みを発生します。このため、 デスクリプタ・テープルの 1 番目の要素 ( セレクタ値 0 ) には、空のエントリを用意しておきます。図 12 に示した テープルの一番下が、さりげなく空いているのはこのため です。 図 14 にセグメントデスクリプタの構成を示します。見 ただけで頭カくなってきそうですが、 Linux はすべての フィールドを使っているわけではありません。ここで重要 なのは、べースとタイプ、そして DPL です。各フィール セグメントのサイズを表します。 リミット ( 19...0 ) セグメントのべースアドレスを表します。 ・べース ( 31...0 ) ドの意味は以下のとおりです。 40 スしようとすると、その命令は実行されす、領域違反が プログラムがリミットを超えた領域のアドレスにアクセ すことかできます。 0 から IMB まで、 1 の場合は 4GB までのサイズを表 サイズの単位は G フラグの内容に依存し、 0 の場合は 意味 読出し専用データセグメント 読み書き可能データセグメント 読出し専用スタック・セグメント 読み書き可能スタック・セグメント 実行専用コードセグメント 実行と言蒄し可能コードセグメント 実行専用コンフォーミングコード・セグメント セグメント 実行と読出し可能コンフォーミングコード・ あったことが OS に通知されます。 ・ G フラグ リミットの単位を表します。 0 ならはバイト、 1 ならば ページ (4KB) です。 ・ D フラグ セグメントのタイプを表します。番号とタイプの対応を ・タイプ セグメントデスクリプタでは 1 を設定します。 ・ S フラグ します犲雀レベルについては次回に説明します ) 。 グメントへのアクセスに必要な CPU ク讚在レベルを表 このフィールドはデスクリプタ牛讚雀レベルと呼はれ、セ ・ DPL (Descriptor PriviIege LeveI) します。 ワップアウトされることはないので、つねに 1 に設疋 ときは 0 になります。 Linux ではセグメント全体がス セグメントがメモリ上に存するときは 1 、存在しない ・ P フラグ 0 です。 OS 用のフラグですが、 Linux では使いません。つねに ・ AVL 予斉みピット。つねに 0 です。 ・ res す。 16bit になります。 Linux では、つねに 1 に設定しま できます。 D フラグが 1 のときは 32bit 、 0 のときは ロテクトモードでは 16bit と 32bit を〕尺することが るデータのサイズはかならす 16bit でした。一方、フ リアルモードでは、アドレスのサイズや CPU か処理す ・ A フラグ 表 1 に示します。 UNIX MAGAZINE 2002.5

( 0 ・・一 op ーーー・れ t Kit fo ′ ( p ′ー ro 図 4 デパッガ上での実行 # /usr/10ca1/h8/bin/h8300—hms-gcc # /usr/Ioca1/h8/bin/h8300—hms—gdb (gdb) file a. out Reading symbols from a. out ... done. (gdb) set machine h8300h (gdb) target sim Connected tO the simulator . (gdb) load ¯mh ¯g char—test . c Loading section . text, size 0X8720 vma 0X100 Loading section . data, size 0x8aa vma 0X8820 Loading section . stack, size 0X4 vma Ox3fffc Start address 0X100 Transfer rate: 294512 bits in く 1 sec . (gdb) て u 取 Starting program : /root/demo/a. out char va1 = 255 uns igned va1 255 Program received signal SIGTRAP , Trace/breakpoint trap. 0X58a in —exit ( て c = 0 ) at —exit . c : 14 14 _exit . c : NO such fi1e or directory. (gdb) quit The program is running. Exit anyway? (y or Ⅱ ) y 表 1 データ型の大きさ x86 1 4 4 2 4 4 8 みましよう。次のようなプログラム (char-test. c) を作成 し、 X86 と h8300-hms-gdb ーヒで実行してみます。 #include く stdio . h> int main(int argc , char **argv) int unsi gned int short float long double h8300 1 2 2 2 4 4 4 char va11 数ぶん、シリアル経由で capterm へテスト表示を繰り 返します。続いて capterm からの入力待ち状態にな り、文字が入力されると、これを capterm 上に表示 して終了します ( つまりエコーバックするわけです ) 。 h8300-hms-gcc と X86 用の GCC では、データ型の サイズが異なるものがあります俵 1 ) 。たとえば、 int は 2 バイトなので、範囲は一 65536 から 65535 までになり ます。 また、 h8300-hms-gcc では、 char 型は unsigned char として扱われます。 X86 では char は signed char な ので、上交演算では X86 のときと異なることがあります。 ーー - - ーーーーーー - ー一一 ' ーー - ークロスコーンパイノい鼬竟に慣れるために、ちょっと試して UNIX MAGAZINE 2002.5 unsigned char va12 printf ( " char va1 %d\n",vall) ; %d\n" ,va12) ; printf ( "unsigned val exit(O); これをコンパイルし、テパッガ - ヒで実行します ( 図 4 ) 。 h8300-hms-gcc に付けている—g オプションは、 gdb が必要とする情報をオプジェクトに埋め込むためのもので す。 -mh は H8 / 300H 用のコードを生成するためのオプ ションです。 コンパイルした実行ファイルは H8 / 300H 用のものな ので、このままでは X86 上では実行できません。そこで、 gdb を用いて h8 の CPU をエミュレートしてプログラム を実行します (h8300-hms-gdb は、 h8 のエミュレート が可能なようにコン六イルされています ) 。ます、 h8300 ー hms-gdb を起動し、 file コマンドでテンヾッグ対象のファ イル ( この例では a. 。 11t ) を指定します。続けて、 h8300 ー hms-gdb を H8 / 300H 工ミュレータとして動かすため 131

連載 / シェルの魔術ー① 図 1 id コマンドの実行 $ id uid = 10039 (moley) gid = 10039 (moley) groups = 10039 (moley) , 0 (wheel) , 20 (staff) 示してくれるため、ふだんは UID を意識することはあり ません。自分の UID を調べるには、 id コマンドを使いま す ( 図 1 ) 。 実行結果の、 uid " の部分を見ると、 10039 という直 カ俵示されています。こオ功ゞ UID です。また、瓜で囲 まれた文字列がその UID に対応するユーザー名です。 UNIX では、複数のユーサー名で伺し UID を共有するこ とができます 2 。この場合、ログインするときに入力するパス ワード、ログインシェルやホーム・ディレクトリをユーザー名 ごとに変えることができますが、内部的には同しューサーとし て扱われます。あとて説日月しますが、所有しているファイルや、 実行しているプロセス荏限も同しです。 図 1 に示した id コマンドの実行結果には、、、ⅲ d " 舅 19 ト に gid groups" などと書かれた部分があります。これ は、ユーザーが所属しているグループを表しています。 グループとは、共通の性質をもったユーザーの集まり です。たとえば、何人かカ哄同で作業をすることが多い場 合、全員か伺しグループに属するとデータを共有しやすく なります。また、特定のユーザーだけに特別な権限を与え たい場合も、そのようなユーザーを 1 つのグループにまと め、グルーフ。単位で権限を与えたりします。 ューサー名に対する UID と同しように、 UNIX ではグ ループも数値て識別しています。この直のことを GID (Group (D) と呼びます。 管理者か新しくアカウント ( ューサー ) を作成するとき、 同時にそのアカウントカ嘱するグループを 1 つ決定しま す。このグループをプライマリ・グループと呼びます 3 。 ューサーはかならすプライマリ・グループに属するので、 すべてのユーサーはつねに 1 つ以 E のグループに属するこ とになります。図 1 の、、 gid " は、プライマリ・グループを 示しています。ューザーは、プライマリ・グループに加え て、複数のグループに属することもできます ( 図 2 ) 。 id コ 2 ただし襭朱な事情がないかぎり、このような言聢をすることはありませ ん。 3 最丘ではユーザー・プライベート・グループ (UPG) が主充になりつ つあります」一にれにづいてはー一次可に説明します。 UNIX MAGAZINE 2002.5 図 2 所属グループ プライマリ・グループ gid = 10039 (moley) gid=20(staff) gid=O (wheel) ユーザー uid = 10039 (moley) 連載の 2 回目 ( 2001 年 8 月号 ) で、「ファイルの正体」 と題し、ファイルとファイル名の関係や、ファイルの本 名、別名などをとりあげました。このとき、 ls コマンドを ー 1 オプション付きで実行し ( 図 3 ) 4 、出力の最後の行の先 頭にある、 1 " がシンポリック・リンクを表すこと、左から 2 番目のカラムの数字が、、ファイルの本名 " の数を示すこ となどを説明しました。 図 3 には、これらを含めて全部で 8 つの情報が表示さ れています。例として、最終行を分解してみましよう ( 図 4 ) 。分解したそれぞれの部分カ舸を表すのかを以下で説明 します。これらのうちいくつかについては、のちほど詳し くとりあげます。 ( 1 ) ファイルの番 知頁の 1 文字はファイルの不頁でづー。こ刎列の、、 1 " は、 シンポリック・リンクを表しています。ディレクトリの場 合は、、 d " 、通常のファイルは、、一 " です。未なファイル では、、、 c " や、、 p " が表示される場合もあります。 4 2001 年 8 月号の例 ( 129 べージ ) とは左から 4 番目のカラムの記 マンドの実行結果では、 groups" の部分がそのユーザー の所属するグループを表しています。 が異なります。 103

連載 /JavaServer Pages—@ 図 11 sleep() を追加した不具合を修正しているコード public int getVa1ue ( ) int c ount synchronized (this) { if ( (count=readCounter() ) return count ; count 十十 ; try { Thread. sleep ( 5000 ) ; } catch (Exception e) { saveCounter (count) ; return C ount ; 図 13 jsp:useBean タグの非他タ里 くの { 図 12 正しく表示されたアクセスカウンタ ムファイル ( E ) 編集 ( 印表示検常 ) ジャンプ 0 ブッりマり ( 印タスりヘルプ旧 ) 物匪仮カウンタ ( その 4 ) ー Netscape 5 ロロ雪コュメ : 完了 00 け ) リアクセス数 : 64 排他虹理を行っているカウンタ 、働ホーム、検常ロカりマーり、 t 師物 536 ”、新着、お都助、メントズ 方イル住編果 ( 印表示検索ジャンプ 0 ブッりマーり ( 印タスクへルプ ( 印 アクセス数 : 63 排他処理を行っているカウンタ 」木ーム検索朝ブッりマーり第物引聞ー鷭。、新著籌お都助、メントズ ロ X ロ X / / begin [file="/counterl . jSP";fr0m=(11,0);t0=(11,66)] counter . Counter1 ac Ⅱ u11 ; -jspx-specialac true ; ← true なら jsp:useBean の本体の処理を実行する if ( ac = Ⅱ u11 ) { pageContext . getAttribute ( "ac" ,PageContext. APPLICATION—SCOPE) ; ac= (counter . Counterl) synchronized (application) { false; boolea 取 -Jspx—specialac (counter. CounterI) java. beans . Beans . instantiate(this . getCIass() . getCIassLoader() , "counter . Counter1") ; pageContext . setAttribute ( ac , すると、別々のアクセスによって実行される 2 系統の処 理の両方が、 getAttribute() で null を受け取ります。次 の if 文のなかのコードも重複して実行さ新しく生成さ れた 2 つのオプジェクトが、 pageContext 内に同し名前 て保存されます。 その結果、 ・アクセス回数を 1 回数えそこなう ・ jsp:useBean の本体の処理が 2 回実行されてしまう ・生成した 2 つのオプジェクトの一方しか保存されない ( 最初に保存されたオプジェクトは 2 番目に保存された オプジェクトに上書きされて失われる ) といったさまざまな問題カ吽します。 UNIX MAGAZINE 2002.5 PageContext . APPLICATION_SCOPE) ; このように、 Web のアプリケーションでは処理か並列 に実行されることを ; 頁におき、共通のデータを読み書き するときは必要に応して排他処理を組み込まなくてはなり ません。 ☆ 今回は、 JavaBean を生成する jsp:useBean タグのす こし詳しい説明から発展して、 JavaBean オプジェクト のスコーフ。や jsp:useBean の実装を解説しました。また、 Web アプリケーションの典型的な不具合として、 JSP ペ ージに対して同時に複数のアクセスが発生した場合の動作 をとりあげ、正しく処理をおこなうための排他処理とその 具ー勺なガ去を紹介しました。 ( あらい・みちこ ASTEC) 127

Linux のプートプロセス セグメント導入の こで、どうして 8086 がセグメントという不議な機構を 採用したのかを考えてみましよう ( 以下の話は当時の状況から 孑伹則したもので、正があるわけではありません ) 。 単純に考えれば、メモリ空間を 32bit て扱うようにすれば よさそうなものです。そうすると、レジスタなども 32bit に しなければなりません。しかし、これには無理がありました。 Z80 や 8080 などの 8bitCPU のように ( おもなレジスタは 8bit でしたが、メモリ空間は 16bit でした ) 、メモリを指定す る部分だけを 32bit にすることも考えられましたが、これはか なり不便でした。 C 言語のホインタを考えてみましよう。ポ インタはアドレスなので、 32bit 幅になります。これを扱うに は 2 つのレジスタか尼要になり、プログラミングか面倒になり ます。 考えられる理由の 1 つは互換性です。当時、 lntel は 8bit の CPU として大成功を収めた 8080 / 8085 を販売しており、 これらに対応したソフトウェアもたくさんありました。これ と互換性のない CPU を作ると、ほかのメーカーとふたたび 争わなくてはなりません。そこで、 8080 / 8085 とあまり変わ らない構成にしたのではないかと思います。互換性といって も同レヾイナリかま行できるわけではなく、アセンプリ言語の ソースをそれなりに書き換える必要がありましたが、ある程度 は機間に変換することができました。これが、一足飛びに内 部が 32bit 構成になっていたら、書換えはかなり難しかった でしよう。 もう 1 っ考えられる理由は、製造技術止の制約です。レジ スタを 32bit 構及にするには、より多くのトランジスタを集積 する必要があります。しかし、当時の lntel はべンチャー企業 であり、大規模な LSI を置するには力不足だったのではな レジスタ値 : オフセット値 UNIX MAGAZINE 2002.5 イ巒内されます。 CPU が次に読み込むマシン語命令のオフセット位置が 実行中のプログラムの位置を指す実行ポインタを表し、 て、 IP レジスタ ( プロテクトモードの場合は EIP ) は、 指すセグメント内に存在しなければなりません。そし す。そのため、プログラムコードは、 CS レジスタが か夫行するプログラムコードを読み込むために使われま CS (Code Segment) は、その名が示すとおり、 CPU CS レジスタ ます。 のうちの CS と DS 、 SS レジスタは用途か決められてい 図 3 には 6 つのセグメント・レジスタがありますが、そ たとえは、 、 2345H : 100H " のように言当します。 いでしようか。 とはいえ、 16bit 及のままでは間題がありました。それは メモリ空間です。メモリを 16bit で指定すると 64KB までし か扱えないことになり、これでは 8bit の CPU となんら変わ りがありません。そこで、 16bit 構友のまま、より多くのメモ リ空間をなんとか扱えるようにしたのがセグメントだったとい うわけです。つまり、アドレスク旨定に 2 つの 16bit レジス タを使うようにしたのです。そうすれば、ふだんは 16bit を 偂醍にし、 64KB より多くのメモリを扱うときだけセグメント について考慮すればいいことになります。 当時は 8bit の CPU が全盛でしたから、 1 つのモジュール または 1 つのデータ構造なら 64KB に収まると予想していた のでしよう。しかし、 8086 シリーズの大ヒットにより、この 予想はみごとに外れてしまいました。つまり、プログラマーた ちはもっと大きなプログラムを書くようになり、そしてより大 きなデータ構造を扱うようになったのです。 ついでに、なぜメモリ空間を IMB にしたかも想像してみま しよう。 IMB ですから 20bit 、すなわち CPU の外に出すア ドレスパスも 20 本必要になります。これより多くのアドレス 空間、たとえば 24bit にすると、これに加えてさらに 4 本の 糸勦ゞ必要となり、 CPU のパッケージが大きくなってしまいま す。現在も青はそれはど変わっていませんが、大きな CPU パッケージを作るのは技勺に容易ではありません ( 8086 で は、アドレス線とデータ線を重ねてピン数を減らしていること からも想像できます ) 。また、ソケットも必名勺に大きくなり、 基板の酉当泉も複雑になります。これらを考えあわせて 20bit に したのではないでしようか。 さきほどの表記を使うと、 CPU は CS:(E)IP カ甘嗣ーリ ニアアドレスからマシン語命令を読み込みます。次に その命令長を (E)IP に加算してポインタを進め、命令 を実行します。 分岐 ( ジャンカ命令など、セグメント内のアドレス に実行位置を、、飛ばす " 命令を実行するときは、 (E)IP レジスタに移動先のオフセット値が代入されます。 方、セグメントの外にあるプログラムを実行する場合 は、 CS レジスタと (E)IP レジスタの両方か史新され ます。 DS レジスタ すべてのプログラムは、データを加工することで目的の 処理をおこないます。 CPU はメモリからデータを読み 込み、足したり、引いたり、掛けたり、割ったり、回 したり、こねくりまわして、その結果をメモリに書き込 35

= し inux のブートプロセス 図 14 セグメントデスクリプタ豈 56 55 54 53 52 51 48 47 46 45 44 43 63 の > リミット G D < ( 19...16 ) P DPL S タイプ A べース ( 23 … 16 ) リミット ( 15...0 ) 40 39 32 べース ( 31 … 24 ) べース ( 15...0 ) 0 16 15 31 図 15 プロテクトモードのアドレス計算 セグメント・セレクタ オフセット GDTR ー〇一・ グロー / ヾ丿レ デスクリプタ テープ丿レ リニアアドレス 1. セレクタ値と GDTR からデスクリプタのアドレスを CPU がこのセグメントにアクセスすると自重加勺にセッ 求める トされます。 2. デスクリプタの内容をメモリから読み出す 以 . E のデスクリプタ・テープルをメモリ上に作成したあ 3. セグメントのべースアドレスを取り出す と、その先頭アドレスとエントリ数を CPU に通知する 4. セグメントのべースアドレスとオフセット値を加算する 特別な命令を実行します。この命令を実行すると、図 3 の という処理がおこなわれます。アドレスの加算は CPU 内 GDTR レジスタに 32bit のツ頁アドレスと 16bit の工 のハードウェアで実行されるので、高速に処理されます ントリ数カき込まれ、その点から CPU はデスクリプ が、デスクリプタの読出しはメモリアクセスをともないま タ・テープルを参照できるようになります。テープルの内 す。つまり、 1 回のメモリアクセスのためにメモリに 2 回 容は、 CPU の内部にコピーされるわけではなく、 CPU アクセスすることになり、なんとも不締斉です。しかし、 は必要なときにメインメモリ上のテープルから必要なエン 80386 以降の CPU は、アドレス変換を高速に処理する トリを読み出します。 ために、セグメントデスクリプタの内容をコピーしておく こまでで、プロテクトモードのアドレス変換にかかわ レジスタが用意されています。 る要素はすべて登場しました。これをまとめると図 15 の 図 15 ではメモリから読み出すように描いてありますが、 ようになります。たとえば、 CPU がメモリからデータを 実際はセグメントのべースアドレスはメモリから取り出し 41 UNIX MAGAZINE 2002.5