JPH08297585A - オペレーティングシステムによるデータ転送方法 - Google Patents

Abstract

(57)【要約】 【目的】アプリケーションプログラムからの要求にした
がって入力元リソースから出力先リソースへＯＳがデー
タを転送するときのオーバヘッドを軽減する。 【構成】ユーザプロセス１により、データ転送に使用す
る入力元リソースと出力先のリソースの対をチャネルと
してＯＳに指定し、チャネル登録処理部７によりこれを
チャネル構造体１３Ａ〜１３Ｎの一つに登録する。さら
に、そのユーザプロセス１より、使用するチャネルと転
送すべきデータ量を指定して、ＯＳにデータ転送を要求
する。転送処理部２の制御の元で、このチャネル用に、
ＯＳカーネル空間内にバッファ１０を確保し、入力先リ
ソースをアクセスするための入力処理部８と出力先リソ
ースをアクセスするための出力処理部９を選択し、選択
された入力処理部と出力処理部により、指定された量の
データの転送が終了するまでをこのバッファ１０を繰返
し使用してデータ転送を繰り返す。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、計算機システムにおい
て、アプリケーションプログラムがオペレーティングシ
ステム（ＯＳ）に、特定のリソースが関与するデータ転
送を要求し、ＯＳがそのリソースを用いてデータ転送を
実行するデータ転送方法に関する。

【０００２】

【従来の技術】図１３に示すように、代表的な計算機シ
ステム３００上では、１つまたはそれ以上のプロセッサ
や主記憶を有する処理システム３０１内で動作するアプ
リケーションプログラム３０２が、ＯＳ（３）の管理の
下に、磁気ディスク装置３０４上のファイル３０７や、
ネットワーク３０５に接続された送受信回路内のバッフ
ァ、コンソールディスプレイ３０６内のビデオＲＡＭあ
るいは同じ計算機上で走行する別のアプリケーションプ
ログラム３０３などに対して、データを入出力しつつ処
理を進めている。以下では、転送すべきデータの入力元
として使用される、磁気ディスク装置装置上のファイ
ル、ネットワークに接続された送受信回路内のバッフ
ァ、コンソールディスプレイ内のビデオＲＡＭ、アプリ
ケーションプログラムまたはその他の、入力元のデータ
を保持すると論理的に考えられるリソースを、互いに区
別しないで呼ぶときには、これらを「入力元リソース」
と呼び、そのデータの出力先としてこれらのリソースの
いずれかが使用されたとき、それらのリソースを「出力
先リソース」と呼ぶことにする。このようなリソースに
対するデータの入出力処理の一つは、入力元リソースか
らデータを読み出し、読み出されたデータに処理を施す
ことなく、出力先リソースにそのまま移動することであ
る。以下では、このようなデータ移動をデータ転送とも
呼ぶ。

【０００３】近年分散ネットワークコンピューティング
や超並列プロセッサ計算機の普及、あるいはマルチメデ
ィアデータの利用拡大に伴い、データ転送の高速化が望
まれている。

【０００４】従来のデータ転送の典型的な方法の一つ
が、例えば S. J. Leffler他著 "TheDesign and Implem
entation of the 4.3BSD UNIX Operating System," Add
ison-Wesley, PP.169-185 （1989） に詳しく説明され
ている。ここでは、ユーザプロセスがＯＳに対して、リ
ードシステムコールを発行して、データを所望の入力元
リソースからユーザプロセス内のバッファに読み出すこ
とを要求し、この読み出しの完了後に、このバッファ内
のデータを所望の出力先リソースに転送することを要求
するの及びライトシステムコール発行する。以下、所望
のデータが全て転送されるまで、これらのシステムコー
ルの発行を繰り返す。

【０００５】例として、図２のように、ユーザプロセス
６０において、磁気ディスク装置１１上のファイル３０
７内のデータを、ネットワーク１２に出力する場合を考
える。なお、本明細書では、ユーザプロセスとは、ＯＳ
の管理の下に実行されるプログラムの制御の流れの単位
であり、文献によっては「プロセス」「タスク」「スレ
ッド」などとも呼ばれ、アプリケーションプログラムの
一部又は全部を構成するものである。また、この例で
は、ファイル３０７からデータを入力し、ネットワーク
１２に出力する場合について述べるが、他の入力先リソ
ースあるいは他の出力先リソースに関しても同様であ
る。なお、ユーザプロセスからＯＳへのサービスの要求
は、ユーザプロセスがシステムコールをＯＳに発行する
ことにより行われる。ＯＳでは、ディスパッチャがこの
システムコールを受け付け、どのようなサービスが要求
されているか否かを判定し、そのサービスを実行するた
めの、ＯＳ内の特定の処理部を呼び出す。しかし、後述
する実施例を含めて、以下の説明では、説明の簡単化の
ために、ディスパッチャには言及しないで、ＯＳがシス
テムコールに応答してその特定の処理部を呼び出すと記
述する。

【０００６】さて、ユーザプロセス６０は、入力元リソ
ースとしてファイル３０７指定するオープンシステムコ
ールなどのシステムコールをＯＳに対して発行し、ファ
イル３０７に対する識別子としてＯＳで予め定められた
記述子をＯＳから得る。出力先リソースとして使用する
ネットワーク１２に関しても同様である。これらの記述
子を得たユーザプロセス６０は、次にファイル３０７に
対応する記述子と、ユーザメモリ空間内に設けたデータ
転送用のバッファ５０のアドレスとその大きさを引数と
して指定して、データの読み出しを要求するリードシス
テムコール５１を発行する。

【０００７】ＯＳ３では、このシステムコール５１を受
けて、ファイルシステム８を呼び出す。すなわち、ＯＳ
３は、このシステムコールを発行したユーザプロセス１
の状態を格納している４内の記述子テーブル４５を、リ
ードシステムコール５１の際に引数として指定された記
述子により参照し、この記述子に対応するエントリ１４
から、カーネルファイルテーブル５内のエントリ１６の
アドレス２６を得る。カーネルファイルテーブル５は、
いろいろの入力処理部と出力処理部を起動するためのア
ドレスを保持するもので、今の例では、エントリ１６内
に、上記システムコールで指定された入力元リソースか
らデータ入力を行なう時に呼び出すべき入力処理部、今
の例ではファイルシステム８、のアドレス２８が納めら
れている。ＯＳ３はこのアドレス２８を用いてファイル
システム８に対して関数呼び出しを行なう。

【０００８】ファイルシステム８は、磁気ディスク装置
１１上の然るべき領域に対する読み込み命令３１３を発
行し、要求されたデータをファイルシステム内に読み出
し（３１１）、さらにバッファ５０に読み出されたデー
タを書き込む（５５）。

【０００９】これでファイルシステム８の動作が終了
し、ＯＳ３からユーザプロセス６０へ制御が戻る。ユ
ーザプロセス６０がバッファ５０に入力されたデータを
さらにネットワーク１２に出力しようとする場合、ユー
ザプロセス６０は、ネットワーク１２を指定する記述子
と、バッファ５０のアドレス及び大きさとを引数として
指定する、書き込み（ライト）システムコール５３を発
行する。ＯＳ３では、リードシステムコールの場合と同
様にして、プロトコル処理部９が、バッファ５０のデー
タを読み出し（５８）、然るべきプロトコル処理を施し
た後、ネットワーク１２へ出力する（３１４）。これで
バッファ５０の大きさに相当するデータの転送が終了し
たが、ファイル３０７にまだ読み込むべきデータが残っ
ている場合は、ユーザプロセスによりシステムコール５
１、５３の発行という手順が繰り返される。

【００１０】このような、データ転送の高速化を支援す
る様々な方法が提案されてきた。例えば、O. Krieger,
M. Stumm, and R. Unrau, "The Alloc Stream Facility
--A Redesign of Application-Level Stream I/O", IE
EE Computer, Vol.27, No.3, pp.75-82 （March 1994）
において説明されている、Alloc Stream Facility（Ａ
ＳＦ）では、図２のバッファ５０に相当する記憶領域を
カーネルメモリ空間に設けることにより、いずれかの入
力先リソースからこの記憶領域に読み出したデータをア
プリケーションプログラムがアクセス可能にし、もって
そのデータをアプリケーションプログラム内のバッファ
にコピーする操作を不要にしている。また、R. Govinda
n and D. P. Anderson, "Scheduling and IPC Mechanis
ms forContinuous Media", Proceedings of 13th ACM S
ymposium on Operating System Principles, pp.68-80
（1991）において説明されている、Memory-mapped Ster
ams （MMS）では、入力元リソースのデータを仮想記憶
空間上の領域にマップし、入力すべきデータをＯＳによ
り予め実記憶上に用意させ、これをアプリケーションプ
ログラムにより利用させることにより、アプリケーショ
ンプログラムによる、システムコールの発行回数を抑え
ている。

【００１１】

【発明が解決しようとする課題】図２を用いて説明した
従来のデータ転送方法は、次の問題を有する。

【００１２】まず、ユーザプロセスとＯＳとの間で頻繁
に制御の行き来が生ずるため、これに由来するオーバヘ
ッドが大きい。すなわち、あるユーザプロセスがあるデ
ータを読み出すためにリードシステムコールを発行した
後、そのデータの読み出しが完了すると、ＯＳは、完了
割り込みを発生し、その割り込みを処理するルーチンに
より、そのデータに対するリードシステムコールを発行
したユーザプロセスを見つけ、そのユーザプロセスにデ
ータの読み出しの完了を通知する。そのユーザプロセス
は、この完了通知を受けて、出力先リソースへの、その
データの書き込みを要求するライトシステムコールを発
行する。このように、データ転送のために繰り返しユー
ザプロセスとＯＳとの間で制御の行き来が生ずる。

【００１３】とくに、入力元リソースから出力先リソー
スへのデータの転送の場合、多量のデータの転送に対し
て、リードシステムコールとライトシステムコールの対
を複数回発行する必要があり、この制御の往来の回数が
増大する。ユーザプロセスとＯＳとの間で制御の行き来
が生ずると、その際にユーザモード（いわゆる非特権保
護モード）とカーネルモード（いわゆる特権保護モー
ド）との間の、計算機のモード切り替えが必要となり、
このモード切り替えの際に発生するコンテクストスイッ
チングのための処理などがオーバヘッドとなる。

【００１４】さらに、マルチタスキング環境では、複数
のユーザプロセスが要求する複数のデータ転送の実行
を、効率的にスケジュールすることが難しい。この環境
下では、各ユーザプロセスは、ＯＳによるスケジューリ
ングにより、プロセッサを割当てられた状態でしか処理
を進めることができない。すなわち、上記ユーザプロセ
スがデータ読み出しのために、リードシステムコールを
発行した後、上記データ読み出しの完了までの間に、そ
のユーザプロセスがプロセッサ待ちの状態になると、上
記読み出し完了の割り込みが発生しても、このユーザプ
ロセスは、そのユーザプロセスに実際にプロセッサが再
度割り当てるまで、そのデータに対してライトシステム
コールを発行することが出来ない。したがって、そのデ
ータの読み出しが終了しているにも拘らず、そのデータ
に対するライトシステムコールの発行が遅延する。この
ように、データ転送を要求するシステムコールの発行タ
イミングが、ユーザプロセスの状態に依存するため、こ
のデータの転送の実行をスケジュールすることは難し
い。さらに、この従来技術では、リソースを最大限有効
に利用するように、これらのデータ転送をスケジュール
することも難しい。すなわち、いずれかのユーザプロセ
スから現に発行されたシステムコールが要求する入力元
リソースあるいは出力先リソースが利用可能でないため
にそのシステムコールを実行できないが、他の空き状態
にある入力元リソースあるいは出力先リソースにを使用
するシステムコールがまだ他のユーザプロセスから発行
されていないという状態が起こり得る。各ユーザプロセ
スは、連続するデータを構成する複数のデータ部分を読
み出すために、複数のリードシステムコールと複数のラ
イトシステムコール交互に発行する。これらのシステム
コールの発行時刻は、各ユーザプロセスに依存するうえ
に、ＯＳはこれらのシステムコールが現に発行された時
点でしか、スケジュールすべきシステムコールを知り得
ない。したがって、ＯＳは、複数のユーザプロセスによ
り要求されるデータ転送を効率よく実行するようにスケ
ジュールできない。

【００１５】本発明の目的は、アプリケーションプログ
ラムから要求されたデータ転送を実行する間に生じる、
そのユーザプロセスとＯＳの間の制御の往来を減少する
データ転送方法を提供することである。

【００１６】本発明の他の目的は、複数のアプリケーシ
ョンプログラムが要求する複数のデータ転送の実行をＯ
Ｓによりスケジュールし易いデータ転送方法を提供する
ことである。

【００１７】

【問題点を解決するための手段】上記目的を達成するた
めに、本発明では、アプリケーションプログラムによ
り、入力元リソースと出力先リソースの対（チャネル）
と転送すべきデータの量を指定して、それらのリソース
の間のデータ転送をオペレーティングシステムに要求
し、この要求に応答して、ＯＳにより、この指定された
量のデータの転送を実行する。具体的には、ＯＳが使用
可能なバッファを確保し、入力元リソースからデータを
読み出し、このバッファに読み出されたデータを書き込
み、その後この書き込まれたデータをこのバッファーか
ら出力先リソースに転送する。以上の読み出しから転送
までの動作を、上記の指定された量のデータが転送され
るまで繰り返す。この結果、アプリケーションプログラ
ムは一度のデータ転送要求をＯＳに発行するだけで、後
はＯＳが実際にデータ転送を繰返し実行する。したがっ
て、本発明では、ユーザプロセスとＯＳとの間の制御の
往来が非常に少なくなる。その結果、この際に必要とな
るユーザモードとカーネルモードとの間の計算機モード
の切り替えに伴うオーバヘッドが減少する。

【００１８】さらに、本発明では、複数のアプリケーシ
ョンプログラムからのデータ転送要求の各々を上記の方
法で実行するとともに、それぞれのデータ転送要求のた
めのデータの読み出し及び書き込みの繰返しをＯＳによ
り制御する。この結果、複数のアプリケーションプログ
ラムプログラムが、複数の異なるチャネルにおけるデー
タ転送を要求しているような環境においても、これらの
データ転送の実行をＯＳによりスケジュールしやすくな
る。

【００１９】

【実施例】以下、本発明に係るデータ転送方法を図面に
示した実施例および変形例を参照してさらに詳細に説明
する。

【００２０】＜実施例１＞図１において、４０は、入力
元リソースとして使用され得る入力装置を表わし、例え
ば、磁気ディスク装置、他の計算機システム等に接続さ
れたネットワーク、キーボードなどを示す。５０は、出
力先リソースとして使用され得る出力装置を表わし、例
えば、上に述べた磁気ディスク装置と同じかもしくは異
なるディスク記憶装置、上のネットワークと同じネット
ワーク、あるいは他のキーボードなどを示す。

【００２１】ユーザプロセス１は、データ転送をＯＳ３
に要求するときに、従来と同様に、使用する入力元リソ
ースと出力先リソースの記述子をＯＳに決定して貰い、
データ転送の入力元リソースの記述子と出力先リソース
の記述子との対を指定するようになっている。以下で
は、データ転送すべき入力元リソースと出力先リソース
の組合せを「データ転送路」もしくは「チャネル」と呼
ぶ。２０は、ユーザプロセスが使用する新たなシステム
コールとして用意されたもので、入力元リソースに対応
する記述子と出力先リソースに対応する記述子との対を
引数として含み、この対により指定されたチャネルを登
録することをＯＳ３に要求するチャネルシステムコール
である。ＯＳ３では、チャネル登録処理部７が、このシ
ステムコールに応答して、このチャネルに関する情報を
保持するチャネル構造体を作成することにより、そのチ
ャネルを登録する。さらに、そのチャネルに対してチャ
ネル識別子を決定し、ユーザプロセス１にこのシステム
コールの戻り値としてこのチャネル識別子を返す。チャ
ネル構造体１３Ａ〜１３Ｎは、登録されたいろいろのチ
ャネルの現在の状態を保持するもので、それらは互いに
チェインされて、チャネルリスト６が形成される。この
チャネルシステムコールは、さらに、そのチャネルを介
したデータ転送に使用するバッファの大きさを指定する
ようになっており、チャネル登録処理部７は、この指定
された大きさに基づいて、バッファのサイズを決め、さ
おの決められたサイズのバッファとして、カーネルアド
レス空間（カーネル空間）内に位置し、このＯＳが走行
する計算機システムの主記憶（図示せず）内の領域が割
り当てられたバッファ１０を確保する。さらに、その決
められたバッファサイズをそのチャネル構造体内に書き
込む。

【００２２】２１は、ユーザプロセス用に設けられた他
のシステムコールで、これは、データ転送に使用するチ
ャネル識別子と転送データ量とを引数として含み、この
識別子で指定されるチャネルにおけるデータ転送をＯＳ
３に要求するトランスファシステムコールである。ＯＳ
３では、転送処理部２がこのトランスファシステムコー
ルを受け付け、チャネルリスト６内の、このシステムコ
ールを発行したユーザプロセスに対して設けられたチャ
ネル構造体を参照しながら、要求されたデータ転送を行
なう。すなわち、本実施例では、ユーザプロセスが入力
元リソースと出力先リソースの対を指定するチャネル
し、この入力先リソース内の、ユーザプロセスが指定し
たデータの全てを、この出力先リソースへ転送し終るま
で、データ転送を入力元リソースと出力先リソースの間
で繰返し実行するように、転送処理部２がデータ転送を
制御するところに特徴がある。この結果、ユーザプロセ
スは、一度データ転送を要求するシステムコールをＯＳ
を発行すればよい。したがって、従来のようにデータ転
送のためにユーザプロセスとＯＳとの間で頻繁に制御の
行き来が生じるようなことがないので、データ転送に付
随するオーバヘッドが小さくなる。

【００２３】より具体的には、ＯＳ（３）は、さらに、
従来技術と同様に、複数の入力元リソースからのデータ
の読み出しを行なうための複数の入力処理部８と、複数
の出力先リソースへのデータの書き込みを行なうための
複数の入力処理部９とを有し、転送処理部２は、そのシ
ステムコールが指定するチャネルに属する入力元リソー
スと出力先リソースを、そのシステムコールを発行した
ユーザプロセスに対応して設けられたチャネル構造体に
もとづいて判別し、その入力元リソースからの一定量の
データの読み出しを、その入力元リソースに体する入力
動作を行い得る、いずれか一つの入力処理部８に要求
し、この入力処理部８の制御により、そのデータがその
チャネル用に設けたバッファ１０に読み出されると、そ
のチャネルに属する出力先リソース用に設けられたいず
れかの出力処理部９に、その読み出されたデータをその
出力先リソースに書き込むことを要求する。この書き込
みが終了後、上記読みだされたデータの後続のデータに
関して、データの読み出しと書き込みを、上記トランス
ファコールで指定された転送データ量のデータが転送さ
れるまで繰り返す。

【００２４】本実施例では、複数のユーザプロセスが複
数のチャネルをＯＳに登録してデータ転送を行なわせる
ことができる構造となっている。しかし、図１では、簡
単化のために、チャネル構造体以外は、１つのユーザプ
ロセスが登録した、１つのチャネルに関連する部分のみ
を図示し、その他は省略している。

【００２５】転送制御部２は、以上のデータ転送を複数
のユーザプロセスから要求された複数のデータ転送の各
々に対して実行し、かつ、これらの複数のデータ転送を
並列に実行するように、これらのデータ転送のためのデ
ータの読み込みとデータの書き出しをスケジュールす
る。このために、本実施例では、転送制御部２は、チャ
ネルリスト６を繰返し走査して、それぞれのチャネル構
造体が指定する、入力元リソースからのデータ入力ある
いは出力先リソースからのデータ出力のいずれを実行す
べきかを判定し、その実行すべきデータ入力あるいはデ
ータ出力を実行する、然るべき入力処理部８または出力
処理部９に、入力要求あるいは出力要求を発行する。こ
の入力要求あるいは出力要求に基づいて、データの読み
込みがそのチャネルに体して実行されているのと並行し
て、転送制御部２は、チャネルリスト２の後続のチャネ
ル構造体に対して、上に述べたのと同じ処理を実行す
る。

【００２６】具体的には、転送制御部２は、いずれかの
走査されたチャネル構造体が指定するチャネルに関し
て、その入力元リソースからそのチャネル用のバッファ
へのデータの読み出しがなされていないときには、デー
タの読み出しを要求し、その入力元リソースからそのバ
ッファへのデータの読み出しが終了している場合には、
そのデータの、そのバッファから出力先リソースへの書
き出しを要求する。さらに、このデータの書き出しが終
了している場合には、再度、入力元リソースからそのバ
ッファへの後続のデータの読み出しを要求する。こよう
な制御のために、各チャネル構造体には、データの読み
込みが終了したか否かの情報と、データの書き出しが終
了したか否かの情報と、ユーザプロセスに要求された転
送データ量、すでに読み込まれたデータの総量、すでに
書き出されたデータの総量などを保持するようになって
いて、そのチャネル構造体が代表するチャネルに関し
て、データの読み込みあるいはデータの書き出しが終了
した時点で、これらの情報を更新するようになってい
る。

【００２７】本実施例では、チャネルリストを走査する
契機は、いずれかのユーザプロセスから新にトランスフ
ァコールが発行されたことがチャネル登録部７から通知
された場合、あるいは、いずれかのチャネルに関して、
データの読み込みが終了したことがいずれかの入力処理
部８から通知された場合、あるいは、データの書き出し
が終了したことがいずれかの出力処理部９から通知され
た場合である。

【００２８】したがって、本実施例では、複数のデータ
転送の間に頻繁に発生する呼び出しは、転送処理部２か
ら入力処理部８の呼び出し３１、出力処理部９の呼び出
し３４、及びそれらの逆である入力処理部８から転送処
理部２の呼び出し３２および出力処理部９から転送処理
部２の呼び出し３３であるが、これらはすべて、システ
ムコールのような割込み（トラップ）ではなく、サブル
ーチン呼び出しで呼び出しであることに注意すべきであ
る。これにより、これらのデータ転送を小さいオーバヘ
ッドで行なうことができる。

【００２９】以上のごとく、本実施例では、複数のチャ
ネルにおけるデータ転送をＯＳ内で制御することができ
る。この結果、たとえ、データ転送を要求したユーザプ
ロセスが、その後、プロセッサ待ちの状態になっても、
ＯＳは、そのユーザプロセスがすでに要求したデータ転
送を継続することが出来る。また、複数のチャネルにお
いてデータ転送が行なわれている場合でも、１つ１つの
チャネルにおけるデータの流れを容易に制御できる。

【００３０】なお、本実施例でも、図２に示した従来技
術と同様に、複数の入力処理部８と複数の出力処理部の
アドレスを保持するカーネルファイルテーブル５と、各
プロセスに関する情報を保持するプロセス構造体４とが
設けられている。この４には、従来と同様に、記述子テ
ーブル４５が設けられている。この記述子テーブル４５
には、このプロセスが使用するチャネルに対する入力動
作を実行する一つの入力処理部８のアドレスを保持す
る、カーネルファイルテーブル内のエントリ１６のアド
レス１４と、そのチャネルに対する出力動作を実行する
一つの出力処理部９のアドレスを保持する、カーネルフ
ァイルテーブル内のエントリ１７のアドレス１１５、お
よび、その記述子に対して次に入出力動作を行おうとす
る時に、入出力を行う位置を示すファイルポインタとを
保持する。以下、本実施例の動作を詳細に説明する。

【００３１】（記述子テーブルとカーネルファイルテー
ブル）ユーザプロセス１は、データ転送をＯＳに要求す
る前に、以下のような処理を従来技術と同様に実行す
る。

【００３２】ＯＳは予めカーネルファイルテーブル５を
従来技術と同様に、予め作成する。このテーブル５は、
各入力処理部８と各出力処理部９を起動するのに使用す
る、それぞれの処理部のアドレスを保持している。ま
た、各ユーザプロセスは、自分の現在の状態を保持する
プロセス構造体をＯＳ内に持っている。

【００３３】ユーザプロセス１が使用する入力元リソー
スまたは出力先リソースの記述子の決定は以下のように
従来と同様にして行われる。

【００３４】走行中のユーザプロセスの各々には、予
め、例えば、そのユーザプロセスの起動時にＯＳ３によ
り４が割り当てられる。いずれかのユーザプロセスが、
いずれかのディスク記憶装置に保持されたファイル内の
データを利用するとき、そのユーザプロセスは、そのフ
ァイルの名称と、ファイル内のデータの内、使用すべき
データの先頭アドレスを指定するオープンシステムコー
ルというシステムコールをＯＳに発行する。ＯＳはこの
システムコールに応答して、このファイルに対する記述
子を決定して、ユーザプロセスに通知するとともに、こ
の記述子に対応して記述子テーブル４５の１つのエント
リ１４を割当てる。このエントリ１４は、このファイル
を保持するディスク装置をアクセスするために用意され
た、例えば、ファイルシステムと呼ばれる、一つの入出
力処理部８のアドレスを保持する、カーネルファイルテ
ーブル５内のエントリ１６のアドレスを保持する。さら
に、エントリ１６は、オープンシステムコールで指定さ
れた、このファイルの名称を保持している。およびファ
イル内の読み出すべきデータの先頭アドレスは、記述子
テーブル４５内のエントリ１４に、既に述べたファイル
ポインタとして格納される。このファイルポインタは、
そのファイルのどの位置から入力すべきかを示す情報と
して、入力処理部８（この例ではファイルシステム）に
より参照される。次に同様にして、上記ユーザプロセス
は、例えば上のファイルのデータを他のファイルに転送
したい場合、そのファイルに関しても同様なオープンシ
ステムコールをＯＳに発行する。このシステムコールも
同様に処理され、記述子テーブル４５には、同様に、こ
の他のファイルに関する、テーブル５のエントリ１７の
アドレス１５が格納される。

【００３５】（チャネル構造体）チャネル構造体１３
は、入力元リソースから出力先リソースへの１つのデー
タ転送の、現時点における状態が格納されるデータ構造
である。図３に示すように、チャネル構造体１３は以下
の情報を格納する記憶領域を含んでいる。

【００３６】フラグ１４１は、そのチャネルの状態を数
値化し、要約して示すものである。数値化されるべき状
態の主なものは、次の通りである。すなわち、ユーザの
要求したデータ転送が終了したことを示すフラグCHDON
E、チャネルにおいてデータ転送を行なっている際にエ
ラーが発生したことを示すフラグCHERROR、チャネルシ
ステムコール２０によって登録された後、トランスファ
システムコール２１によって転送開始を要求されるのを
待っている状態であることを示すフラグCHWAIT、入力元
リソースからこれ以上データを読み込めないことを示す
フラグCHEOFなどである。ここでフラグCHDONE、CHERRO
R、CHWAIT、CHEOFなどは、同時にセットされても識別で
きるような、互いに異なるフラグである。

【００３７】リストポインタ１４２は、別のチャネル構
造体へのポインタを格納する。このリストポインタ１４
２を用いてすべてのチャネルを結合し、チャネルリスト
６を構成する。リストポインタ１４２の値を一定の値
（例えば０）にすることにより、このチャネル構造体が
リストの最後であることを示すことができる。

【００３８】プロセスポインタ１４３は、このチャネル
を登録したユーザプロセスの、プロセス構造体４へのポ
インタを格納する。

【００３９】入力記述子１４４は、バッファ１０へデー
タの入力を行なう時の入力元リソースを指定する記述子
を格納する。この入力記述子１４４と、プロセスポイン
タ１４３により、このチャネルにおいてデータの入力を
行なう際に、呼び出すべき入力処理部８を見出すことが
できる。

【００４０】出力記述子１４５は、バッファ１０に置か
れたデータを出力する時の出力先リソースを指定する記
述子を格納する。転送処理部２は、出力記述子１４６
と、プロセスポインタ１４３により、このチャネルにお
ける出力処理部９を見出すことが出来る。

【００４１】チャネル識別子１４６は、ユーザプロセス
がトランスファシステムコール２１によりデータ転送を
要求する際に、データ転送を実行すべきチャネルを指定
するのに用いられる。

【００４２】バイトカウンタ１４７は、データ転送を行
なうべきバイト数を格納する。この値が負の数である場
合、入力元リソースから入力できるデータがなくなるま
でデータ転送を行なうことを示す。

【００４３】バッファ管理構造体１５０は、チャネル構
造体１３に含まれるデータ構造で、そのチャネルにおけ
るデータ転送のために割り当てられたバッファ１０を管
理するためのものである。本実施例では、バッファ１０
はＯＳ３のカーネル空間内に静的に割り当てられた連続
した記憶領域とするが、バッファ１０は、入力元リソー
スから入力したデータを出力先リソースに出力するまで
の間一時的に格納しておくことができれば十分なので、
メモリ空間を利用してバッファ１０を実現する方法とし
ては、記憶領域を動的に割り当てるやり方など、本実施
例とは異なるバッファ管理の方法を用いることもでき
る。本実施例では、バッファ管理構造体１５０は、以下
のような情報を含む。

【００４４】バッファポインタ１５１は、このチャネル
におけるデータ転送のために割り当てられた記憶領域で
あるバッファ１０へのポインタを格納する。データポイ
ンタ１５２には、バッファ１０上の次に出力すべきデー
タのアドレスを格納する。入力データカウンタ１５３
は、これまでに入力したデータのバイト数を保持する。
さらに、出力データカウンタ１５４は、これまでに出力
したデータのバイト数を保持する。

【００４５】（チャネルシステムコール）本実施例にお
いては、ユーザプロセスがデータ転送をＯＳに要求する
ときに、チャネルシステムコールにより、入力元リソー
スと出力先リソースとの対を指定してチャネルを登録す
る必要がある。チャネルシステムコールは、次のような
形式である。

【００４６】チャネル（入力記述子，出力記述子，バッ
ファサイズ） ここで、入力記述子は入力元リソースに対応する記述
子、出力記述子は出力先リソースに対応する記述子であ
る。これらの記述子は、ユーザプロセス１が利用予定の
入力元リソースと出力先リソースをＯＳに指定し、それ
らのリソースに対する記述子をＯＳから予め得ておく。
これらの記述子をＯＳから得るには、従来技術で記載し
たような公知の方法を使用すればよい。バッファサイズ
は、このチャネルにおけるデータ転送のために確保すべ
きバッファ１０の大きさである。

【００４７】（チャネル登録処理部７）ＯＳ３では、こ
のチャネルシステムコールを受けて、チャネル登録処理
部７を呼び出す。チャネル登録処理部７は、図５に示す
ように、新しいチャネル構造体１３をカーネル空間内に
確保する（ステップ１２１）。具体的な領域確保の方法
は様々であり、ＯＳがサポートしているメモリ割り当て
ルーチンを用いてもいいし、あらかじめ大きな領域を確
保しておき、そこをチャネル構造体のプールとして用い
ても良い。次にこのチャネル構造体を、発行されたチャ
ネル・システム・コールの引数をもとに初期化する（ス
テップ１２２）。初期化としてはプロセス・ポインタ１
４３、入力記述子１４５及び出力記述子１４６の設定な
どを含むが、特に、チャネル構造体のフラグ１４１の部
分には、フラグCHWAITをセットし、このチャネルはトラ
ンスファ・システム・コールによるデータ転送の開始を
待っていることを明示する。次に、このチャネル構造体
をチャネルリスト６に追加する（ステップ１２３）。リ
スト６のどこにこのチャネル構造体を追加するかは様々
である。次に、データ転送用のバッファ１０のための領
域をカーネル空間内に確保し、そのアドレスをチャネル
構造体のバッファ・ポインタ１４４に格納する（ステッ
プ１２４）。より具体的な領域確保の方法はチャネル構
造体を割り当る時と同様に様々である。ＯＳは、このバ
ッファのサイズを、チャネルシステムコマンドで指定さ
れたサイズを参考にして決める。バッファサイズが指定
されない場合、指定されたバッファサイズが不適切な場
合、あるいは性能上より好ましいバッファサイズがある
場合には、ＯＳは、チャネルシステムコマンドで指定さ
れたサイズとは異なるサイズのバッファをカーネル空間
内に確保することもありうる。最後に、このチャネルを
識別できる識別番号を１つ決定し、それをこのチャネル
の識別子としてチャネル構造体のチャネル識別子１４７
に格納する。その後、この値を戻り値としてユーザプロ
セスに通知する（ステップ１２５）。なお、チャネルシ
ステムコールの引数が不正であるなどの原因によりチャ
ネルの登録に失敗したときは、システムコールの戻り値
を−１としてその旨をユーザプロセスに通知する。

【００４８】このチャネル識別子は、その後ユーザプロ
セスがデータ転送をＯＳ３に要求する時に、転送を行な
うべきチャネルを指定するのに用いられる。１つのユー
ザプロセスは、複数のチャネルを登録できる。チャネル
識別子の役割は、トランスファシステムコールを受けた
転送処理部２がチャネル（より正確にはチャネル構造
体）を一意に識別できるようにするためのもので、この
条件を満たす限りどのようなチャネル識別子の選び方を
してもかまわない。考えられる方法の１つとして、チャ
ネル識別子を、記述子の１つとして扱うというやり方が
考えられる。この場合、チャネル識別子を決めるには、
従来のＯＳに備わったルーチンを呼び出して、使用され
ていない（入出力先リソースが対応付けられていない）
記述子を見出し、それをチャネル識別子とすれば良い。
こうすることにより、オペレーティングシステムに従来
から備わる、記述子を操作するシステムコールが、チャ
ネルに対しても有効となるという利点がある。例とし
て、従来技術で挙げた代表的なオペレーティングシステ
ムが備えるフォークシステムコールにより、新たにユー
ザプロセスを生成する場合を考える。フォークシステム
コールでは、新しいユーザプロセス（子プロセス）は、
元のユーザプロセス（親プロセス）の記述子をそのまま
受け継ぐことができるという機能を持つ。そのため、親
プロセスが登録したチャネルを、チャネルを引き継ぐ機
能をＯＳに新設することなく、新しいユーザプロセスに
受け継がせることが可能となる。

【００４９】（トランスファシステムコール）ユーザプ
ロセス１がＯＳ３にデータ転送を開始させるためには、
トランスファシステムコール２１を発行しなくてはなら
ない。このトランスファシステムコール２１は次のよう
な形式である。

【００５０】トランスファ（チャネル識別子，バイト
数） ここでチャネル識別子はユーザプロセス１が先にチャネ
ルシステムコール２０により登録したチャネルの識別子
である。また、バイト数は転送すべきバイト数を指定す
る。なお、本実施例では、データ転送するバイト数を、
トランスファシステムコールが発行されてから出力先リ
ソースに出力されたデータのバイト数とする。入力元リ
ソースから入力すべきデータがまだ存在する場合でも、
このバイト数だけのデータ転送が行なわれたらトランス
ファシステムコールは終了する。バイト数として０を指
定した場合は、入力すべきデータがなくなるまで（例え
ば入力元リソースがファイルの時はファイルの終わりま
で）データ転送が続けられる。後に説明するように、デ
ータ転送処理部２は、トランスファシステムコール２１
に応答して、データ転送を実行し、実際に転送したバイ
ト数を戻り値として返る。この戻り値が引数で指定した
バイト数と同じ場合は、ユーザプロセスの要求したデー
タ転送が成功裡に終了したことを意味する。また、戻り
値が引数よりも小さい場合は、データ転送において何か
しら障害があったことを意味し、また負の数である場合
は、引数が不正であるなど、データ転送の前にエラーが
あったことを示す。

【００５１】（データ転送処理部２）トランスファシス
テムコール２１を受けたＯＳ３は、転送処理部２を呼び
出す。この転送処理部２のより詳細な構造は、図４のよ
うになっている。

【００５２】転送開始／終了処理部７３は、トランスフ
ァシステムコール７３を受け、すでにチャネル登録処理
部７によって登録されているチャネルのいずれかにおけ
るデータ転送を準備し、スケジュール処理部７５を呼び
出し（８４）、そのチャネルでのデータ転送を開始させ
る。その後、待機処理部７４を呼び出し（８２）、ユー
ザプロセスが要求したデータ転送が終了するのを待た
せ、データ転送が終了した時点でユーザプロセスに制御
を戻す。

【００５３】待機処理部７４は、基本的にはデータ転送
が終了するまでトランスファシステムコールを発行した
ユーザプロセスを休眠状態にするためのルーチンである
（本実施例では行なわないが、ユーザからのオプション
設定により、休眠状態にしないようにすることもでき
る）。しかし、必要に応じて走行可能状態とされて、入
力処理部または出力処理部を行なう（８６または８７）
場合もある。

【００５４】スケジュール処理部７５は、新にトランス
ファシステムコールがユーザプロセスにより新にいずれ
かのチャネルに対するデータ転送が要求されたときに転
送開始／終了処理部７６により起動されるか、あるい
は、いずれかの入力処理部８あるいは出力処理部９によ
る入力処理あるいは出力処理が終了したときに、入力終
了処理部７８あるいは出力終了処理部７９により起動さ
れる。どれか１つのチャネルに関する事象の発生（具体
的には、データ転送要求の発生、データ入出力の終了）
により呼び出される。

【００５５】スケジュール処理部７５の基本的な動作
は、チャネルリスト６を走査し、そこに登録されたチャ
ネル構造体の各々を参照して、それぞれが対応するチャ
ネルの現時点での状態を調べ、それぞれチャネルに対し
データの入力とデータの出力の一方あるいは両方が可能
かどうかを判定し、データ入力が可能であれば入力要求
発行処理部７６を呼び出し（８８）、データ出力が可能
であれば出力要求発行処理部７７を呼び出す（９０）と
いうものである。

【００５６】入力要求発行処理部７６及び出力要求発行
処理部７７は、スケジュール処理部７５により指定され
た１つのチャネルに対して入力要求あるいは出力要求を
発行する。より具体的には、そのチャネルにおける入力
元リソースまたは出力先リソースへのアクセスを行なう
際に呼び出すべきいずれかの入力処理部８あるいはいず
れかの出力処理部９を決定し、この決定された入力処理
部８あるいは出力処理部９に対して入力要求あるいは出
力要求を出力する。これらのルーチンは入力要求または
出力要求を発行するだけで、データのバッファ１０への
入力あるいはバッファ１０からのデータの出力が終了す
るまで待たずにスケジュール処理部７５に制御を戻す。
この結果、すべてのチャネル構造体の操作を素早く行な
えるため、複数のチャネルを一括してスケジュールする
のが容易になる。

【００５７】なお、複数の入力処理部８あるいは複数の
出力処理部９の中には、入出力のために呼び出しを受け
た場合、データの入出力が終了するまで呼び出したルー
チンに制御を返さないという同期入出力しかサポートし
ていないものがある。

【００５８】本実施例では、こうした入出力処理部に対
して入出力要求を発行する場合は、待機処理部７４にて
休眠状態となっているユーザプロセスを走行可能状態と
し、そこから入力処理部８あるいは出力処理部９を呼び
出させることにより、入力要求発行処理部７６及び出力
要求発行処理部７７は要求を発行するだけで、データの
入出力を待たずにすぐに戻るというセマンティクスを実
現する。

【００５９】なお、入力処理部あるいは出力処理部の中
には、入出力のために呼び出しを行なった場合、データ
の入出力が終了するまで呼び出したルーチンに制御を返
さないという同期入出力しかサポートしていないものが
ある。そこで、本実施例では、こうした入出力処理部に
対して入出力要求を発行する場合は、待機処理部７４に
て休眠状態となっているユーザプロセスを走行可能状態
とし、そこから入力処理部あるいは出力処理部を呼び出
させることにより、入力要求発行処理部７６及び出力要
求発行処理部７７は要求を発行するだけで、データの入
出力を待たずにすぐに戻るというセマンティクスを実現
する。これらの点を含め、入力要求発行処理部７６及び
出力要求発行処理部７７のより詳細な実装については後
述する。なお、以下本明細書では、OSが備える各種の入
力処理部及び出力処理部を、入出力要求を発行した際に
データの入出力を待たず、すぐに呼び出したルーチンに
もどるというセマンティクスをサポートするものと、こ
のようなセマンティクスをサポートせず、入出力要求を
発行したら、データの入出力が終了するまで呼び出した
入出力処理部内で待つことを余儀なくされるものの２つ
に分類し、前者を非同期的、後者を同期的であると呼
ぶ。

【００６０】入力終了処理部７８及び出力終了処理部７
９は、あるチャネルに属する入力元リソースまたは出力
先リソースへのアクセスを行なうための入力処理部８ま
たは出力処理部９から、バッファ１０へのデータの入力
あるいはバッファ１０からのデータの出力が終了した際
に呼び出される（９８または９９）。これらのルーチン
は、入力元リソースあるいは出力先リソースによって異
なる入力処理部８または出力処理部９が、データの入出
力が終了した時に返してくる情報を検査し、対応するチ
ャネル構造体が保持している情報を更新し、その後スケ
ジュール処理部７５を呼び出す。これにより、あるチャ
ネルの状態が変化したとき、常にスケジュール処理部７
５が呼び出されることになる。

【００６１】待機処理部７４は、基本的にはデータ転送
が終了するまでトランスファシステムコールを発行した
ユーザプロセスを休眠状態にするためのルーチンであ
る。なお、ユーザからのオプション設定により、休眠状
態にしないようにすることもできる。しかし、必要に応
じて走行可能状態として、入力処理部８または出力処理
部９を動作させる（８６または８７）場合もある。

【００６２】以上から明らかなように、転送処理部２に
おいて、スケジュール処理部７５は、少なくとも１つの
チャネルにおいてその状態が変化したとき常に呼び出さ
れ、またあるチャネルにおいてデータの入出力を行おう
とする際にも、しかるべき入力処理部８又は出力処理部
９を呼び出して入出力要求を発行するだけで、その入出
力の実行を待たずに直ちに次のチャネルに対するデータ
転送要求の処理へ移行できる。従って、複数のチャネル
が登録されてデータ転送が行われている場合でも、実際
のデータの流れをスケジュール処理部７５において容易
に管理することができる。そのため、スケジュール処理
部７５には、必要に応じて、後述するようなアルゴリズ
ム以外にも、リアルタイムスケジューリングアルゴリズ
ムなどの様々なアルゴリズムを容易に実装することがで
き、それにより本実施例のデータ転送機能をさらに高機
能かつ高性能のものとすることができる。

【００６３】（転送開始／終了処理部７３）転送開始／
終了処理部７３の動作を図６に示す。この処理部７３
は、トランスファシステムコール２１を受けて呼び出さ
れ、まずシステムコールの引数として指定されたチャネ
ル識別子に対応するチャネル構造体を、チャネルリスト
６を走査して得る（ステップ２２１）。次に、発行され
たトランスファシステムコールの引数をチェックしなが
ら、それらをチャネル構造体に設定していく（ステップ
２２２）。特に、ここでチャネル構造体のフラグ１４１
においてフラグCHWAITをリセットし、データ転送中であ
ることを明示する。また、注意すべき点として、ここで
入力データカウンタ１５３及び出力データカウンタ１５
４の初期化は行なわない。これらが初期化されるのはチ
ャネル登録処理部７においてのみであり、これにより、
データ転送を（シグナルの配送などの原因で）一時中断
して再開する場合も、同じトランスファシステムコール
を発行することで行なうことができる。以上までで、不
当な引数が用いられているなど、何かエラーがあった場
合は（ステップ２２３）、それを通知する形で（すなわ
ちトランスファシステムコールの戻り値が−１を返すよ
うに）制御がユーザプロセスに戻される（ステップ２２
７）。エラーがなかった場合は、スケジュール処理部７
５が呼び出される（（ステップ２２４）。スケジュール
処理部７５はチャネルリスト６につながれたすべてのチ
ャネル構造体を走査するので、この時点でこのチャネル
に対するデータ転送が開始される。スケジュール処理部
７５から戻ったら、次に待機処理部７４を呼び出し、ト
ランスファシステムコールにより要求されたバイト数の
データ転送が終了するまで待機する（ステップ２２
５）。その後ユーザプロセスに、実際に転送されたデー
タのバイト数を戻り値として戻る（ステップ２２６）。

【００６４】（待機処理部７４）このルーチンの動作は
図７の通りである。このルーチンはある１つのチャネル
構造体とともに呼び出される。まずこのチャネル構造体
のフラグ１４１においてフラグCHERRORがセットされて
いるかが検査され、このチャネルに対してエラーが発生
しているかどうかが調べられる（ステップ２０１）。も
しセットされていれば、発生したエラーに関する情報が
ユーザプロセスに渡るようにして自分を呼んだルーチン
に戻る（ステップ２０２）。CHERRORがセットされてい
なければ、次にフラグCHDONEを検査し、データ転送が終
了しているかどうか調べる（ステップ２０３）。CHDONE
がセットされている時は、ユーザの要求したデータ転送
が完了した旨の通知と共に自分を呼び出したルーチンに
戻る（ステップ２０４）。もしCHDONEもCHERRORもセッ
トされていなければ、次に待機処理部はこのチャネルに
対して同期入力あるいは同期出力の要求が生じていない
かどうか調べる（ステップ２０５および２０７）。これ
らの検査はチャネル構造体のフラグ１４１において、そ
れぞれフラグCHSYNCRD、CHSYNCWRがセットされているか
どうかを調べることにより行なわれる。これらのフラグ
はチャネル構造体のフラグ１４１において既述のCHDONE
などのフラグとは独立にセットまたはリセットできる。
もしフラグCHSYNCRDがセットされている場合は、そのチ
ャネルに対する入力処理部８を呼び出して、バッファ１
０に入力元リソースからデータを入力する（ステップ２
０６）。そのチャネルに対する入力処理部８を決定する
のは、従来の方法であった図２の時と同様、４の記述子
テーブル１８、カーネルファイルテーブル５を参照する
ことにより行なわれる。記述子などの情報は、チャネル
構造体に格納されている。ステップ２０６の終了時点で
データの入力は（エラーであれなんであれ）終了してい
るので、次に入力終了処理部７８を呼び出す（ステップ
２０８）。その後、待機処理部７４の始めに戻る。CHSY
NCWRがセットされている場合も同様に、出力処理部９を
呼び出してデータの出力を行ない（ステップ２０９）、
続いて出力終了処理部を呼び出し（ステップ２１０）、
待機処理部７４の始めに戻る。CHSYNCRD、CHSYNCWRのい
ずれもセットされていない時は、ＯＳのプロセス管理機
構を呼び出して、自分自身を休眠状態にする（ステップ
２１１）。

【００６５】ステップ２１１にて休眠状態となったユー
ザプロセスは、必要に応じて実行可能状態とされる。実
行可能状態となったユーザプロセスは、その時点から処
理を再開し、ステップ２０１に戻る。ここで注意すべき
点は、このユーザプロセスは既にＯＳ内の待機処理部７
４にて休眠しており、処理再開後、必要に応じて例えば
入力処理部などを直接呼び出すという点である。この
間、ＯＳとユーザプロセスとの間の制御の往来、すなわ
ちカーネルモードとユーザモードとの間の計算機モード
の切り替えを要しないため、一々システムコールを発行
して入出力を行う場合と比較して、オーバヘッドが非常
に小さい。

【００６６】（スケジュール処理部７５）この動作を図
８および図９に示す。ここではチャネルリスト６上のす
べてのチャネル構造体が検査され、データ転送が終了し
たか、あるいは入出力を行なうことが可能か、などが１
つ１つのチャネルに対して調べられる。スケジュール処
理部７５においては、まず一連の操作において入力要求
または出力要求が発行されたチャネルがあるかどうかを
示す変数（Ｉとする）に０を代入して初期化する（ステ
ップ１０１）。次に、チャネルリスト６の先頭にあるチ
ャネル構造体を取り出す（ステップ１０２）。そして、
このチャネル構造体を参照して入出力が可能かどうかの
検査を行なっていくが、ここでまず始めに、このチャネ
ルにおけるデータ転送を要求したユーザプロセスに対し
てシグナル（ユーザプロセスレベルでのソフトウェア割
込み）が配送されていないかどうか調べる（ステップ１
０３）。この検査はチャネル構造体のプロセスポインタ
１４３により４を参照することにより行なわれる。もし
シグナルが配送されているときは、このチャネルにおけ
るデータ転送を中断するが、その際エラーが発生したの
と同じ扱いとする。すなわち、このチャネルに対応する
チャネル構造体のフラグ１４１にフラグCHERRORをセッ
トし、待機処理部７４中で休眠状態となっているユーザ
プロセスを走行可能状態とする（ステップ１１２）。も
しシグナルが配送されていなければ、次にこのチャネル
おいてデータを入力することが可能であるかどうかを、
チャネル構造体のデータポインタ１４８、入力データカ
ウンタ１４９、出力データカウンタ１５０、バッファサ
イズ１５５などをもとに判定する。入力可能かどうかの
判定は、バッファにまだ空きがあり、判定の結果、もし
そのチャネルに対してデータの入力が可能であれば（ス
テップ１０５）、入力要求発行処理部７６が呼び出され
て、そのチャネルの入力元リソースへのアクセスを行な
う入力処理部８に対して入力要求が発行され（ステップ
１０６）、変数Ｉの内容に１が加算される（ステップ１
０７）。ステップ１０６においてエラーが生じた場合
は、既に述べたステップ１１２が実行され、フラグCHER
RORがセットされ、そのチャネルを要求しているユーザ
プロセスを走行可能状態にする。エラーでなければ、次
に、このチャネルにおいて出力先リソースにデータを出
力することが可能かどうかを判定し（ステップ１０
８）、可能であれば出力要求発行処理部７７を呼び出し
（ステップ１０９）、さらに変数Ｉの内容に１が加算さ
れる（ステップ１１０）。入力の場合と同様、エラーが
発生した場合はステップ１１２が実行される（ステップ
１１１）。以上で１つのチャネルに対する処理を終え、
チャネル構造体のリストポインタ１４２をみてチャネル
リスト上の次のチャネル構造体を取り出す（ステップ１
１３）。もし次のチャネル構造体があれば（ステップ１
１４）、ステップ１０３に戻る。もしもうチャネル構造
体がない場合は、次に変数Ｉが検査される（ステップ１
１５）。もし変数Ｉが０でなければ、ステップ１０１に
戻ってチャネルリスト６の走査が繰り返される。ここで
走査の繰り返しが行なわれるのは、あるチャネルの入出
力が、別のチャネルに対して入出力要求が発行されたこ
とによって可能となる可能性があるからである。一方、
もし変数Ｉが０、すなわちチャネルリスト６の一連の操
作において入力要求あるいは出力要求が発行されたチャ
ネルが１つもなければ、スケジュール処理部７５を終え
て、自分を呼び出したルーチンに戻る（ステップ１１
６）。

【００６７】（入力要求発行処理部７６）この動作は図
１０の通りである。この処理はある１つのチャネルを引
数としてスケジュール処理部７５から呼び出される。ま
ず、チャネル構造体の入力記述子１４５とプロセスポイ
ンタ１４３から、このチャネルに対応するユーザプロセ
スの記述子テーブル１８とＯＳ３のカーネルファイルテ
ーブル５が参照され、そのチャネルに対応する入力処理
部８が決定される（ステップ１６１）。次に、その入力
処理部が同期的であれば（ステップ１６２）、チャネル
構造体のフラグ１４１にフラグCHSYNCRDをセットして、
待機処理部７４にて休眠中であったユーザプロセスを走
行可能状態とする（ステップ１６４）。非同期的であれ
ば、データの入力が終了した時に入力終了処理部７８を
呼び出すように設定した後、入力処理部８を呼び出して
データ入力要求を発行する（ステップ１６３）。その
後、発行した入力要求に対して既にデータ入力がなされ
た（例えば入力処理部がファイルシステムで、必要とす
るデータが既にバッファキャッシュに読み込まれていた
場合などが考えられる）かどうかが調べられ（ステップ
１６５）、もし読み込まれていれば入力終了処理部７９
を呼び出してチャネル構造体の内容を更新する（ステッ
プ１６６）。ここで、入力終了処理部７９を呼び出すと
きに、入力要求発行処理部７６からの呼び出しであるこ
とが入力終了処理部７９において認識できるようにす
る。入力終了処理部７９は、入力要求発行処理部７６か
らの呼び出しである場合は、スケジュール処理部７５を
呼び出さずに終わる。これにより、スケジュール処理部
７５が自分を再帰的に呼び出す結果となってしまうのを
防ぐ。その後ステップ１６３または１６４においてエラ
ーが発生したかどうかを調べ（ステップ１６７）、エラ
ーの有無を通知する形で自分を呼び出したスケジュール
処理部７５に制御を返す（ステップ１６８、１６９）。

【００６８】（出力要求発行処理部７７）このルーチン
の動作は、出力記述子１４６が参照され、この記述子が
指定する出力先リソースに対応する出力処理部９に出力
要求が発行されること以外は、既に述べた入力要求発行
処理部７６と同じ動作である。

【００６９】（入力終了処理部７８）この動作を図１１
に示す。この処理部は、あるチャネルにおいてデータの
入力が終了した時に呼び出される。まず、どのチャネル
に対する入力が終了したのかが決定され、そのチャネル
に対応するチャネル構造体が取り出される（ステップ２
０１）。次に、そのチャネルの入力元リソースに対して
行なわれたデータ入力がエラーであったかどうかが検査
され（ステップ２０２）、もしエラーであればチャネル
構造体のフラグ１４１にフラグCHERRORをセットする
（ステップ２０３）。その後、実際に読み込まれたデー
タのバイト数に応じて、チャネル構造体内のバッファ管
理構造体１５０を更新する（ステップ２０４）。次に、
そのチャネルの入力元リソースから入力すべきデータが
これ以上ないか、あるいはユーザが（トランスファシス
テムコールの引数として）要求したバイト数だけ入力し
終えたかどうかが調べられ（ステップ２０５）、もしな
ければチャネル構造体のフラグ１４１にフラグCHEOFを
セットする（ステップ２０６）。この後、もし入力終了
処理部が入力要求発行処理部７６からの呼び出しでなけ
れば（ステップ２０７）、スケジュール処理部７５を呼
び出す（ステップ２０８）。それから自分を呼び出した
ルーチンに戻る（ステップ２０９）。

【００７０】（出力終了処理部７９）この動作を図１２
に示す。この処理部は、あるチャネルにおいてデータの
出力が終了した時に呼び出される。入力終了処理部７８
の場合と同様、まずどのチャネルに対する入力が終了し
たのかが決定され、そのチャネルに対応するチャネル構
造体が取り出される（ステップ２３１）。次に、そのチ
ャネルの出力先リソースに対して行なわれたデータ出力
がエラーであったかどうかが検査され（ステップ２３
２）、もしエラーであればチャネル構造体のフラグ１４
１にフラグCHERRORをセットする（ステップ２３３）。
次に、実際に出力先リソースに出力されたデータのバイ
ト数に応じて、チャネル構造体内のバイトカウンタ１４
７及びバッファ管理構造体１５０を更新する（ステップ
２３４）。ここで、もしチャネル構造体のフラグ１４１
にフラグCHEOFがセットされており、かつバッファにデ
ータがない場合（ステップ２３５）あるいはバイトカウ
ンタ１４７が０になってユーザの要求したバイト数だけ
データを転送し終えた場合は（ステップ２３６）、チャ
ネル構造体のフラグ１４１にフラグCHDONEをセットする
（ステップ２３７）。その後、もし自分が出力要求発行
処理部７７から呼び出されたものでなければ（ステップ
２３８）、スケジュール処理部７５を呼び出す（ステッ
プ２３９）。その後自分を呼び出したルーチンに戻る
（ステップ２４０）。

【００７１】なお、本実施例によれば、データ転送の高
速化に付随して、次のような利点もある。のＯＳに適合
するアプリケーションプログラムを新規に開発する場合
には、本実施例で用いた新規なシステムコールを用いる
必要がある。しかし、これらのシステムコールは、「デ
ータの経路を登録し、そこにデータを流す」という形式
の、データの移動経路を明確に記述するので、アプリケ
ーションプログラム内でのデータの移動経路の使用状況
が明確になる。このため、そのようなアプリケーション
プログラムの開発を容易にする。

【００７２】＜変形例＞実施例１を以下のように変形す
ることも出来る。

【００７３】（１）実施例１では、あるチャネルにおけ
るデータ転送を実行する際に呼び出される入力処理部８
や出力処理部９は、ユーザプロセスがそのチャネルを登
録する時に何を入出力先リソースとして指定したかによ
って異なるが、これらのルーチンは従来のものを変更な
く使うことができる。しかし、カーネル空間内のバッフ
ァ１０にデータを入力し、それをまた出力するという処
理を、すべてＯＳ３内で行なうという構造になっている
ことを活用して、既存の入力処理部や出力処理部を、デ
ータ転送の際に最適な処理が行なわれるように拡張する
ことも可能で、これによりさらにデータ転送の性能を改
善することができる。また、データ転送専用の入力処理
部又は出力処理部を本実施例のＯＳに新規に追加しても
よく、そうすればデータ転送をより高機能のものにでき
る。

【００７４】（２）ユーザが独自の入力処理部あるいは
出力処理部をプログラムしてＯＳに登録できるようにす
れば、実施例１のＯＳを適用して処理の性能を高めるこ
とのできる範囲が、データ転送だけでなく、ユーザが指
定した入力元リソースから、ユーザが指定した出力先リ
ソースへの、ユーザが定義したデータ処理を間に置いた
データ転送にまで、すなわち、ほとんどのアプリケーシ
ョンプログラムにまで、拡大できる。

【００７５】（３）実施例１では単一のプロセッサの下
で動作するＯＳに実装することを想定して説明した。し
かし、実施例１は同様の特徴を持つＯＳに容易に適用可
能であり、また疎結合あるいは密結合マルチプロセッサ
システムの下で動作するＯＳに対しても、異なるプロセ
ッサ間の協調のための機能がＯＳにサポートされていれ
ば、少々の拡張により実施例１を適用することができ
る。

【００７６】＜実施例２＞実施例１では、そこ用いたチ
ャネルシステムコールの形式から分かるように、記述子
を割り当てられるリソース（例えばファイル）のみを、
データ転送の入力元リソース又は出力先リソースとして
指定できる。本実施例では、記述子を割り当てることが
できるリソースの種類を増やすことにより、実施例１の
データ転送機能の適用範囲を拡大する。例えば、ＯＳ３
にユーザプロセスのユーザアドレス空間（ユーザ空間）
のある領域に記述子を割り当てる機能がある場合を考え
る。この場合、従来のリードシステムコールまたはライ
トシステムコールによって行なっていた入出力は、チャ
ネルシステムコールとトランスファシステムコールの組
み合わせですべて置き換えることができる（すなわちす
べての入出力をデータ転送としてとらえることができ
る）。ユーザ空間の一部に記述子を割り当てることがで
きると、頻繁に入力や出力の行なわれるメモリ空間に記
述子をあらかじめ割り当ててチャネルを登録しておくこ
とにより、アドレスに依存しない入出力が可能となる。
また、仮想記憶をサポートしているＯＳでは、ユーザ空
間との入出力を行なう場合、一般にユーザアドレス空間
内の目的とする領域を物理メモリに固定する処理をその
たびに必要とするが、この処理はオーバヘッドが大き
い。そこで、頻繁に入出力を行なうメモリ領域に記述子
を割り当てておき、その際にその領域を物理メモリに固
定したままにしておくことにより、毎回の入出力（デー
タ転送）においてはこのオーバヘッドを回避することが
できる。

【００７７】＜実施例３＞実施例１では、あるチャネル
が登録された時点で、データ転送すべき入力元リソース
と出力先リソースの両方がＯＳに分かっている。そこ
で、本実施例では実施例１の転送処理部２（とりわけ入
力要求発行処理部７６）の拡張により、そのチャネルに
おけるデータ転送を最適化する。例えば、あるチャネル
における入力元リソースと出力先リソースが同じファイ
ルシステムによって管理された２つのファイルである場
合、このチャネルのバッファとしてファイルシステムの
バッファキャッシュを用いるようにすれば、このチャネ
ルに対してはデータ転送用のバッファ１０をカーネル空
間内に別に割り当てる手間を省くことができ、かつ、本
来必要ないメモリ間コピーの回数を減らして、データ転
送をより高速に行なえる。また、ディスプレイのフレー
ムバッファのように、一定のアドレス空間内の領域への
アクセスがハードウェア的に機器へのアクセスへ変換さ
れるような入出力先リソースが、あるチャネルにおける
入力あるいは出力先リソースである場合、そのアドレス
の領域をそのチャネルのバッファとすることにより、メ
モリ間コピーの回数だけでなく処理量をも削減すること
が可能である。さらに、本変形例を実装したＯＳが動作
する計算機にしかるべき手段が備えられている場合は、
入力元リソースと出力先リソースの組み合わせによって
は、入力元リソースから一度主記憶中にデータを読み込
まずに、出力先リソースにハードウェア的に直接出力す
ることができ、それによってより高速なデータ転送を行
なえる。

【００７８】実施例１の入力要求発行処理部７６におい
て、ステップ１６１ではそのチャネルに対応する入力処
理部のアドレスを得る。これを拡張して、このステップ
にて出力処理部のアドレスも得るようにし、２つのアド
レスの組を見て上記のような転送の最適化ができるかど
うか調べるようにする。これは、例えばそうした最適化
が可能なアドレスの組（同じファイルシステムの入力と
出力のためのアドレスなどの組）をテーブルにして、Ｏ
Ｓ内の適当な領域に格納しておき、これを参照すること
によって行うことができる。調べた結果最適化が可能な
らば、ステップ１６２以降で呼び出す入力処理部を、別
の、最適化された転送のための処理部への呼び出しに変
更する。この処理部は前記の最適化が可能なアドレスの
組ごとに個別に存在し、それぞれの入力元リソースと出
力先リソースの組に応じた最適なデータ転送を実行す
る。

【００７９】＜実施例４＞実施例１では、チャネルシス
テムコールがユーザプロセスに返すチャネル識別子を、
記述子の１つとして扱うことができるため、チャネルシ
ステムコールの引数として、別のチャネルのチャネル識
別子を指定できる。そこで、本実施例では、然るべき処
理の実装により、データ転送路の分岐や合流などといっ
た、より複雑な転送経路の設定をユーザプロセスが行え
るようにする。例えば、データ転送路の合流を実現する
場合、次のように実施例１を拡張すればよい。実施例１
の出力要求発行処理部７７では、ある１つのチャネル
（ｃとする）のチャネル構造体１３の出力記述子１４３
を検査する。このステップを拡張して、検査の結果、出
力記述子が別のチャネル（ｄとする）のチャネル識別子
であった場合に、そのチャネルｄのチャネル構造体に格
納された出力記述子に対応する出力先リソースに出力す
るようにする。これにより、チャネルｄの出力先リソー
スには、チャネルｃの入力元リソースからのデータとチ
ャネルｄの入力元リソースからのデータが交互に出力さ
れ、結果として２つの入力元リソースからのデータを合
流させ、１つの出力先リソースに出力することが可能に
なる。また、このやり方だと、さらに別のチャネルの出
力先リソースとしてチャネルｃ又はチャネルｄを指定す
ることにより、３つ以上のチャネルの合流、すなわち３
つ以上の入力元リソースからのデータを合流させること
もできる。データの分岐も、実施例１の入力要求発行処
理部７６をこれと同様に拡張することにより容易に実現
することが出来る。

【００８０】＜実施例５＞実施例１においては、トラン
スファシステムコールの引数を、チャネルを指定するチ
ャネル識別子と、転送すべきバイト数の２つとしたが、
本実施例では、この他にデータ転送の様式を指定するよ
うなオプションを付け加える（あるいは、別のシステム
コールでオプションの指定を行なっても良い）。こうし
たオプションとしては、例えばデータ転送をできる限り
高速に行なわせるのではなく、それよりも遅いある一定
の転送速度を指定して、その速度でデータ転送を行なわ
せる（いわゆるアイソクロナス（isochronous）データ
転送）、など様々なものが考えられる。このような時間
を意識した機能を実現するためには、ＯＳ３内の各処理
部が利用可能な計時機能を計算機システム３００内に設
け、実施例１の転送処理部２、とりわけスケジュール処
理部７５に、然るべきアルゴリズムを実装すればよい。
このような計時機能は、現在ほとんどの計算機システム
に備わっている。また、スケジュール処理部７５に実装
すべきアルゴリズムとしては、リアルタイムスケジュー
リングアルゴリズム、またはマルチメディアスケジュー
リングアルゴリズムとして、従来の技術の項で挙げたGo
vindan他の文献など、過去に多数発表されている。これ
らのアルゴリズムは、わずかな変更を加えるだけでスケ
ジュール処理部７５に実装することができる。

【００８１】

【発明の効果】本発明では、アプリケーションプログラ
ムがＯＳにデータ転送を要求するためにＯＳに対して発
行されるシステムコールの回数が削減され、それにより
このデータ転送に伴うオーバヘッドが低減する。

【００８２】さらに、こうしたデータ転送が同時に複数
実行されているような場合、本発明ではこれらのデータ
転送のスケジュールをＯＳにより容易に行い得る。

【図面の簡単な説明】

【図１】本発明によるデータ転送方法を実現するオペレ
ーティングシステムの概略構造を示す図である。

【図２】従来のオペレーティングシステムにおけるデー
タ転送方法を示す図である。

【図３】本発明の一実施例におけるチャネル構造体のデ
ータ構造を表す図である。

【図４】上記実施例における転送処理部のプログラム構
造を示す図である。

【図５】上記実施例におけるチャネル登録処理部の手順
を示す流れ図である。

【図６】上記実施例における転送開始／終了処理部の手
順を示す流れ図である。

【図７】上記実施例における待機処理部の手順を示す流
れ図である。

【図８】上記実施例におけるスケジュール処理部の手順
の一部を示す流れ図である。

【図９】上記スケジュール処理部の手順の残部を示す流
れ図である。

【図１０】上記実施例における入力要求発行処理部の手
順を示す流れ図である。

【図１１】上記実施例における入力終了処理部の手順を
示す流れ図である。

【図１２】上記実施例における出力終了処理部の手順を
示す流れ図である。

【図１３】従来技術によるデータ転送方法を示す図であ
る。

【符号の説明】

２０：チャネルシステムコール、２１：トランスファシ
ステムコール

Claims (11)

【特許請求の範囲】
1. 【請求項１】処理装置と、主記憶と、複数の入出力装置
   とを有し、複数のアプリケーションプログラムがオペレ
   ーティングシステム（ＯＳ）の制御の下で実行されてい
   る計算機システムにおける、オペレーティングシステム
   によるデータ転送方法であって、 転送すべきデータを保持する入力元リソースと、そのデ
   ータを受け取るべき出力先リソースとの対と、該入力元
   リソースと該出力先リソースとの間で転送すべきデータ
   の量とを指定する、該複数のアプリケーションプログラ
   ムの一つから発行されたデータ転送要求に応答して、該
   入力元リソースに保持されたデータの内、所定量の大き
   さのデータ部分を該入力元リソースから該主記憶に読み
   込み、 該読み込みの完了後、該読み込まれたデータを該主記憶
   から該出力先リソースに書き出し、 該書き出しの完了後、該読み込みと該書き出しを、該デ
   ータ転送要求で指定された量のデータが該入力元リソー
   スから該出力先リソースに転送されるまで、該入力元リ
   ソースに保持された他のデータ部分に対して繰り返し、 該繰返しの終了後に、該アプリケーションプログラム
   に、該データ転送要求で要求されたデータ転送の終了を
   通知するステップを有するもの。
2. 【請求項２】該入力元リソースと該出力先リソースの対
   に対応して、該要求されたデータ転送を制御する情報ブ
   ロックを記憶し、 上記入力元リソースからのデータ部分の読み込みあるい
   は該出力先リソースへの書き出しの実行を該情報ブロッ
   クに基づいて制御し、 上記入力元リソースからのデータ部分の読み込みあるい
   は該出力先リソースへの書き出しを実行する毎に該情報
   ブロックを書き換えるステップをさらに有する請求項１
   記載のオペレーティングシステムによるデータ転送方
   法。
3. 【請求項３】該情報ブロックは、少なくとも、上記デー
   タ転送要求で指定された転送データ量、該入力元リソー
   スから読み込み済みのデータの総量、該出力先リソース
   へ書き出し済みのデータの総量を含み、 上記方法は、 該入力元リソースからの読み込みステップを実行する毎
   に、該読み込み済みのデータの総量を更新し、 該出力先リソースへのデータの書き出しを実行する毎
   に、該書き出し済みのデータの総量を更新するステップ
   をさらに有し、 該繰返すステップは、該更新された、読み込み済みのデ
   ータの総量が該要求されたデータ転送量に等しくなるま
   で、該入力元リソースからのデータの読み込みを繰返
   し、該更新された、書き出し済みのデータの総量が該要
   求されたデータ転送量に等しくなるまで、該出力先リソ
   ースへのデータの書き出しを繰返すステップを有する請
   求項１記載のオペレーティングシステムによるデータ転
   送方法。
4. 【請求項４】該読み込みステップは、 該データ転送要求に応答して、該入力元のリソースがデ
   ータ読み出し可能な状態にあるか否かを判別し、 該入力元のリソースがデータ読み出し可能な状態にある
   ときには、上記ＯＳ内に準備された複数の入力処理ルー
   チンの内、該入力元リソースに対してデータの読み出し
   動作を実行可能な一つの入力処理ルーチンに対して、該
   入力元リソースから該主記憶へのデータの読み込みを要
   求し、 該一つの入力処理ルーチンの制御下で該入力元リソース
   に対して該要求された読み込みを該実行するステップを
   有し、 該書き出しステップは、 該出力元リソースがデータを書き込み可能な状態にある
   か否かを判別し、 該出力元のリソースがデータ書き込み可能な状態にある
   ときには、上記ＯＳ内に準備された複数の出力処理ルー
   チンの内、上記出力元リソースに対してデータの書き込
   み動作を実行可能な一つの出力処理ルーチンに対して、
   該読み込みステップで読み込まれたデータの該主記憶か
   ら該出力先リソースへの書き出しを要求し、 該一つの出力処理ルーチンの制御下で、該出力先リソー
   スに対して該要求された書き出しを実行するステップを
   有する請求項１記載のオペレーティングシステムによる
   データ転送方法。
5. 【請求項５】該データ転送要求を該一つのアプリケーシ
   ョンプログラムから該ＯＳに発行する前に、その一つの
   アプリケーションプログラムから発行された、該入力元
   リソースと該出力先リソースとの対の登録要求に応答し
   て、上記ＯＳ内に準備された複数の入力処理ルーチンの
   内、該入力元リソースに対してデータの読み込み動作を
   実行可能な一つの入力処理ルーチンと、上記ＯＳに含ま
   れた複数の出力処理ルーチンの内、上記出力元リソース
   に対してデータの書き込み動作を実行可能な一つの出力
   処理ルーチンとを選択し、 選択された一つの入力処理ルーチンを起動するための第
   １の情報と該入力元リソースを指定する第２の情報と、
   選択された一つの出力処理ルーチンを起動するための第
   ３の情報と、該出力先リソースを指定する第４の情報を
   該主記憶に記憶するステップをさらに有し、 該読み出し要求の発行は、該記憶された第１、第２のの
   情報に基づいて、該一つの入力処理ルーチンに、該入力
   元リソースからのデータの読み出し込みを要求するステ
   ップを有し、 該書き出しは、該記憶された第３、第４の情報に基づい
   て、該一つの出力処理ルーチンに、該出力元リソースへ
   のデータの書き出しを要求するステップを有する請求項
   １記載のオペレーティングシステムによるデータ転送方
   法。
6. 【請求項６】処理装置と、主記憶と、複数の入出力装置
   とを有し、複数のアプリケーションプログラムがオペレ
   ーティングシステム（ＯＳ）の制御の下で実行されてい
   る計算機システムにおける、オペレーティングシステム
   によるデータ転送方法であって、 （ａ）複数のアプリケーションプログラムが要求した複
   数のデータ転送を制御する情報ブロックであって、それ
   ぞれ、いずれか一つのアプリケーションプログラムを指
   定する情報と、転送されるべきデータを保持する、該一
   つのアプリケーションプログラムにより指定された入力
   元リソースを指定する情報と、そのデータを受けとるべ
   き、該一つのアプリケーションプログラムにより指定さ
   れた出力先リソースを指定する情報と、その入力元リソ
   ースとその出力先リソースとの対に関する、該一つのア
   プリケーションにより指定された転送データ量とを含む
   ものを記憶し、 （ｂ）該複数の情報ブロックの所定の順に順次選択し、 （ｃ）該ステップ（ｂ）により現在選択された情報ブロ
   ックに基づいてデータの読み込みを要求し、その要求で
   はその情報ブロックに含まれた、入力元リソースを指定
   する情報が指定する入力元リソースから主記憶へのデー
   タの読み出しを要求し、 （ｄ）該要求されたデータの読み出しが終了した後、そ
   の読み出しが完了したデータを、該主記憶から、その情
   報ブロックに含まれた、出力先リソースを指定する情報
   により指定される出力先リソースに書き出すことを要求
   し、 （ｅ）該要求されたデータの書き出しが終了した後、該
   読み出しが完了したデータの後続のデータの読み出しを
   要求し、その後続のデータの読み出しが完了する毎に、
   その読み出された後続のデータの書き込みを要求するよ
   うに、該読み出しの要求ステップ（ｃ）と該書き込みの
   要求ステップ（ｄ）とを、該一つの情報ブロックに含ま
   れた転送データ量のデータが該入力元リソースから該出
   力先リソースに転送されるまで繰返すステップを有し、 ここでステップ（ｂ）は、そのステップ（ｂ）によりす
   でに選択された一つ又は複数の情報ブロックの各々に基
   づいて、上記ステップ（ｃ）から（ｅ）が実行するのと
   並行して、該複数の情報ブロックの内、未選択の複数の
   情報ブロックを順次選択するように実行されるもの。
7. 【請求項７】該ステップ（ａ）で選択されたいずれか一
   つの情報ブロックに基づいて、該ステップ（ｂ）を実行
   する前に、該選択された情報ブロックが指定する入力元
   リソースがデータの読み込みが可能な状態にあるか否か
   を判別し、 その入力元リソースがデータを読み込み可能であるとき
   に上記ステップ（ｂ）をその情報ブロックに基づいて実
   行し、 その入力元リソースがデータを読み込み可能でないとき
   に上記ステップ（ｂ）をその情報ブロックに対して実行
   するのを延期し、 該一つの情報ブロックに基づいて、該ステップ（ｂ）を
   実行した後、該ステップ（ｃ）を実行する前に、該選択
   された情報ブロックが指定する出力先リソースがデータ
   の書き出しが可能な状態にあるか否かを判別し、 その出力先リソースがデータの書き出しが可能であると
   きに上記ステップ（ｃ）をその情報ブロックに基づいて
   実行し、 その出力先リソースがデータを書き出し読み込み可能で
   ないときに上記ステップ（ｃ）をその情報ブロックに対
   して実行するのを延期するステップをさらに有する請求
   項６記載のオペレーティングシステムによるデータ転送
   方法。
8. 【請求項８】各情報ブロックは、それが指定する入力元
   リソースからデータを主記憶に読み込みが完了したか否
   かを示す読み込み完了情報と、該入力元リソースから読
   み出されたデータをその情報ブロックが指定する出力先
   リソースに書き出し済みか否かを示す書き出し完了情報
   をさらに有し、 該方法は、 （ｆ）各情報ブロックに基づく、該ステップ（ｃ）また
   はステップ（ｅ）によるステップ（ｃ）の繰返しにおけ
   る、データの読み込みが完了する毎に、その情報ブロッ
   ク内の、入力元リソースからの読み込みが完了したか否
   かを示す上記情報をセットし、 （ｇ）その情報ブロックに基づく、該ステップ（ｄ）ま
   たはステップ（ｅ）によるそのステップ（ｄ）の繰返し
   におけるデータの書き出しが完了する毎に、その情報ブ
   ロック内の、出力先リソースへの書き出しが完了したか
   否かを示す上記情報をセットし、 （ｈ）該複数の情報ブロックが繰返し選択されるよう
   に、上記ステップ（ａ）を繰返し、 （ｉ）各情報ブロックが該ステップ（ｂ）または（ｈ）
   により選択される毎に、その情報ブロック内の、上記読
   み込み完了情報および上記書き出し完了情報に基づい
   て、上記ステップ（ｃ）または（ｄ）を行うべきかを判
   別するステップをさらに有する請求項６記載のオペレー
   ティングシステムによるデータ転送方法。
9. 【請求項９】該ステップ（ｈ）は、いずれかの情報ブロ
   ックに基づいて実行された該ステップ（ｃ）により要求
   された読み出しの完了ごとにおよび該いずれの情報ブロ
   ックに基づいて実行された該ステップ（ｄ）により要求
   された書き出しの完了ごとに、起動される請求項８記載
   のオペレーティングシステムによるデータ転送方法。
10. 【請求項１０】該ステップ（ａ）は、 （ａ１）いずれかのアプリケーションプログラムから発
    行された、一つの入力元リソースと出力先リソースの対
    の登録要求に応答して、その対を表わす情報を含む一つ
    のの情報ブロックを記憶し、 （ａ２）該一つのアプリケーションプログラムからその
    後発行された、上記対と転送データ量とを指定するデー
    タ転送要求に応答して、その対に対してステップ（ａ
    １）で記憶された上記一つの情報ブロック内に、その指
    定された転送データ量を記憶するステップを有する請求
    項８記載のオペレーティングシステムによるデータ転送
    方法。
11. 【請求項１１】各情報ブロックは、データ転送を要求し
    たいずれかのアプリケーションプログラムが指定した該
    入力元リソースから読み込み済みのデータの総量と、該
    アプリケーションプログラムが指定した該出力先リソー
    スへ書き出し済みのデータの総量を含み、 上記方法は、 該入力元リソースからの読み込みステップ（ｃ）を実行
    する毎に、該読み込み済みのデータの総量を更新し、 該出力先リソースへのデータの書き出しステップ（ｄ）
    を実行する毎に、該書き出し済みのデータの総量を更新
    するステップをさらに有し、 該繰返すステップ（ｅ）は、該更新された、読み込み済
    みのデータの総量が該要求されたデータ転送量に等しく
    なるまで、該入力元リソースからのデータの読み込みス
    テップ（ｃ）を繰返し、該更新された、書き出し済みの
    データの総量が該要求されたデータ転送量に等しくなる
    まで、該出力先リソースへのデータの書き出しステップ
    （ｄ）を繰返すステップからなる請求項６記載のオペレ
    ーティングシステムによるデータ転送方法。