分散処理オペレーティングシステムの構築法に関す る研究

九州大学学術情報リポジトリ

Kyushu University Institutional Repository

分散処理オペレーティングシステムの構築法に関す る研究

谷口, 秀夫

https://doi.org/10.11501/3059382

出版情報：Kyushu University, 1991, 博士（工学）, 論文博士 バージョン：

権利関係：

ω

回­

æ6‘

Lν

分散処理オペレーティングシステム の構築法に関する研究

平成3年5月

谷 口 秀 夫

目 と欠

第一章 序論 ^l

1 1 まえがき

1 2 分散処理の発展 2

l 2. 1 背景 2

1 2. 2 分散処理システムの要件 3 1 3 分散処理o 5に関する研究状況 4

1 4 本論文の研究課題 7

4 l 目的 7

1 4 2 内容 7

l 5 本論文の構成 ⁸

第二章 分散処理05構築の基本方式 9

2 . 要求条件 9

2 . 1 応用プログラムインタフェース 9 2 . l 2 機能分散と負荷分散 1 0 2. 2 構築上の課題と対処方式 1 0 2 . 2. 1 機能を実現する処理モジュールの分割単位 1 1 2 . 2 . 2 処理モジュール問のインタフェース 1 5 2 . 2 . 3 処理モジュール問の通信インタフェース 1 8

2 . 2 . 4 処理モジュール問を結ぶ通信路との関係 1 9

2 . 3 実現方式の違いによる分類 1 9

第三章 新規作成による分散処理05

3. 1 分散処理05の構成法 3. 2 リクエスト制御方式

3. 2. 1 基本構造

3 3 6 6 2 2 2

2

、1ノ-l ft\

3. 2 . 2 特徴 3 0 第五章 既存os結合による分散処理os 6 7 3 . 3 リクエスト制御方式の実現例 3 2 5 . _l 本分散処理osの特徴 6 7 3 . 3. _l ハードウェア環境 3 2 5 . 2 リモートファイルアクセス機能の構成法 7 0 3 . 3 . 2 リクエスト制御方式の適用 3 2 5. 2. 分散したファイルの統一管理方式 7 0 3 . 3 . 3 ファイル管理機能 3 4 5 . 2. 2 グループファイルへのアクセス方式 7 0 3 . 3 . 4 プロセス生成制御機能 3 6 5 . 2. 3 アクセス要求の転送単位と通信方式 7 2 3 . 3 . 5 プロセス間通信機能 4 1 5. 3 UNIXにおける実現法 7 4

3. 4 性能評価と考察 4 2 5 . 3 . _l グローバルトリーの導入 7 4

3 . 4. _l リクエスト制御オーバヘッド 4 2 5. 3 . 2 グループリモートファイルアクセス機能の実現 7 6 3 . 4. 2 ファイルアクセス 4 2 5. 3 . 3 アクセス要求の転送方式 7 7

3 . 4. 3 プロセス生成 4 6 5 . 3 . 4 処理構成 8 5

3 . 5 まとめ 4 8 5 . 4 性能評価と考察 8 5

5. 4. アクセス速度 8 7

第四章 高信頼システム 5 3 5 . 4. 2 セグメンテイング機能の効果 9 0

4. _l 高信頼化の方式 5 3 5 . 4. 3 グループリモートファイルアクセス機能の有効性 9 0

4. 2 ハードウェア機能 5 5 5 . 5 まとめ 9 3

4 2 . _l 構成 5 5

4 2. 2 立ち上げ 5 6 第六章 電子会議システム 9 5

4 2. 3 プロセッサ切り離し 5 6 6. 1 会議サービスの機能 9 5

4. 3 o 1 R 0 S機能 5 6 6 . 2 基本機能 9 6

4. 3 . _l 構成 5 6 6. 3 分散処理OSの機能 9 8

4. 3 2 立ち上げ 5 9 6 . 3 . _l 電子会議サービスが求める機能 9 8

4 . 3 . 3 資源の切り離し 5 9 6. 3 . 2 複数サービスの共存と協調処理が求める機能 100 4. 3 . 4 障害回復処理の高速化 6 1 6 . 4 電子会議サービス内容 100

4. 4 サービス管理プログラム 6 2 6 . 4 . 1 企画段階 101

4 4. 1 障害回復機能 6 3 6. 4 2 準備段階 101

4 . 4 2 計算機切り替え機能 6 3 6 . 4 3 討論制御段階 103

4 5 まとめ 6 5 6 . 4. 4 終了段階 104

6 . 5 性能評価と考察 104

6 . 6 まとめ 106

( ii ) ( iii )

第七章 結 論 ₁₀₇

謝 辞 1 1 1

参考文献 ₁₁₃

(iv)

多有一一主主 F亨言命

1 ^_ 1 まえーヵまき

計算機を様々な通信路で結んだ分散処理システムの構築[情報処8 ₇ ]が盛ん に行なわれている。 このような分散環境を制御するオペレーテイングシステム〈

以降、 o sと略す)は、 大きく次の二つに分類できる。 一つはネットワークo s であり、 もう一つは分散処理o sである。

ネットワークo sは、 o S 1 (0 pen S ystems 1 n ter-connect ion)に代表さ れる標準的な通信制御手順に基づいて分散処理の環境を実現するo Sである。 こ のo Sは、 主に、 大型計算機を数千ピット/秒の通信回線で結んだ分散処理シス テムに適用されている。 分散処理o Sとの大きな違いは、 磁気ディスクや磁気テ ープなどの操作において、 応用プログラム(以降、 APと略す)に提供している アクセス法が異なることである。 ネットワークo Sの場合、 APは、 同一計算機 内 にある磁気ディスクや磁気テープなどへのアクセスと、 別計算機にある磁気デ ィスクや磁気テープなどへのアクセスとの違いを、 意識する必要がある。 例えば、

ファイル内容を複写する場合、 同一計算機内であればデータの読み出しと書き込 みにより行なう。 一方、 別計算機からの ファイル複写であれば、 通信制御手11闘に 従ったファイル転送機能を利用することになる。

分散処理o Sは、 o S自体の機能を分散化した形でAPに提供することにより 分散環境を実現するo Sである。 このo Sは、 主に、 マイクロプロセッサを搭載 した計算機をローカルエリアネットワーク(以降、 LANと略す〉のような数メ ガピット/秒の高速伝送路で結んだ分散処理システムに適用されている。 APは、

同一計算機内にある磁気ディスクや磁気テープなどへのアクセスと、 別計算機に ある磁気ディスクや磁気テープなどへのアクセスを、 同じ形式で行なえる。 した がって、 例えば、 ファイル内容を複写する場合、 APの処理は、 同一計算機内で の複写と計算機関にまたがる複写が同じ処理になる。

本論文では、 分散処理o Sの構築法について述べる。 本論文で扱うo Sとは、

- 1 ^-

データベースやコンパイラなどを含む広義o sではなく、 プロセス管理やファイ ル管理などの基本機能のみによる狭義o sである。 分散処理o sの構築が可能に なった背景を述べ、 分散処理o s構築時に留意すべき条件や課題を示すo さらに、

新規に分散処理o sを作成する場合と既存のo sを結合する場合の各々について、

分散処理o sの例を示し、 それを利用したサービスシステムを述べる。

本章では、 分散処理o sの構築法の研究に関し、 その背景となる計算機のハー

ドウェア技術やソフトウェア技術および通信の伝送路や通信手順に関する技術に ついて述べる。 また、 分散処理o sに関する研究の状況ならびに本研究の目的や 内容について述べる。 以降、 1. 2節では分散処理が 発展してきた背景やその特 徴を述べる。 1. 3節では、 分散処理o sの構築に関する研究の状況について述 べる。 1. 4節では、 本論文の研究目的とその内容を述べる。 最後に、 1. 5節 では本論文の構成を述べる。

1 ^_ 2 タテ賛女究包王里ι〉多迭居室

1. _2. 1 背景

分散処理システムが急速に発展している背景には、 次に説明するいくつかの技 術の発展向上が深く関係している。

第ーには、 L _{S 1} (L arge _S cale ₁ ntegra ted ci rcui t)技術の急速な進歩[

日経マ8 ₆ J [電子通8 4 ] [電子通8 ₆ ]である。 これにより、 マイクロプロ セッサの性能は飛躍的に向上し、 数M₁ P _S (Million 1 nstructions Per _S econd)の性能を有するプロセッサチップも登場している。 また、 記憶素子の高集 積化も進み、 1メガピットのメモリチップも登場している。 その結果、 o sが利 用できるプロセッサ負荷やメモリ域が大きくなった。 これにより、 o Sをアセン プラ言語ではなく高級言語で記述することが可能にな り、 従来に比べ o Sの検討 が行ない易くなった。

第二には、 実装技術の向上があげられる。 細線加工や多層配線の技術進歩によ り、 1枚のハードウェア基板に多くの機能を搭載できるようになった。 このこと と先に述べたL S 1技術の向上は、 価格性能比が良くかっ小型な計算機の実現を

-2-

可能にした。 その結果、 少人数あるいは個人で計算機を保有することが可能にな り、 計算機を身近な研究対象とすることができるようになった。

第三として、 通信技術の向上、 特に、 データ通信に利用できる通信路として、

LANに代表されるような高速伝送路[情報処8 ₂ Jが登場してきたことである。

例えば、 数キロメートル離れた計算機関を数メガピット/秒の速度で結合するハ ードウェア環境を構築できる。 このような環境では、 o sが別計算機にある磁気 ディスク などへの操作を、 同一計算機内の磁気ディスクなどの場合に比べあまり 遅くない程度で実現できる。 つまり、 従来に比べ、 より密な関係にある処理を分 散して行なうことができるようになった。

もう一つの要因として、 UNIX[Ri t78Jの普及があげられる。 UNI Xは、 優れた利用者インタフェースを持つと共にそのソースプログラムが公開さ れ、 研究機関や教育機関を中心に普及したo 従来は、 o sに関する研究を行なう 場合、 研究に必要となるo s作成環境およびそのo sが走行する計算機の確保や 整備が大変であった。 しかし、 UNIXはこれらの問題を解消し、 多くの人がO

Sの改造環境を持つことを容易にした。 また、 先にも述べたように、 少人数で計 算機を保有することが可能になったことも、 UNIX の普及に大きく関連してい る。

上記の技術を背景にして、 分散処理システムが発展している。 その中では、 分 散環境を生かしたサービスの提供が求められている。 このサービスを実現するA

Pの開発を容易にするため、 分散処理o Sの構築技術が必要になっている。

1. _{2. 2} 分散処理システムの要件

高い性能や信頼性を持つサービスを実現するため、 分散処理システムには様々 な処理形態がある。 したがって、 その構築に対し、 次に説明するいくつかの要件 がある。

第ーに、 機能や負荷の分散である。 ハードウェアの面からみると、 プロセッサ や入出力装置， 通信回線制御装置などの接続構成としていろいろな構成が存在す る。 また、 ソフトウェアの面からみると、 ハードウェアを制御する処理はハード ウェア構成に合わせて構成する必要がある。 さらに、 ソフトウェア独自の処理も いろいろな分散形態に対処する必要がある。 つまり、 組み替え自由な柔軟性がハ

3-

ードウェアとソフトウェアの両方に必要である。

第二に、 膨大なAPの扱いである。 分散処理システムにおいては、 スタンドア ロン環境のサーピスだけではなく分散環境に特有なサ ーピス[野口8 7 ]が求め られている。 現在、 メールや会議サービスなどがある。 さらに、 CS C W (C om puter S upported C o-operated Work)と呼ばれて研究が盛んに進められている サービス分野[CSC86] [CSC88]もある。 したがって、 分散環境サー

ビス用のAPを効率的に作成する必要がある。 そのためには、 スタンドアロン処 理用のAPをそのまま分散処理に利用できることが求められる。 さらに、 一つの APを分散処理とスタンドアロン処理の両方に利用できることも求められる。 技 術的には、 スタンドアロン環境と分散環境の両環境について、 APの走行環境は 物理的構成と独立して論理的構成を構築できることが必要である。

最後に、 様々な計算機を結んだ環境での実現である。 すべての計算機が、 プロ セッサと通信機能を持つ ことを前提としても問題ない。 しかし、 o sやプロセッ サがすべて同種とは考えにくし'0 したがって、 異なっ たo s間や異な ったプロセ ッサ聞をも含む分散環境構築が必要である。

1 . 3 タミテ費免疫!1王里o ^s �こ鳥司す一るを汗多宅ヰ犬之兄

分散処理o Sの構築に関する研究は、 その実現方式の違いにより、

( 1 )新規に作成する場合

( 2 )既存の同種o Sを結合する場合

( 3 )異種のo sを結合する場合

に分類できる。 方式( 1 )や方式( ² )は、 表1. ^{3 -}1のような研究状況にあ

る。 異種のo sを結合する場合については、 分散処理o Sとしての研究はほとん どなく、 ネyトワークo Sとしての研究にとどまっている。 しかし、 分散環境が 普及するにつれて、 研究が盛んになると思われる。

新規に作成する場合に関する研究は、 次の状況にある。 リモートメッセージ通 信の機能をAPに提供して分散環境を実現した例として、 Ede n[Edw81]

やShosh in - 0 S [T 0 k 8 3 ]がある。 Ed e nは、 LAN結合の分散環境を

-4

表1 . 3 - 1 分散処理OSの構築に関する研究の状況 年代 新規に作成 既存の同種OSを結合 198 1 E d e n

198 2 . Newcastle Connection COCANET

198 3 DOMAIN ALTOS-NET E

LOCUS

S h 0 5 h i n OS

1 984 1 B 1 S

198ち CFS NFS

1 986 Mach DPE

. COSMOS RFS EFS GFS

1 987 . Ago r a-I NEST . Butler system

1 988 CHORUS S p r i t e

. Andrew Fi le System

1 989 . DIROS MOSIX

- 5

オブジェクト間メッセージ通信の考え方で実現しo S核外に構築されている。 S

hoshin- 0 Sもメッセージ通信を基本にしている。 新規作成ながらUNIXと同

じAPインタフェースを実現しているo Sとして、 LOCUS [Wa 183]，

Agora -I [田胡8 4] [回胡87] [高野88]， COSMOS [中島8

6]， Mach [Acc86]がある。 LOCUSは、 UNIXの上位互換機能 を持ち、 分散ファイル管理機能だけではなくファイルが存在するプロセッサ上へ のプロセス起動も可能にしており、 VAX750上に実現している。 Ag 0 r a

- 1とCOSMOSは、 分散環境をスタ ンドアロン環境のUNIXマシンとして APに見せており、 マルチプロセッサo Sの考え方に近し\0 M a c hは、 4. 3

b s d U N 1 Xの互換機能を持ち、 後述するNewcast 1e-C onnection [ B r 0 8 2 ]による分散ファイル管理機能を持つ。 独自のo S体系をもつものとして、 C FS [Sch85]， CHORUS [Ro z88J， Spr i te [Ou s88J

， DIROS [谷口89 A]がある。 CF Sは、 分散ファイル管理機能を持ち、

o S核外に実現している。 CHORUSは、 「スレ ッ ド」と呼ぶ軽量プロセス機 能を利用してLANによる分散環境を実現している。 Sp r i t eは、 分散ファ イル管理と共にプロセス移動やリモートプロシジャ コール(Rernote P rocedure

C a 11)の機能を持つ。 DIROSは、 リクエスト制御方式を利用してAP機能 の分散を可能にする分散ファイルや分散プロセスの機能を実現していると共に、

o S機能の分散も可能にしている。 さらに、 分散環境内のメモリやディスクを統 一的に扱っているDOMAIN [Lea83Jや、 負荷分散に重点を置いたB_{u t}

1er-systern [N i c 8 7 J、 5000個以上の計算機環境で走行するA_ndrew-F

ile-Systern [J ₀ h 8 8]がある。

既存の同種o Sを結合する場合に関する研究は、 UNIXまたはUNIXに似 たo Sを基にしたものがほとんどである。 そのため、 分散ファイル管理機能の実 現が中心である。 UN 1 Xを基にしたものには、 Newcast 1e-C onnect ion， C 0

C A N E T [R _{0 W} 8 2 J， 1 B 1 S [T i c 8 4 J， N F S [W a 1 8 5 J ， D P E [谷口86J， RFS [Rif86J， EFS [At186Jがある。 C OCANETは、 リモー トプロセス閣の通信も可能にしている。 ALTOS-N ET-II [Ka v83JはXENIX上、 GFS [Rod86JはULTRIX 上に搭載されている。 NEST [Agr87Jは、 処理を別計算機上で実行する

- 6 -

ことを実現している。 MOSIX [Bar89]は、 計算機内に最大8プロセッ サを持ちその計算機関をLANで結んだ分散環境で走行し、 UNIXインタフェ ースを実現している。

多くの研究は、 分散処理o SがAPに提供する機能について行なったものであ る。 これに対し、 分散処理o Sの構成法に関する研究例は少ない。 多くの分散処 理o Sは、 メ yセージ通信を構成の基本としている。

1 ^_ 4

1. 4. 1

ヱド言命三之ι〉石汗ラモ主果是重

目的

本研究は、 分散処理o Sの構築法に関する指針を示すことを目的とする。

同種プロセッサによる計算機を結んだ分散環境において、 分散処理o Sを構築 する際の要求条件と検討課題を明らかにする。 また、 各検討課題についていくつ かの対処方式を提案し、 それらと分散処理o S構築の実現方式との関係を述べる。

さらに、 サービス処理の内容に合わせた分散処理o Sの構築例とシステム例によ り、 上記の要求条件や検討課題の妥当性を示すと共にサービス処理の内容と対処 方式の関係を示す。

これにより、 サービス処理の内容に合わせた分散処理o Sの構築が可能になる。

1. 4. 2 内容

分散処理o Sの構築に対する要求条件について、

( 1 )スタンドアロン環境と分散環境を、 APに提供するAPインタフェース

形式

( 2 )機能や負荷の分散を行なえる程度

の観点から検討する。 また、 o Sのプログラム構成に着眼し、 四つの検討課題を 示すO さらに、 各検討課題についていくつかの対処方式を提案し、 それらが要求 条件を満足できる程度および分散処理o Sを新規に作成する場合や既存の同種O Sを結合する場合との関係を明らかにする。

新規に分散処理o Sを作成した例として、 トランザクシ ョ ン処理用の分散処理

-7-

o sを示す。 このo sは、 スタンドアロン環境と分散環境を統ーしたインタフェ ース形式でAPに提供している。 さらに、 AP処理とo s処理の両方について機 能や負荷の分散を可能にしている。 その構築においては、 トランザクシ ョ ン処理 に適した対処方式の選択がなされている。 次に、 既存の同種o sを結合して分散 処理o sを作成した例として、 会議サービスなどの分散協調処理を可能にする分 散処理o sを示す。 このo sは、 スタンドアロン環境と分散環境を統ーしたイン タフェース形式でAP'こ提供している。 AP処理の機能や負荷の分散を可能にし ているものの、 o s処理については実現していない。 一方、 検討課題の一つであ る通信路の扱いにおいて、 通信路の特徴を生かした機能をAPに提供している点 が大きな特徴である。 これらにより、 分散処理o sの構築における要求条件と検 討課題の妥当性を示すと共に、 サービス処理の内容と 対処方式の関係を明らかに する。

1 ^_ 5 ::::zド言命コミこCD牢管局文

以降、 2章では、 分散処理o sを構築する際の基本方式を述べる。 3章では、

新規に分散処理o sを作成する場合の方式を述べる。 4章では、 3章で述べた新 規分散処理o sの特徴を生かしたサービスとして、 高信頼システムについて述べ る。 5章では、 既存の同種o sを結合する場合についてファイル管理 機能をネッ トワーク化する方式を述べる。 6章では、 5章で述べた既存同種の分散処理o s の特徴を生かしたサービスとして、 電子会議システムについて述べる。 7章では、

2章から6章までのまとめと残された課題を述べる。

-8-

多有二二宝章主 タミテ置支タ岳王里o s牢毒多箆α〉主基ヱドズコ「玉丈

本章では、 分散処理o sを構築する基本的な方式について述べる。 以降、 2.

1節では、 分散環境をAPに提供するo s機能のインタフェースやo sプログラ ムの構成に要求される条件について述べる。 2. 2節では、 分散処理o sを構築 する上の検討課題を挙げると共にそれらに対する対処方式を提案する。 2. 3節 では、 分散処理o sを構築する実現方式の違いと上記の要求条件や検討課題の関 係について述べる。

2 ^_ 1 芸雲オミミ会主イ牛

2. 1. 1 応用プログラムインタフェース

分散環境で多種多様なサービスを提供するためには、 多くのAPを用意する必 要がある。 これを効率的に行なうため、 二つのことが望まれる。 一つは、 APの 新規作成量を少なくするため、 スタンドアロン環境で動いているプログラムを分 散環境にも利用できることである。 もう 一つは、 APの作成を容易にするため、

分散環境を意識した処理部分は局所化でき、 プログラムはスタンドアロン環境と 同様な考え方で作成できることである。

これらの要望を満足するには、 分散処理o sがAPに提供するプログラムイン タフェース(以降、 システムコールと呼ぶ)は、 次のようでなければならない。

APが走行する計算機と同じ計算機内にある資源(以降、 ローカル資源と呼ぶ) と、 APが走行する計算機とは別の計算機にある資源(以降、 リモート資源と呼

ぶ〉を統一的な形で見せることである。 具体的には、 システムコールについて、

次の二つのことが求められる。 一つは、 同種の資源に対する操作は、 ローカルや リモートに関係なく同じシステムコールで行なえることである。 もう一つは、 シ ステムコールのパラメータ内にある操作対象資源の指定法をローカル資源とリモ ート資源で統ーすることであり、 「資源の名前付け」問題[古宇田8 8 ]に帰着

- 9 -

する。 ここでいう資源には、 ファイル， 入出力装置， メールボックス， セマフォ などの資源、 さらに分散環境に特有なプロセッサ資源がある。

分散処理o Sが上記の要求条件を満足することにより、 次のようなことが可能 になる。 例えば、 スタンドアロン処理での柔軟性向上を目的に、 操作する資源名 をプログラムの外部から指定できるように作成されたプログラムについて考える。

このプログラムは、 分散環境を意識しないで作成されたにもかかわらず、 分散処 理o S下で走行させることにより、 そのまま分散環境で利用できる。

2. 1. 2 機能分散と負荷分散

プロセッサ能力や通信能力および入出力装置の構成に合わせて柔軟かっ効率的 に分散環境を構築でき、 かっ性能やメモリ効率の良いシステムを構築できること が大切である。 このためには、 機能分散や負荷分散がAP処理だけではなくo s 処理も含めた両方で可能でなければならない。

AP処理の分散は、 2. 1. 1項で述べた要求条件に加え、 次の要求条件をO Sが満足することにより 可能になる。 それは、 AP処理を行なうAPプロセスの 生成や制御を任意の計算機lこ対して自由に行なえることである。 つまり、 2. 1.

1項で述べた資源に対することと同様なことがAPプロセスに対しても満足でき ることである。

一方、 o s処理の分散を可能にするには、 o sに次の対処が必要である。 一つ は、 o sの機能を特定のまとまった機能単位に分割できることである。 もう一つ は、 分割した各機能を実現しているプログラム(以降、 処理モジュールと呼ぶ) 聞のインタフェース(以降、 内部コールと呼ぶ)が、 同一計算機内と別計算機関 で統ーされていることである。

2 _ 2 求書草多草Eーとι〉差果是墓と文寸6111ズヨf玉丈

本節では、 分散処理o Sに対する要求条件(資源やAPプロセスの操作に関す るAPインタフェースの統一， ⁰ S処理の分割と分割されたプログラム間のイン タフェースの統一)を満足するため、 o Sのプログラム構成に関する課題、

-10-

. 0 Sの機能を、 どのように分割するか? (分割単位)

・ 処理モジュール間で、 何をやりとりするか? (インタフェース)

- 処理モジュール間で、 どんな形でやりとりするか? (通信インタフェース)

・ 処理モジュール間で、 通信路をどのように扱うか? (通信路との関係) について、 対処方式を提案し特徴を示す。

本節で説明するo Sの構造およびo SとハードウェアやライブラリやAPとの 関係を図2. 2- 1に示す。 図2. 2 - 1において、 実線は、 システムコールの インタフェースを示す。 破線は、 ライブラリコールのインタフェースを示す。 ラ イブラリとは、 システム コールを更にAPから使いやすくしたインタフェースで ある。 一点鎖線は、 内部コールのインタフェースである。

2. 2. 1 機能を実現する処理モジュールの分割単位

分散処理o Sの各機能を実現する処理モジュールを分割する単位は、 分散でき るo S機能の単位にそのまま対応する。 したがって、 その分割は、 分散処理o S を構築する上で重要な検討項目である。 機能を細かく分割すると、 分散できる機 能の柔軟性は高いが、 処理モジュール聞の通信が増加し性能が低下する。 したが って、 この対処においては、 分散できる機能の柔軟性と分割による性能低下の兼

ね合いに留意する必要がある。

最も簡単な分割として、 各計算機上で走行するo Sをひとつの分割された単位 と考えることができる。 これに対し、 各o Sを分割する方式は、 大きく三つに分 類できる。 各々の分割方式について、 様子と特徴を図2. 2. 1-1および表2.

2. 1 - 1に示し、 以下lこ説明する。

資源制御処理分割方式は、 資源の管理や供給や操作を行なう処理を単位とする 方式である。 例えば、 ディスクやプリンタなどの資源を管理する処理、 資源への

アクセス を制御する処理などが、 分割の単位になる。 本方式は、 分割の単位が大 きいため、 システムコールの処理実行に伴う処理モジュール閣の通信回数が少な

L 、。 したがって、 構成が容易である。 さらに、 計算機内に閉じた処理(以降、 ロ ーカル処理と呼ぶ。 これに対し、 計算機聞にまたがる処理をリモート処理と呼ぶ〉

の性能低下はほとんどない。

システムコール 処理分割方式は、 システムコールの機能を実現する処理を単位

応用プログラム ⁽A P)

，e"""' ライブラリh“句、、、、、、、

〆//' J〆--- | 、、、一 ""、、

/'

./オベレ -fイング � ^""

-

，/ / シスナム(0 S )

'"'"

/ / l'ー、... ^{"\. 、}

/ 、Z品山自 I '"・1ファイル\ ^、

/ /

I "'(_' I'F \

/

. ぺ三 一一一 I "1山市“自\管理 \

! /

I

\

i I

/

ヘ \ \

: I

( \

^\ \ \

I I

^l l

\ �一

理 1 J

\

\

I �lJ歯車 /

\

，回..I...h 帥守山也、

\

\

1

/

\. ，一一盛司、

I

/ ノ

\

"\.(装置管理) I γ…ー

/

、 ー孟一一 I (プロセス制御)/

ノ

\ \之 | 等 / ^/

�

l、-、 、、‘司、� I t _.. �〆.. ， .'

-、、司-、、 、、-- 1 -� " ，，'

DK:磁気ディスク

FD:フレキシブルディスク HDLC:ハイレベルデータリンク

システムコールのインタフエース ライブラリコールのインタフエース

内郡コールのインタフェース

図2. 2ー1 0 Sの構造およびハードウエア等との関係

- 12-

( 1 )資源制御処理分割方式 _{( 2} )システムコール処理分割方式

図2. 2. ^{1 - 1} 処理モジュールの分割方式

- 13-

( 3 )実行時処理分割方式

分割方式

資源制御処理

システムコール処理

実行時処理

表2. 2. 1-1 各分割方式の特徴

長 所 短 所

( 1 )ローカル処理の性能I( 1 )細かなOS機能の分散が難 低下はほとんどない。| しい。

(2 )構成が容易である。1 ( 2 )障害時の影響が大きい。

( 1 )利用者からみたOSI(l)OS内部に閉じた処理の分

機能の分散ができる。| 割が難しい。

( 2 )特別なハードウェア 支t震を必要としない。

( 1 )分散できるプロセッI( 1 )ローカル処理の性能低下が

サの数が多い場合、 並| 著しい。

列処理が進み性能向上1 ( 2 )リモート処理の性能向上の が見込まれる。 I ためにはハードウェアの支媛

- 14-

が必須である。

( 3 )性能が低下しやすいためフ

ァイル系機能の分散が中心で ありプロセス系機能の分散は 難しい。

とする方式である。 例えば、 メ ッセージ制御やセマフォ制御あるいはディスク制 御やプリンタ制御などが、 分割の単位になる。 本方式に基づく分散処理o sは、

APから見えるシステムコールの各機能単位で分散を図ることができるため、 A P設計者がo s機能の分散を設計することも可能である。

実行時処理分割方式は、 排他アクセスされる資源の各々や各APプロセスの管 理に割り当てられるものを制御している処理を単位とする方式である。 例えば、

プロセスAがファイルAにアクセスする制御、 プロセスAがファイルBにアクセ スする制御、 プロセスBがファイルAにアクセスする制御などが、 分割の単位に なる。 本方式は、 非常に細かな単位を処理モジュールとする。 そのため、 o s機 能を分散し並列処理化することで性能向上が期待できる。 しかし、 システムコー ルの処理実行に伴う処理モジュール間の通信回数が非常に多いため、 性能低下を

招く恐れもある。

2. 2. 2 処理モジュール聞のインタフェース

処理モジュール聞のインタフェースは、 ライブラリコール転送とシステムコー

ル転送と内部コール転送に分類できる。 各々のインタフェースの様子と特徴を図 2. 2. 2 - 1および表2. 2. 2 - 1に示し、 以下に説明する。

ライブラリコール転送とは、 ライブラリコールのインタフェースでネットワー

ク化する方式である。 つまり、 ライブラリコールをリモートに転送し、 実行する。

この方式は、 o sがAPに提供するプログラムインタフェースであるシステムコ ールをAPから隠ぺいしている。 そのため、 異なるo s間での分散環境構築が容 易な方式といえる。

システムコール転送とは、 システムコールのインタフェースでネットワーク化

する方式である。 つまり、 システムコールをリモートに転送し、 実行する。 AP のプロセスは、 システムコール発行により制御をo sに移す。 したがって、 本方 式は、 スタンドアロン環境で走行するAPプロセスのロードモジュールを、 その まま分散環境でもAPプロセスとして走行させることができる。

内部コール転送とは、 内部コールのインタフェースでネットワーク化する方式 である。 つまり、 内部コールをリモートに転送し、 実行する。 この方式は、 別計 算機上のo sの処理モジュール間でも直接のインタフェースを持つことができる。

- 15

システムコール転送

...

ライブラリコール転送

も…・・日……・…・・・・・・…・・・…・・・・・・・・・…...・・・・・骨

システムコールのインタフエース ライブラリコールのインタフエース

内郡コールのインタフエース

図2. 2. 2-1 処理モジュール間のインタフエース

表2. 2. 2-1 各インタフェースの特徴

種 類 長 所 短 所

( 1 )異種os聞の結合が比較 ( 1 )応用プログラムについ ライブラリコール 的容易にできる。 て、 スタンドアロン環境

転送 と分散環境のロードモジ

ュール互換がない。

( 1 )応用プログラムについて ( 1 )内部コール転送に比べ スタンドアロン環境と分 リモート処理が遅い。

システムコール転送

|

互換がある。 L】。

( 2 )処理モジュール聞のイン

タフェース整合が取りやす L、。

( 1 )応用プログラムについて ( 1 )システムコール転送に スタンドアロン環境と分 比べ処理モジュール間の 内部コール転送 散環境のロードモジュール インタフェース整合が取

互換がある。 りにくい。

( 2 )リモート処理が速い。

( 3 ) 0 S機能を分散できる。

リモート

，、』

- 17-

そのため、 リモート処理が速い。

一つのosを分割の単位とする場合は、 ライブラリコール転送とシステムコー ル転送の両インタフェースが可能である。 os内をいくつかの単位に分割した場 合は、 3項目すべてのインタフェースが可能である。

o sの処理

i し ... L...

... ...

... ...

... ...

_ ...

... ...

2. 2. 3 処理モジュール間の通信インタフェース

ライブラリコールに基づく処理内容， システムコールに基づく処理内容および 内部コールに基づく処理内容(以降、 これらをまとめてジョブと呼ぶ)を処理モ ジュール間で送受信する通信インタフェースについて述べる。

通信インタフェースは、 ジョブ送受信時のジョブの状態により、 完了型と非完 了型に分けられる。

完了型とは、 ジョブを実行する処理モジュールが、 ジョプの依頼を受信したこ とを契機としてジョブ実行を開始し、 その結果返却時にプロセッサ利用の権限を ジョブを依頼した処理モジュールに戻すものである。 ジョブの実行で待ちを必要 とする場合は、 ジョブを実行する処理モジュール側で待つ。 そのため、 ジョブの 実行が終了しないとジョブを依頼した処理モジュールにプロセッサ利用の権限が

( 1 )完了型の処理

一方、 非完了型とは、 ジョブの結果返却とプロセッサ利用の権限移行が独立し ているものである。 ジョブを実行する処理モジュールは、 ジョブの依頼を受け付 けた時点で、 プロセッサ利用の権限をジョブを依頼した処理モジュールに戻す。

ジョプを依頼した処理モジュールは、 別の処理を実行でき、 適当な所でジョブの 結果返却を要求する。 どうしても完了の形態で扱いたい場合は、 ジョブ依頼の受 付によりプロセッサ利用の権限を受け取った直後に、 ジョブの結果返却を要求し てジョブを依頼した処理モジュール側で待つ。

上記の違いは、 そのままシステムコールの形式に現われる。 完了型の通信イン タフェースの場合、 システムコールは完了型になる。 一方、 非完了型の通信イン タフェースの場合、 システムコールは完了型と非完了型の二つが考えられる。 完

OS(7)処理

戻らない。

今 之ど〉

hF F 〈 -- 回』 --

-- -- . ，ii !

--

1・・ M，- --

-

-

-

- -

- -

+咋

キ←

圃圃

-­

-

-

-

- -

-

園田

--

-

-- -- 曲目 --

-申 ドIP

E--

ドーーーーーーー-...由ーー田園田ーーー惨

( 2 )非完了型の処理

了型と非完了型のシステムコール処理の流れを図2. 2. 3 - 1に示す。 完了型 の処理では、 osの処理終了により結果と共に制御が戻ってくる。 一方、 非完了 型の処理では、 処理の依頼や結果の取得の度に制御が戻ってくる。 このため、 完

図2. 2. 3

-

-18- -19-

了型のシステムコールは、 結果を格納し管理する処理を必要としない。 したがっ て、 プロセッサ負荷が少ない場合は処理効率がよい。 しかし、 多くの処理を行な うためには多くのプロセスを必要とするため、 o Sオーバヘッドが大きい。 これ に対し、 非完了型のシステムコールは、 一つのプロセスで多くの処理を行なうこ とができる。 そのため、 高プロセッサ負荷のシステムに向いている。

2. 2. 4 処理モジュール閣を結ぶ通信路との関係

分散処理システムにおいては、 各々の計算機を種々の通信路で結合している。

したがって、 o Sの各機能を実現している処理モジュールを分散すると、 その処 理モジュール間の通信路には色々なものが存在することになる。 多種の通信路を 利用して分散環境を構築するには、 単に計算機関をそれらで結ぶだけ ではなく、

通信路の特徴を生かしながらその違いを隠ぺいするという課題がある。

通信相手を選択する観点から、 通信路は大きく三つに分類できる。 一つは、 R

S _{2 3 2} Cのように一対一通信でアドレスの概念を必要としないものである。 一

つめは、 DDX-CSのようにアドレスにより、 一対一通信を可能にしているも のである。 三つめは、 LANのように一対一通信だけではなく、 一つのアドレス に複数の計算機を割り付けることにより一対複数のグループ通信も可能にしてい るものである。

これらの通信路の特徴を生かした形で、 処理モジュール閣の通信を提供する必 要がある。 例えば、 グループ通信の同時通信性を生かせば、 分散データベースで 必要とされている分散資源の内容一致保証の実現に有効である。 さらに、 通信路 の違いを処理モジュール 聞の通信インタフェースに見せないことが大切である。

その結果、 処理モジュールは自由に通信路を利用できるため、 処理モジュールの 自由な分散を可能にできる。

2 ^_ 3 �定王見交7玉丈cz:>是撃し、よるタテ業頁

同種o S閣を結合して分散処理o sを構築する場合、 新規に作成する方式と既 存o Sを結合して作成する方式がある。 各方式について、 要求条件に対する満足

- 20

度や構築上の課題に対する対処度を表2. 3- 1に示す。 当然、のことながら、 新 規にo Sを作成する場合は各項目とも自由度が大きい。

例えば、 APインタフェースについては次のようになる。 新規に分散処理o S を作成する場合には、 要求条件を満足できる。 しかし、 既存o Sの結合により分 散処理o Sを作成する場合、 すべての資源について要求条件を満足することは難 しい。 そのため、 要求条件の満足が難しい資源については、 分散環境に特有な処 理としてアクセスを独立した形で見せることが大切である。 分散環境に特有な資 源であるプロセッサ資源についていえば、 既存のシステムコールにパラメータ追 加を行なうより、 プログラムが走行するプロセッサ指定を行なう新規システムコ ールを提供した方がよい。 例えば、 同じ処理を各計算機のプロセッサで行なう処 理の場合を考える。 処理を実行するプログラム部分と処理するプロセッサを指定 する部分に分離してプログラムを作成することにより、 分散環境を意識した処理 部分を局所化できる。

また、 分割単位については次のようになる。 既存o Sを結合して分散環境を実 現する場合、 性能向上のために内部構造が複雑になっていたりソースコードが入 手できない等の理由により、 o S内を分割することは不可能である。 そのため、

o Sひとつひとつを分割単位とせざるをえない。 一方、 新規に分散処理o Sを作 成する場合の分割単位は、 自由に設定可能である。

1. 3節で述べたように、 新規o S作成方式の例としていくつか発表されてい る。 これらは、 内部コール転送で構築され、 AP処理だけではなくo S処理の分 散も可能にしている。 一方、 既存o S結合方式の例もいくつか発表されている。

これらは、 主にファイル管理機能のネットワー ク化を図ったものである。 また、

既存のスタンドアロンo Sへの改造を小さくするため、 ライブラリコール転送や システム コール転送で構築されている。

異種o S間を結合して分散処理o Sを構築する場合、 要求条件を満足できる程 度は個々のo Sにより差が生じる。 また、 構築上の課題については既存o S結合 方式の場合とほぼ同様である。 しかし、 処理モジュール間インタフェースとして ライブラリコール転送またはシステムコール転送を用いるため、 それらをo S聞 の機能差に基づいて変換する方式を検討する必要がある。 具体的には、 機能変換 と形式変換およびエラー 発生時の処理とエラー値の変換である。

章第

来斤士見イ乍尾文によるタミト費支度ß王里o s 表2. 3 -₁ 同種os間結合による分散処理os構築上の特徴

一一一一一一一一

ローカル資源とリモ ローカル資源の管理 APインタフェース ート資源の統一的見せ 法に影響されリモート

要求条件 ^{方が可能 資源との統一的見せ方}

には限界がある

織能 ・ 負荷分散 APとosの両方に APについての分散 ついて分散が可能 が可能

分割単位 自由に設定可能 osが単位

ライブラリコール転 ライブラリコール転

インタフェース 送とシステムコール転 送とシステムコール転 構築上の課題

送および内部コール転 送が可能 送が可能

通信インタフェース 自由に設定可能 既存osのインタフ

[

エース形式に依存

通信路 自由に設定可能 既に提供されている

|

機能に依存

本章では、 新規作成により分散処理o Sを構築する 場合について述べる。 この 場合、 2. 1節で述べた要求条件を満足することは可能である。 構築上の課題に ついては、 2. 2節で述べたように様々な対処方式がある。 ここでは、 二つの大 きな特徴を持つo S構築方式について説明する。 第一の特徴は、 処理モジュール 間インタフェースとして、 システムコール転送と内部コール転送の両方を可能に していることである。 これにより、 AP処理だけではなくo S処理の分散も可能 にしている。 第二の特徴は、 通信路として、 ハードウェアパス結合による共有メ モリとプロセッサ間割り込みの場合だけではなく、 SC S 1 (S mall Computer

S ystem 1 nterface)やLANの場合を含む3種類の通信路を利用できることで ある。 これにより、 通信の速度や形式や距離が異なる3種の通信路で結合された

環境での分散処理を可能にしている。 以降、 3. 1節では、 新規に分散処理o S を作成している事例を比較する。 3. 2節では、 分散処理o Sのプログラム構造 の一つであるリクエスト制御方式を提案する。 また、 その基本構造と特徴につい て述べる。 3. 3節では、 リクエスト制御方式に基づいて作成したo Sの実現例 について述べる。 3. 4節では、 性能評価と考察を行なう。 3. 5節では、 本章 のまとめを述べる。

3 . 1 タミヤ茸女史l1王里o s ι〉孝誇反文主去

新規に分散処理o sを開発する方式の例は、 1. 3節で述べたように既にいく つか発表されている。 それらの中で、 内部コール転送を行ないAP処理だけでは なくo S処理の分散も可能にしているo Sとして、 Ago r a-I [田胡8 ₇ ] やCOSMOS2 [土屋8 ₇ ]がある。 これらは、 内部コール転送を行なう処理 モジュールの分割において、 次の問題がある。

A g 0 r a - 1は、 相互排他アクセスされる資源の各々を制御している処理部

- 22-

分や各利用者プロセスに対応する処理を行なう処理部分を処理モジュールとする 実行時処理分割方式を採用している。 そのため、 一つのシステムコールにより数 十回の内部コール転送が発生し、 ローカル処理における性能低下を招いている。

これを防ぐため、 内部コール転送をハードウェアで支援することが必須である。

また、 多数の内部コール転送によるo s全体の性能低下を防ぐため、 処理モジュ ールの分 割lこ留意する必要がある。 例えば、 入出力装置とのデータ授受を伴うフ ァイル1/0の処理は処理時間が長いため、 この処理部分に適用している。 これ に対し、 プロセス制御などの処理は、 プロセッサによるメモリ内処理が中心にな り処理時間が短く、 かつ非常に走行回数が多いため、 この処理部分には適用して いない。

COSMOS2は、 資源制御処理分割方式を採用している。 この方式の処理モ ジュールは、 資源の管理や供給や操作を処理している3種類の部分からなってい る。 そのため、 細かなo s機能分散が難しい。 また、 分散環境を一つの密接なシ ステムとしてとらえている。 したがって、 鍵となる計算機が停止すると分散処理 システム全体が停止して しまうので障害に弱いといえる。

ここでは、 システムコール転送と内部コール転送を同時に可能にし、 AP処理 と共にo s処理の分散を可能にする「リクエスト制御方式J [谷口8 ⁹ AJにつ いて述べる。 ここで、 リクエストとは、 ジョブを依頼する処理モジュール(以降、

依頼処理モジュールと呼ぶ)とそのジョブを実行する処理モジュール(以降、 被 依頼処理モジュールと呼ぶ)との種々のやりとり(ジョブの依頼や結果取得や結 果応答など)を意味する。 リクエスト制御方式は、 プロセッサ間の通信種別を隠 ぺいしている。 つまり、 プロセッサ内や計算機内プロセッサ間および計算機関プ ロセッサ閣の各々の通信を、 統ーしたインタフェースで処理モジュールに提供し ている。 また、 ジョブ内容に依存しない形でリクエストを制御する。 本方式は、

2. 1節や2. 2節で述べた分散処理o sに対する要求条件と構築上の課題につ いて表3. 1 - 1の特徴を持っている。 本方式は、 特別なハードウェア支援を必 要としない。 また、 システムコール機能に対応させて 処理モジュールを分割する システムコール処理分割方式を採用することにより、 必要とされるo s処理の分 散を効率よく行なえる。

- 24-

表3. 1 - 1 リクエスト制御方式の特徴

ーーーーーー一ーーーーーーーーーーーーーーーーーーーーーー

APインタフェース ^{( 1} )ローカル資源とリモート資源、の統一的見

要求条件 せ方が可能

機能 ・ 負荷分散 ^{( 1} ) A Pとosの両面について分散が可能

( 1 )装置を制御する処理(ディスク制御なと

分割単位 )やAPに提供している各機能を実現する 処理を単位に分割

インタフェース ^{( 1} )システムコール転送と内部コール転送を 構築上の課題

実現

( 1 )非完了型の4つのインタフェース(依頼

通信インタフェース 結果取得， 取消し. 結果応答)

( 2 )同一プロセッサ内と別プロセッサ問を統

一

通信路 ^{( 1} )共有メモリとSCSIとLANの利用が

可能

3 2 リ クエス ト 告TJ笹口コぢ玉丈

3. 2. 1 基本構造

リクエスト制御は、 四つのインタフェース、 すなわち、 依頼処理モジュール側

からのジョブの依頼や結果取得や取消と、 被依頼処理モジュール側からの結果応 答とを基本とする方式である。 この制御では、 処理モジュールを分散環境で一意 な識別子で区別する。 具体的な構造について以下に説明する。

分割の単位は、 システムコール処理分割方式を採用して行なう。 つまり、 AP インタフェースであるシステムコールに対応する機能を実現している単位で行な う。 これ により、 必要とされる機能分散を可能にし、 かっ処理モジュール閣の通 信量を小さくできる。 具体的には、 セマフォ制御やメ ッセージ制御， ディスク制 御などである。

処理モジュールの識別は、 処理モジュール識別子と呼ぶ識別子により、 分散環 境で一意に行なう。 処理モジュール識別子(図3. 2. 1-1)は、 計算機番号 (computer number)とプロセッサ番号(processor number)とモジュール番号(

program module number)を持つ。 計算機番号は、 分散環境内においてその処理モ

ジュールが存在する計算機を識別する情報である。 プロセッサ番号は、 計算機内 においてその処理モジュールが存在するプロセッサを識別する情報である。 モジ ュール番号は、 処理モジュールの種別と内部番号を識別する情報である。

処理モジュール聞の情報授受は、 リクエストプロ ソクと呼ぶ制御プロックを、

依頼処理モジュールと被依頼処理モジュールの間で送受信することにより、 行な う。 リクエストプロックの一例を図3. 2. 1-2に示す。 リクエストプロック の内容は、 依頼処理モジュール識別子(object identifier of source)と被依頼 処理モジュール識別子(object identifier of desti nation)とジョブ内容(co ntent of the job)とデータ情報(data)と結果(resul けからなる。

依頼処理モジュールと被依頼処理モジュールの聞は、 四つのインタフェース、

すなわち、 ジョブの依頼(request a job)と結果取得(fetch the result)と取 消(cancel the job)および結果応答(respond with the result)からなる。 さ らに、 それらを六つの処理ルーチン(以降、 ユニット(un i t)と呼ぶ〉で制御す

- 26ー

f

program module number

processor number computer number

図3. 2. 1 - 1 処理モジュール識別子

C∞ompl附nu帥I宜I

program module number compl附number

J

program module number content ofthe job

data

result

A: object identifier of destination B _: object identifier of source

A

，

B

図3. 2. 1 _- 2 リクエストブロックの情成例

アクションユニットがジョブを受付けた後、 被依頼処理モ

依頼側処理モジューノレv処理ルーチン(ユニット) 通信制御部 処碍ルーチン(ユニγ卜) 被依頼処理モジュール

刊、 小 〆、

<ジョブ の依 頼>

リクエストブロ シ ①

クを作成し， その 転送を要求する。

る。 各ユニットは次のような機能を持つ。 “アクションユニット" は、 ジョブ依 頼の受付を行なう。 “レスポンスユニット" は、 ジョブ結果を解析すると共lこジ ョプ取消との整合を図る。 “リザルトユニット" は、 ジョブの結果取得と共に後 処理を行なう。 “クリーンユニット" は、 リクエストプロックの解放を行なう。

“キャンセルユニット" は、 ジョプ取消の前処理と後処理を行なう。 “キャンセ

ルアクションユニット" は、 ジョブ取消の受付を行なう。 これらのユニットの内、 ^処理開始

レスポンスユニットとリザルトユニットとクリーンユニットとキャンセルユニッ ^{リクエストブロ ァク}_の解析 <結果応答>

ー一一

① をリクエス ト ブロ γク 十て設定し， その返送を 要求する

トは依頼処理モジュール側が用意する。 また、 アクションユニットとキャンセル

アクションユニットは被依頼処理モジュール側が用意する。 リクエスト制御に基^{づく処理流れを図3. 2. 1-3に示すと共に、 以下に説明する。}

t' Il ! J AT

くs _{t e p} 1 > 依頼側処理モジュールがジョブの内容に基づいてリクエス のチェ ック ジョブの処理状態

K応じた取り消し を行う

トプロ yクを作成し、 通信制御部にその転送を要求する。 (図の①と②)

くs _{t e p} 2 > 通信制御部は、 被依頼側処理モジュールが走行しているプ ^{トフ.ロ γク}

の解放

ロセッサにリクエストプロックを転送し、 アクションユニットを起動する。 (図

J f

の③) 転送 処理のIRり消し

， ，

， t

くs _{t e p} 3 >

キャン セ ノレアク ションユニント

。 @

ジュールはジョブに基づいて処理を開始する。 (図の④)

くs _{t e p} 4 > 処理が終ると、 被依頼処理モジュールはジョブ結果をリク

通常処理フ ロ ー ①ー⑦→①→守→①→⑤→①→⑤→①

キャンセノレ処理フロー @→@→@→@→①→@→①→@→①→or @→@→@→①

エストプロックに設定し、 通信制御部にその返送を要求する。 (図の⑤と⑥)

E今， ∞:処理の呼び出し

くs _{t e p} 5 > 通信制御部は、 依頼処理モジュールが走行しているプロセ

yサにリクエストブロックを転送し、 レスポンスユニ ットを起動する。 (図の⑦) 図3. 2. 1-3 リクエスト制御に基づく処理流れ

くs _{t e p} 6 > レスポンスユニットはリクエストプロックの内容を解析す

る。 リザルトユニットが処理結果を確認後、 依頼処理モジュールは結果を受け取

る。 必要に応じて、 クリーンユユットがリクヱストブロ ックを解放する。 (図の

⑧と⑨〉

く取消s t e p > ジョブの取り消しを要求され ると、 ジョブの現処理状態

に応じた ユニットを起動する。 例えば、 ジョブに基づいた処理が被依頼処理モジ ュールに より実行されている場合は、 通信制御部を介してキャンセルアクション ユニットを起動し、 ジョブを取り消す。 一方、 ジョブ結果が既に返送されている 場合は、 レスポンスユニットを起動してジョブ結果を捨てる。

- 28-

ハヨ

図3. 2. 1-3に示されている通信制御部(transfer control)は、 リクエス トプロックの送受信を司る部分である。 この制御部は、 プロセッサ内や計算機内 プロセッサ間および計算機間プロセッサ聞の通信差異や通信層による相違〈例え ば、 計算機関の結合にLANやs _C S 1が利用されていること等)を吸収して外 部にその差を見せない。

3. 2. 2 特徴

リクエスト制御は3. 2. 1項で述べた構造になっているため、 いくつかの特 徴を持つ。

第一の特徴は、 図3. 2. 1-3に示した通信制御部が下位の各種通信層の違 いを吸収していることである。 具体的には、 処理モジュール間インタフェースと してプロセッサ内と計算機内プロセッサ間と計算機関プロセッサ聞を統ーした形 式で提供している。 これにより、 処理モジュールは通信レベルの違いを全く意識 しない。 そのため、 o s構成として、 処理モジュールをハードウェア構成に合わ せて最適なプロセッサ上で走行させることができる構成を容易に実現できる。 ま た、 ある処理モジュールに陣害が発生しでも、 別プロセッサの同種の処理モジュ ールにジョブを依頼することにより、 信頼性を上げることができる。 例えば、 フ ァイル管理がディスク制御を利用したデータ読み出しを考える。 ファイル管理は、

ディスク制御がどのプロセッサ上にあっても、 リクエストプロック内にあるディ スク制御処理モジュール識別子の計算機番号やプロセッサ番号を変更するだけで、

同じ形式でデータの読み出しができる。

第二の特徴は、 ジョブ内容に依存しない形で処理モジュール閣のリクエストを 制御していることである。 このため、 システムコール転送と内部コール転送の両 方を利用した分散処理o Sの構築が可能になり、 AP処理だけではなくo S処理 の分散も図れる。 例えば、 APに提供しているファイル生成のシステムコールを 別プロセッサにある各ファイル管理の間で転送すれば、 すぐに、 リモートへのフ ァイル生成が行なえる。 また、 データ読み出しの内部コールをファイル管理とデ ィスク制御の間で転送すれば、 ローカルやリモートを意識することなくディスク からのデータ読み出しが行なえる。

第三の特徴は、 処理モジュール間が簡明なインタフェースで結合されることで

一30ー

ある。 このため、 処理モジュールの追加や削除(つまり、 o S機能の追加や削除) が容易にできる。 伊jえば、 他の処理モジュールを利用しないプリンタ制御を追加 する場合、 わずか二つの “ユニット" (処理ルーチン〉をインタフェ ースとして 提供するだけでよい。 具体的には、 “アクションユニット" と “キャ ンセルアク ションユニット" である。

第四の特徴は、 別プロセッサ上で走行する処理モジュール聞の直接通信が可能 であることである。 これにより、 性能が向上する。 例えば、 リモートのディスク にアクセスする場合、 二つの方法がある。 一つは、 APが走行しているプロセッ サ上でAPからのアクセス要求を受け付けたフ ァイル管理と、 ディスクを持つプ ロセッサ上のファイル管理との問で、 システムコール転送を行なう方法である。

これをリモートファイル アクセスと呼ぶ。 もう一つは、 APが走行しているプロ セッサ上でAPからのアクセス要求を受け付けたファイル管理と、 ディスクを持 つプロセッサ上でディスクを制御するディスク制御との間で、 内部コール転送を 行なう方法である。 これをリモートデバイスアクセスと呼ぶ。 前者の方法では、

ディスクを持つプロセッサ上でファイル管理とディスク制御間の内部コール転送 も必要であるため、 後者が速い。

第五の特徴は、 取消インタフェースを持つことである。 このため、 APに対し 処理受付と結果取得および処理取消を各々別システムコールとする機能を提供で きる。 これを非完了システムコール機能と呼ぶ。 これに対し、 処理受付と結果取 得を一つのシステムコールとする機能を完了システムコール機能と呼ぶ。 ローカ ルで速い処理もリモート処理では遅くなる。 そのため、 ローカルやリモー卜の処 理を完了システムコールで提供すると、 ジョブの結果と共に制御が戻ってくるこ とになるため、 待ち状態のプロセスが多数発生し処理効率が低下する。 一方、 非 完了システムコールを利用すれば、 一つのプロセスが多くの様々な処理をo ^Sに

要求できる。 そのため、 待ち状態のプロセスが発生することは少ない。 このこと は、 分散環境においてリアルタイム処理を実現する場合、 重要である。 リクエス 卜制御は、 非完了システムコール機能の提供により、 リアルタイム処理向き分散 処理o sの構築も可能にしている。

-31 -

3 3 リ クエス ト 告リ径ロヌコ「三文0.:>霊長室王見イ列

リクエスト制御方式に基づいて構築した分散型リアルタイムOS(DIROS

D 1 stributed Reaトtime 0 perating S ystem) [水谷87 ] [谷口89 CJ について述べる。 DIROSは、 マルチマイクロプロセッサからなる計算機を高 速通信路で複数台結合した分散環境で走行し、 トランザクシ ョ ン処理を可能にし ている。 D 1 R 0 Sは、 リクエスト制御方式に基づいて構築することにより、 リ モートフ ァイルアクセス機能やリモートデバイスアクセス機能、 さらにマルチプ ロセス生成機能[谷口89 BJやリモートプロセス開通信機能を実現 している。

また、 その実現においては、 スタンドアロン環境と分散環境のAPインタフェー スを同様にする「資源アクセスのネットワーク透過性jの性質を持っている。

3. 3. 1 ハードウェア環境

プロセッサ間通信や各制御部構成の観点から見た場合、 D 1 R 0 Sが走行する

、ードウェア環境 は次のようになっている。 ハードウェア環境の例を図3. 3.

1 - 1に示し、 以下に説明する。 同一計算機内の各プロセッサ(processor)は、

コモンパス(common bus )と呼ぶハードウェアパスにより結合されている。 各プ

ロセッサは、 各プロセッサ共通のメモリ〈以降、 共有メモリ(shared memory)と 呼ぶ)とプロセッサ割込みにより通信を行なう。 共有メモリへは、 各プロセッサ からアクセスできる。 しかし、 各プロセッサが 持つDM A C (D i rec t M emory A ccess C ontroller)からはアクセスできない。 計算機関は、 S C S 1やLAN で接続している。 計算機内のプロセッサ数は1から8まで自由に構成できる。 各

プロセッサは、{也のプロセッサからはアクセスできないローカルメモリ(local memory)を持つ。 プロセッサとその配下にある制御部(controller)は内部パス ( internal bus)により結合されている。 自プロセッサ内において、 制御部の数 や種類は自由に構成できる。 このような構成になっているから、 求められるサー ビスに合わせた ハードウェア環境を実現できる。 したがって、 これをうまく制御 することがD r R 0 Sに求められる。

3. 3. 2 リクエスト制御方式の適用

- 32-

computer A Local Area Network

computer B

r ZE--ties ^江

shared ^•

memory

•

•

L__ーーーーーーーーーーーーーーーー

computer C

口j l

寸! け

ーー_J Interfac

�

'-ーーーーーーーーーー四ーーーーーー_1

図3. 3. 1 - 1 ハードウェア環境の例

- 33ー