JP5516398B2 - マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法 - Google Patents

Description

本発明は、複数のＯＳが動作するマルチプロセッサシステムに関し、特に、デバイスを複数ＯＳ間で共有して利用するマルチプロセッサシステム、ＯＳ間デバイス共有方法に関する。

マルチコアプロセッサの利用形態として、同種ないし異種のＯＳを複数稼動させることは、システム全体の信頼性、応答性を改善する手段として有用である。

他方、マルチコアプロセッサ上の複数ＯＳ間で、ＤＭＡコントローラ、グラフィックアクセラレータ、マルチメディア専用エンジン、ＨＤＤ（ハードディスク）コントローラ等の周辺デバイス（以下単に、デバイスと称する）を共有して利用することは容易ではない。その理由は、通常、デバイス管理はＯＳの役割としてそのＯＳ内で閉じており、あるＯＳの管理下にあるデバイスに対し、他のＯＳからアクセスされることは想定されていないためである。

複数ＯＳ間でデバイスを共有して利用する手法としては、非特許文献１及び非特許文献２に記載されるようなクライアント-サーバ方式がある。このクライアント−サーバ方式は、デバイスにアクセスするＯＳを１つに限定したうえで、そのＯＳ上でアクセスサーバと呼ばれるサーバタスクを稼動させ、それ以外のＯＳ上のタスクは、ＯＳ間通信によってアクセスサーバと通信し、アクセスサーバにデバイスのアクセスを代行させる方式である。このアクセスサーバは、デバイスアクセスを代行する役割を果たすことから、プロキシと呼ばれることもある。
日経エレクトロニクス, 2005年3月28日号, pp134-135 酒井 淳嗣 他, 情報処理 47巻1号, 情報処理学会, 2006年1月, pp 29-33

しかし、非特許文献１及び非特許文献２に記載のクライアント-サーバ方式には、次のような問題がある。

第１の問題は、サーバへのデバイスアクセス要求のたびにプロキシつまりアクセスサーバへのタスク切り替えが必要なため、サーバを介したデバイスアクセスの性能が低下することである。これは特に、グラフィックアクセラレータやＨＤＤのように高速性が重視されるデバイスにおいて重大な問題となる。

第２の問題は、デバイスアクセスの種類ごとにプロキシとなる機能をアクセスサーバに実装する必要があり、その開発コストが大きいことである。

例えば、グラフィックアクセラレータやＨＤＤのような多機能デバイスに対しては、アプリケーション開発者向けに数十から数百のＡＰＩ（アプリケーションプログラムインタフェース）が用意されることも稀ではなく、これらに対するプロキシ及びそれを経由するようなスタブルーチンの開発には看過できないコストを必要とする。

［発明の目的］
本発明の目的は、デバイスアクセス性能低下を抑えたＯＳ間デバイス共有を可能とするマルチプロセッサシステム、マルチプロセッサシステムのＯＳ間デバイス共有方法を提供することにある。

本発明の他の目的は、ＯＳ間デバイス共有に要する開発コストを低く抑えることのできるマルチプロセッサシステム、マルチプロセッサシステムのＯＳ間デバイス共有方法を提供することにある。

本発明によるマルチプロセッサシステムは、複数のＯＳが動作するマルチプロセッサシステムにおいて、複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有し、デバイスドライバが、ＯＳカーネル層でのＯＳ間通信を行う、デバイスインタフェース部と、タスクインタフェース部の少なくとも一方を有し、デバイスインタフェース部が、デバイスドライバの操作対象のデバイスとのアクセスを行い、タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行う。

本発明によるデバイスドライバは、複数のＯＳが動作するマルチプロセッサシステムのＯＳ間で共有するデバイスにアクセスするＯＳが備えるデバイスドライバであって、デバイスドライバの操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、デバイスインタフェース部とＯＳカーネル層でのＯＳ間通信を行い、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行うタスクインタフェース部の少なくとも一方を含む。

本発明によるＯＳ間デバイス共有方法は、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有する複数のＯＳが動作するマルチプロセッサシステムのＯＳ間デバイス共有方法であって、デバイスドライバが、デバイスインタフェース部と、タスクインタフェース部の少なくとも一方を有し、タスクインタフェース部とデバイスインタフェース部とがＯＳカーネル層でのＯＳ間通信を行い、デバイスインタフェース部が、デバイスドライバの操作対象のデバイスとのアクセスを行い、タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行う。

本発明の第１の効果は、クライアント-サーバ方式によるクライアント側タスクからのデバイスアクセス性能を向上させることである。

本発明の第２の効果は、デバイス共有のためのソフトウェア開発コストを抑えることができることである。

本発明の第１の実施の形態によるシステム全体構成を示すブロック図である。 本発明の第１の実施の形態におけるＯＳ−Ａ及びＯＳ−Ｂ上のデバイスドライバの内部構成を示す図である。 本発明の第１の実施の形態における処理要求構造体の内部構成を示す図である。 本発明の第１の実施の形態におけるＯＳ−Ａ及びＯＳ−Ｂ上のデバイスドライバ間通信部の内部構成を示すブロック図である。 本発明の第１の実施の形態における呼出要求構造体の内部構成を示す図である。 本発明の第１の実施の形態における呼出要求リストの内部構成を示す図である。 本発明の第１の実施の形態におけるＯＳ−Ａ用デバイスドライバの初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ｂ用デバイスドライバの初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａ用デバイスドライバの要求解釈部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａ用デバイスドライバの待機タスク再開部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ｂ用デバイスドライバの要求解釈部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ｂ用デバイスドライバの待機タスク再開部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａ用デバイスドライバのデバイス設定部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａ用デバイスドライバのデバイス割り込み処理部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａでのデバイスドライバ間通信部の初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるデバイスドライバ間通信部が通信相手ＯＳを呼び出す動作を説明するフローチャートである。 本発明の第１の実施の形態におけるデバイスドライバ間通信部にて、相手ＯＳから呼び出された際の被呼出処理の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ−Ａ上のユーザタスクがデバイスアクセスを行う際の処理フロー全体を示す図である。 本発明の第１の実施の形態におけるＯＳ−Ｂ上のユーザタスクがデバイスアクセスを行う際の処理フロー全体を示す図である。 本発明の第２の実施の形態におけるデバイスドライバ及びその内部の判定部の位置づけを示す図である。 本発明の第３の実施の形態におけるデバイスドライバ及びその内部の要求待ちリストの構成を示す図である。 本発明の第４の実施の形態によるＯＳ−Ａ及びＯＳ−Ｂ上のデバイスドライバの内部構成を示す図である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態）
［構成の説明］
図１を参照すると、本発明の第１の実施の形態による複数のＯＳを搭載する共有メモリ型のマルチプロセッサシステムは、マルチコアプロセッサ１０と、２種類のＯＳである、ＯＳ−Ａ４０とＯＳ−Ｂ５０、各ＯＳ上のユーザタスク４３、５３、マルチコアプロセッサ１０の外部バス３０に接続されたメモリ３１を含む構成である。

マルチコアプロセッサ１０は、２つのＣＰＵコアすなわちＣＰＵコア（０）２０とＣＰＵコア（１）２１、割り込み制御部１２、割り込みのうち特にＣＰＵコア間の割り込みを発生させるコア間割り込み発生部１３、ＯＳ間で共有する内部デバイス１４を備えて構成され、これらがプロセッサ内部バス１１で接続されている。

ＣＰＵコア上のソフトウェアに目を向けると、ＣＰＵコア（０）２０上ではＯＳ−Ａ４０が稼動している。このＯＳ−Ａ４０には、内部デバイス１４をアクセスするためのデバイスドライバ４１が組み込まれ、そのＯＳ上には、内部デバイス１４をアクセスするユーザタスク（Ａ０）４３が存在する。

また、ＯＳ−Ａ４０は、隣接する他のＯＳと通信するためのデバイスドライバ間通信部（Ａ）４２を有している。

同様に、ＣＰＵコア（１）２１上ではＯＳ−Ｂ５０が稼動している。このＯＳ−Ｂ５０には、内部デバイス１４をアクセスするためのデバイスドライバ５１が組み込まれ、そのＯＳ上には、内部デバイス１４をアクセスするユーザタスク（Ｂ０）５３が存在する。

ＯＳ−Ｂ５０は、隣接する他ＯＳと通信するためのデバイスドライバ間通信部（Ｂ）５２を有している。

ここでは説明のために、マルチコアプロセッサ１０としてＣＰＵコアを２つ含み、その上で２種類のＯＳが動作している構成を図示しているが、本発明は２コア構成のマルチコアプロセッサに限定されず、複数のＣＰＵコアを含む構成であれば適用することが可能であり、また３種類以上のＯＳが動作する構成にも適用可能である。

また、図１では、マルチコアプロセッサ１０の内部バス１１上と、外部バス３０上に、各々内部デバイス１４及び外部デバイス３２が接続されているが、そのデバイスの数や接続先の内部／外部の区別は、本発明を適用を妨げるものではない。更には、割り込み制御部１２やコア間割り込み発生部１３がマルチコアプロセッサ１０の外部バス３０に接続されていても、本発明をそのまま適用できる。

以降もっとも典型的な例として、２コア構成のマルチコアプロセッサで、その内部バス上に接続された内部デバイス１４を２つのＯＳ間で共有する場合を取り上げて具体的に説明する。

次に、本発明の主要な構成要素であるデバイスドライバの構造について説明する。

図２を参照すると、ＯＳ−Ａ４０に組み込まれるＯＳ−Ａ用デバイスドライバ４１は、ユーザタスク（Ａ）４３からの要求を受け付け、処理結果をユーザタスク（Ａ）４３に返却するための、タスクインタフェース部（Ａ）４４と、内部デバイス１４の動作を制御しあるいはその状態を観察し、デバイスからの結果を受け取るデバイスインタフェース部（Ａ）４５と、タスクインタフェース部（Ａ）４４がユーザタスクから受け付けたものの、まだ対象デバイスである内部デバイスが処理を開始していない処理要求を格納しておく領域である要求待ちリスト４６と、対象デバイスが現在実行中の処理情報を格納しておく領域である処理中リスト４７とを備える。

タスクインタフェース部（Ａ）４４は、その内部に、ユーザタスク（Ａ）４３からの処理要求を受け付ける要求解釈部（Ａ）４４１と、ユーザタスクの動作を制御しユーザタスク（Ａ）４３に処理結果を返すための待機タスク再開部（Ａ）４４２とを備える。

デバイスインタフェース部（Ａ）４５は、その内部に、内部デバイス１４のレジスタ等に値を設定し、また他のＯＳ上のデバイスドライバからの通信割り込みを取り扱うデバイス設定部４５１と、内部デバイス１４からの割り込みを取り扱うデバイス割り込み処理部４５２とを備える。

ＯＳ−Ａ４０は、その内部に、ＯＳ−Ａ用デバイスドライバ４１のほか、他のＯＳ上のデバイスドライバとの間で通信を行うデバイスドライバ間通信部（Ａ）４２を備える。また、ＯＳ−Ａ４０上では、内部デバイス１４へのアクセス要求を発行するユーザタスク（Ａ０）４３が動作している。

内部デバイス１４は、与えられた処理が完了した等の状態変化をＯＳ側に伝えるため、ＣＰＵコアに対して割り込みを発生させる割り込み制御部１２に接続されている。

ＯＳ−Ｂ５０は、デバイスインタフェース部（Ａ）４５及びそれに付随するデータ構造（要求待ちリスト４６、処理中リスト４７）を有していない点を除けば、ＯＳ−Ａ４０内部の構造と類似している。以下、同じく図２を参照してＯＳ−Ｂ内部の構成を説明する。

ＯＳ−Ｂ５０に組み込まれたＯＳ−Ｂ用デバイスドライバ５１は、ユーザタスク（Ｂ）５３からの要求を受け付け、処理結果をユーザタスク（Ｂ）５３に返却するための、タスクインタフェース部（Ｂ）５４を備える。また、ＯＳ−Ｂ５０は、ＯＳ−Ｂ用デバイスドライバ５１とＯＳ−Ａ用デバイスドライバ４１との間の通信を行うためのデバイスドライバ間通信部（Ｂ）５２を備える。

タスクインタフェース部（Ｂ）５４は、その内部に、ユーザタスク（Ｂ）５３からの処理要求を受け付ける要求解釈部（Ｂ）５４１と、ユーザタスクの動作を制御し、ユーザタスクに処理結果を返すための待機タスク再開部（Ｂ）５４２とを備える。

上記で述べた構造すなわち、デバイスドライバをタスクインタフェース部とデバイスインタフェース部で構成し、デバイスを直接アクセスするＯＳ（ＯＳ−Ａ４０）にはその両者を搭載し、それ以外のＯＳ（ＯＳ−Ｂ５０）にはタスクインタフェース部のみのデバイスドライバを搭載し、デバイスを直接アクセスしないＯＳのタスクインタフェース部とデバイスを直接アクセスするＯＳのデバイスインタフェース部とをデバイスドライバ間通信で接続する方式が、本発明の中枢をなす特徴的な構成である。

要求待ちリスト４６と、処理中リスト４７は、図３に示す処理要求構造体７０をデータ要素とし、これらがリストでつながったものとして構成される。処理要求構造体７０のインスタンスは、各ＯＳ上のデバイスドライバのタスクインタフェース部の要求解釈部にて作成され、要求待ちリスト４６につなげられる。

対象の内部デバイスでの処理が開始されるときに、当該処理要求構造体７０のインスタンスは、要求待ちリスト４６から取り除かれ、処理中リスト４７に移される。

最後に、各ＯＳ上のデバイスドライバのタスクインタフェース部の待機タスク再開部が、処理中リスト４７中の処理要求構造体のインスタンスを取り除き、呼び出し元のユーザタスクに処理結果を返す。

最も基本的な構成では、デバイスに対する処理がユーザタスクからの要求順に実行されるように設計する。その場合、要求待ちリスト４６と処理中リスト４７は先入れ先出しすなわちＦＩＦＯとして実装することが考えられる。

再び図３を参照すると、処理要求構造体７０は内部に次のようなフィールドを有する。

処理要求識別子７１は、処理要求構造体７０のインスタンスを一意に区別するための識別子である。要求元ＯＳ識別子７２は、この処理を要求したユーザタスクが実行されていたＯＳを特定するための識別子であり、図２の例で言えば、ＯＳ−Ａ４０あるいはＯＳ−Ｂ５０を指す識別子となる。要求元タスク識別子７３は、この処理を要求したユーザタスクを、当該ユーザタスクを稼動させていたＯＳ内において、一意に特定するための識別子であり、例えば各ＯＳが管理するタスクＩＤそのものが用いられる。

デバイス設定情報７４は、ユーザタスクからの要求に沿ってデバイスドライバが対象の内部デバイスに対して設定すべき値に関する情報を保持する。このデバイス設定情報７４は、例えば、デバイスドライバがＤＭＡコントローラであれば、転送元アドレスと転送先アドレスと転送サイズであり、デバイスドライバがグラフィックアクセラレータであれば、３Ｄ描画コマンド列である。

従って、このデバイス設定情報７４が保持する内容はデバイスによって大きく異なるが、ある特定のデバイスに対する処理要求識別子７１では、そのデバイス設定情報７４は常に同一サイズとする。これにより処理要求構造体７０のインスタンスのメモリ管理が容易になる。デバイス設定情報７４の領域は、デバイス設定情報として現実的に想定される最大サイズのデータが保持できるサイズとし、もし必要であれば、処理要求内容を複数の処理要求識別子に分割して表現する。この分割はタスクインタフェース部４４、５４が行う。

デバイス状態７５は、ユーザ要求を内部デバイスが処理した結果を格納するためのフィールドである。このデバイス状態７５に格納される内容は、例えば、ＤＭＡコントローラやグラフィックアクセラレータの場合には、要求処理が成功したか否かを示す単純な整数値であるが、ＨＤＤコントローラの場合、ＨＤＤから読み出したデータ列のように、大きなサイズのデータである場合もある。

デバイス状態７５には、後続のデバイス処理によって上書きされ、あるいは後続のデバイス処理の開始が妨げられる等の理由により、デバイスからの完了割り込みがＯＳ側に伝達された後、速やかにデバイス内から取り出さなければならないデータのみを保持するように設計する。また、このデバイス状態７５のサイズは、ある特定のデバイスに対しては常に同一サイズとなるように設計する。これはデバイス設定情報７４の場合と同じく、メモリ管理を容易にするためである。

次に、本実施の形態におけるデバイスアクセス性能改善に重要な役割を果たす、デバイスドライバ間通信部の構成について、図４を参照して説明する。なお、デバイスドライバ間通信部は各ＯＳに１つずつ存在するが、いずれも同じ構成である。以下では、ＯＳ−Ａ４０側のデバイスドライバ間通信部（Ａ）４２について説明するが、ＯＳ−Ｂ５０側のデバイスドライバ間通信部（Ｂ）５２も同様の構成である。

本実施の形態におけるデバイスドライバ間通信は、事前にあるＯＳ側にて登録しておいたルーチンを他のＯＳ側から呼び出す、という点において、リモートプロシージャコール（ＲＰＣ）と類似の概念で通信を行う。しかし、本実施の形態におけるデバイスドラバ間通信は、ほとんどの部分が割り込みハンドラ内で実行されることが特徴であり、これにより通信オーバヘッドを低減する効果をもたらす。

ＯＳ−Ａ４０側のデバイスドライバ間通信部（Ａ）４２は、事前のルーチン登録に関連して、ＯＳ−Ａ４０側の登録済みルーチンを保持する被呼出ルーチン登録表（Ａ）４２２と、その表に対して事前にルーチンを登録するための被呼出ルーチン登録部（Ａ）４２１を備える。

デバイスドライバ間通信部（Ａ）４２はまた、他ＯＳ側から呼び出された状況の管理に関連して、ＯＳ−Ａ側の登録済みルーチンに対する未実行の呼出要求をリストで管理する呼出要求リスト（Ａ）４２３と、デバイスドライバ間通信部（Ａ）４２が現在、登録済みルーチンのいずれかを呼び出しているか否かを示す被呼出状態記憶部（Ａ）４２４を備える。

デバイスドライバ間通信部（Ａ）４２は、また、相手を呼び出すあるいは相手から呼び出される、という動作に関連して、次の２つの処理部を備える。

すなわち、ＯＳ−Ａ用デバイスドライバ４１からの要求に応じ、コア間割り込みを発生させて他のＯＳ上のデバイスドライバ間通信部を呼び出す処理を行う呼出処理部（Ａ）４２６と、コア間割り込みを経て他のＯＳから要求されたことを受け、登録済みルーチン呼出し処理を行う、被呼出処理部（Ａ）４２５である。

被呼出処理部（Ａ）４２５は、通信高速化のため、割り込みハンドラ内の処理として、ＯＳ−Ａ４０の割り込み受け付け部４８から直接呼び出されることが望ましい。

しかし、割り込み禁止時間をできるだけ減らし、割り込みハンドラをできるだけ軽量にするためには、被呼出処理部（Ａ）４２５の処理の多くをカーネルタスクすなわちＯＳカーネル内で動作するタスクないしスレッドとして実装し、ＯＳ−Ａ４０の割り込み受付部４８は前記カーネルタスクの起動だけを行う構成も可能である。

呼出要求リスト（Ａ）４２３には、図５に示される呼出要求構造体８０のインスタンスが格納される。この呼出要求構造体８０は、要求元ＯＳ識別子８１と、呼出ルーチン識別子８２と、呼出パラメータ８３の３つのフィールドを備える。

要求元ＯＳ識別子８１は、この処理を要求したデバイスドライバが実行されていたＯＳを特定するための識別子であり、図２の例で言えば、ＯＳ−Ｂ５０を指す識別子となる。本実施の形態ではＯＳ−Ａ４０以外のＯＳはＯＳ−Ｂ５０ただ一つであるため、要求元ＯＳ識別子８１は、ＯＳ−Ｂ５０以外の値になり得ないが、３つ以上のＯＳが動作する場合には、要求元ＯＳ識別子８１は複数の値をとりうる。

次に、呼出ルーチン識別子８２は、被呼出ルーチン登録表４２２に登録済みのルーチンのなかの１つを指定するものである。

呼出パラメータ８３は、被呼出ルーチンを実行する際のパラメータ（引数）群を格納する領域である。パラメータ群は一般には呼出ルーチン毎に異なるが、できるだけ少数かつ小さいサイズのパラメータで済むよう呼出ルーチンを設計することで、呼出パラメータ８３のフィールドを小さい固定サイズとすることが望ましい。これはデバイス設定情報７４の場合と同じく、メモリ管理を容易にするためである。

呼出要求リスト（Ａ）４２３は、図６に示されるように、呼出要求構造体８０のインスタンスがＦＩＦＯ状に格納されるリスト構造である。図６の例では、呼出要求構造体８０が呼出要求構造体（１）８０−１、呼出要求構造体（２）８０−２、呼出要求構造体（３）８０−３・・・の順番に格納されており、呼出要求構造体（１）８０−１、呼出要求構造体（２）８０−２、呼出要求構造体（３）８０−３の順に取り出される。

［動作の説明］
上述した第１の実施の形態の動作について、まず初期設定から説明する。初期設定は、デバイスドライバ間通信部（Ａ）４２および（Ｂ）５２、ＯＳ−Ａ用デバイスドライバ４１、ＯＳ−Ｂ用デバイスドライバ５１の各々について行う。

デバイスドライバ間通信部（Ａ）４２および（Ｂ）５２の初期設定について、図１５を参照して説明する。

図１５を参照すると、デバイスドライバ間通信部（Ａ）４２の初期設定は、ＯＳのコマ間割込みハンドラとして被呼出処理部（Ａ）４２５を登録するステップ２０６と、被呼出状態記憶部（Ａ）４２４の処理中フラグをオフ（クリア）するステップ２０７から成る。デバイスドライバ間通信部（Ｂ）５２も上記と同様に、ＯＳのコマ間割込みハンドラとして被呼出処理部（Ｂ）５２５を登録するステップと、被呼出状態（Ｂ）５２４をクリアするステップから成る。

ＯＳ−Ａ用デバイスドライバ４１の初期設定について、図７を参照して説明する。

図７を参照すると、ＯＳ−Ａ用デバイスドライバ４１の初期設定は、次の３つのステップで実行される。

まず、ステップ２０１で、内部デバイス１４からの割込みハンドラとして、図２のデバイス割り込み処理部４５２内のデバイス完了割込処理ルーチンを登録する。この処理はＯＳ−Ａ４０の機能を利用して実行する。

次に、ステップ２０２で、ＯＳ−Ａ４０におけるデバイスドライバ間通信の被呼出ルーチンの一つとして、後述のデバイス設定ルーチンを登録する。この登録は、デバイスドライバ間通信部（Ａ）４２の被呼出ルーチン登録部（Ａ）４２１（図４）を呼び出すことにより実行する。

最後に、ステップ２０３で、ＯＳ−Ａ用デバイスドライバ４１内の要求待ちリスト４６と処理中リスト４７を共に空にする。

ＯＳ−Ｂ用デバイスドライバ５１の初期設定について、図８を参照して説明する。

図８を参照すると、ＯＳ−Ｂ用デバイスドライバ５１の初期設定は、次のステップからなる。すなわち、ステップ２１１にて、ＯＳ−Ｂ５０におけるデバイスドライバ間通信の被呼出ルーチンの一つとして、後述のタスク再開Ｂルーチンを登録する。この登録は、デバイスドライバ間通信部（Ｂ）５２の被呼出ルーチン登録部（Ｂ）５２１（図４）を呼び出すことによって実行する。

以上が初期設定の動作の説明である。次に各デバイスドライバのタスクインタフェース部の動作を説明する。

まず、ＯＳ−Ａ４０側のタスクインタフェース部（Ａ）４４について説明する。前述のように、タスクインタフェース部（Ａ）４４は、要求解釈部（Ａ）４４１と待機タスク再開部（Ａ）４４２から成る。

ユーザタスク４３からのデバイスアクセス要求があると、まず要求解釈部（Ａ）４４１が呼び出される。その要求解釈部（Ａ）４４１での処理の流れを図９に示す。

要求解釈部（Ａ）４４１は、まず、ステップ２２１にて処理要求構造体７０の新しいインスタンスを作成する。処理要求構造体７０の構造は図３に示した通りである。

ステップ２２１で作成された処理要求構造体７０のインスタンスでは、処理要求識別子フィールド７１は、このデバイスドライバ内でユニークな整数値に設定され、要求元ＯＳ識別子フィールド７２は、ＯＳ−Ａを意味する値に設定され、要求元タスク識別子フィールド７３は、今回のデバイスアクセス要求を行ったユーザタスク４３のタスクＩＤが設定される。

また、デバイス設定情報フィールド７４には、今回のデバイスアクセス要求の種類、パラメータ等、デバイスドライバのデバイスインタフェース部（Ａ）４５が内部デバイス１４に対して行う操作を特定するための情報が格納される。デバイス状態フィールド７５にはこの時点では何も設定されない。

要求解釈部（Ａ）４４１は、次に、上で作成した処理要求構造体インスタンスを、ＯＳ−Ａ用デバイスドライバ内の要求待ちリスト４６に登録する。この要求待ちリスト４６は、ＯＳ−Ａのタスクインタフェース部（Ａ）４４、ＯＳ−Ｂのタスクインタフェース部（Ｂ）５４、更にＯＳ−Ａのデバイス割り込み処理部４５２からアクセスされるため、図９のステップ２２２からステップ２２５にあるように、割り込みを禁止した上で、排他制御すなわちロック−アンロック操作で保護した区間内で実際の登録操作（ステップ２２４）を行う。

ここで、ロック−アンロック操作は例えば、ＯＳが提供する排他制御サービス関数ないしＣＰＵが有する排他制御命令を組み合わせた命令列を用いて行なう。このときのロック操作はビジーウェイト型すなわち、既にロック中の場合はロックが確保できるまで繰り返しロックを試みる形式で行う。ビジーウェイト型でロックを行うのは、本実施の形態では排他制御区間が短いため、もし他者が排他制御区間内を実行中であってもすぐに排他制御区間を抜けることが期待されるからである。ただし、システムの特性により、ロック獲得試行を一定時間試みた上で獲得に成功しなければステップ２２３をタイムアウトし、図９の処理要求全体をエラーで終了させる、という実装の形態をとることも可能である。

次に、要求解釈部（Ａ）４４１は、ステップ２２６にて、同じデバイスドライバ内のデバイス設定部４５１に格納された処理である、デバイス設定ルーチンを呼び出す。このデバイス設定ルーチンの動作は後述するが、その概要は、要求待ちリスト４６から次の処理要求構造体を取り出して内部デバイス１４を適切に設定する、という処理である。

その後、要求解釈部（Ａ）４４１は、ステップ２２７で割り込みを許可し、ステップ２２８でＯＳ−Ａのサービス関数を用いてユーザタスク（Ａ０）４３を待ち状態（スリープ状態）に遷移させる。

これによりＯＳ−Ａは呼び出し元ユーザタスク（Ａ０）４３の実行を中断し、別の実行可能ユーザタスクがあれば、そのタスクにタスク切り替えすることになる。以上が要求解釈部（Ａ）４４１の動作の流れである。

デバイスでの処理が終わると、デバイス割り込み処理部４５２が、その処理結果を処理要求構造体７０のデバイス状態フィールド７５に格納して、タスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２を呼び出す。この一連の処理は後述するが、ここでは、図１０を用いてその待機タスク再開部（Ａ）４４２の動作の流れを説明する。

まず、ステップ２３１で、処理要求構造体７０のデバイス状態フィールド７５からデバイス処理結果を読み出し、呼び出し元ユーザタスク（Ａ０）４３内の所定のメモリ領域にデバイス処理結果をコピーする。ＵＮＩＸなどＯＳカーネルとユーザタスクが別の論理メモリ空間で動作するＯＳの場合、このコピーは、カーネル空間からユーザタスク空間へのコピーを実行する、ＯＳ提供のサービス関数を呼び出すことで行う。

次に、ステップ２３２で、前述のステップ２２１で確保した処理要求構造体７０のメモリを解放し、最後にステップ２３３で、ＯＳ−Ａ４０のサービス関数を用いてユーザタスク（Ａ０）４３を実行可能状態に遷移させる。

これにより、ＯＳ−Ａ４０は、デバイス処理待ちで中断していたユーザタスク（Ａ０）４３の実行を再開することになる。以上が待機タスク再開部（Ａ）４４２の動作の流れである。

次に、ＯＳ−Ｂ５０側のタスクインタフェース部（Ｂ）５４を説明する。前述のように、タスクインタフェース部（Ｂ）５４は、要求解釈部（Ｂ）５４１と待機タスク再開部（Ｂ）５４２から成る。これらはＯＳ−Ａ４０側の対応する部分と類似する動作を行うが、要求待ちリスト、処理中リスト、及びデバイスインタフェース部とのやりとりに関しＯＳ−Ａ側に対して働きかける点が異なっている。

ＯＳ−Ｂ５０上のユーザタスク（Ｂ０）５３からデバイスアクセス要求があると、まず要求解釈部（Ｂ）５４１が呼び出される。その要求解釈部（Ｂ）５４１での処理の流れを図１１に示す。

要求解釈部（Ｂ）５４１は、まずステップ２４１にて処理要求構造体７０の新しいインスタンスを作成する。このステップはＯＳ−Ａ４０側での対応する処理であるステップ２２１と同様であるが、要求元ＯＳ識別子フィールド７２にはＯＳ−Ｂ５０を識別する値が設定される。

次に、要求解釈部（Ｂ）５４１は、上で作成した処理要求構造体７０のインスタンスを、ＯＳ−Ａ用デバイスドライバ４１内の要求待ちリスト４６に登録する。ＯＳ間排他制御のため、図１１のステップ２４２、ステップ２４４にあるように、ロック−アンロック操作で保護した区間内で実際の登録操作（ステップ２４３）を行う。

ロック−アンロック操作の実装については、図９に示したＯＳ−Ａ側の処理（ステップ２２３、ステップ２２５）と同様である。すなわち、ＯＳが提供する排他制御サービス関数ないしＣＰＵが有する排他制御命令を組み合わせた命令列を用いてロック及びアンロック操作を行なう。

要求解釈部（Ｂ）５４１は、次にステップ２４５にて、以下のパラメータを指定してデバイスドライバ間通信部（Ｂ）５２を呼び出すことで、ＯＳ−Ａ側のデバイスインタフェース部（Ａ）のデバイス設定ルーチンを遠隔呼び出しする。

呼出先ＯＳ＝ＯＳ−Ａ、呼出ルーチン識別子＝デバイス設定ルーチンの識別子（ステップ２０２で登録したもの）、呼出パラメータ＝なし

デバイスドライバ間通信部の動作については後述する。

その後、要求解釈部（Ｂ）５４１は、ステップ２４６でＯＳ−Ｂ５０のサービス関数を用いてユーザタスク（Ｂ０）５３を待ち状態（スリープ状態）に遷移させる。

これにより、ＯＳ−Ｂ５０は呼び出し元ユーザタスク（Ｂ０）５３の実行を中断し、別の実行可能ユーザタスクがあれば、そのタスクにタスク切り替えすることになる。以上が要求解釈部（Ｂ）５４１の動作の流れである。

デバイスでの処理が終わるとＯＳ−Ａ４０側に割り込みが入り、デバイス割り込み処理部４５２がデバイス処理結果を処理要求構造体７０のデバイス状態フィールド７５に格納して、その処理要求構造体インスタンスを引数としてタスクインタフェース部（Ｂ）５４の待機タスク再開部（Ｂ）５４２を呼び出す。この一連の処理は後述するが、ここでは図１２を用いてその待機タスク再開部（Ｂ）５４２の動作の流れを説明する。

まずステップ２５１で、引数として与えられた処理要求構造体７０のデバイス状態フィールド７５からデバイス処理結果を読み出し、呼び出し元ユーザタスク（Ｂ０）５３内の所定のメモリ領域にデバイス処理結果をコピーする。ＵＮＩＸなどＯＳカーネルとユーザタスクが別の論理メモリ空間で動作するＯＳの場合、このコピーは、カーネル空間からユーザタスク空間へのコピーを実行する、ＯＳ提供のサービス関数を呼び出すことにより行う。

次にステップ２５２で、前述のステップ２４１で確保した処理要求構造体７０のメモリを解放し、最後にステップ２５３で、ＯＳ−Ｂ５０のサービス関数を用いてユーザタスク（Ｂ０）５３を実行可能状態に遷移させる。

これにより、ＯＳ−Ｂ５０は、デバイス処理待ちで中断していたユーザタスク（Ｂ０）５３の実行を再開することになる。以上が各デバイスドライバのタスクインタフェース部の動作の説明である。

次に、ＯＳ−Ａ側デバイスドライバ４１に固有のデバイスインタフェース部（Ａ）４５の動作を説明する。前述のように、デバイスインタフェース部（Ａ）４５は、デバイス設定部４５１とデバイス割り込み処理部４５２から成る。

図１３を参照して、デバイス設定部４５１の動作の流れを説明する。デバイス設定部４５１は割り込み禁止状態で呼び出されることが想定されている。

ステップ２６１〜ステップ２６３にて、デバイス設定のループ処理の継続条件を判断する。要求待ちリスト４６に処理要求構造体が全く存在しない場合、あるいは、ループ継続の繰り返し回数が所定の上限値を越えている場合、あるいは、内部デバイス１４が既に処理中で、新たな処理が受け付けられない状態の場合は、ループを抜け、デバイス設定処理を終了する。

ここで、ループ継続の上限値は、デバイス設定を繰り返すことで割り込み禁止区間が長引き、他の処理（例えばＯＳのタスク切り替えやリアルタイム処理）に悪影響を及ぼすことを防ぐために設定されるものである。

内部デバイスがｎ種類の処理要求を同時に受け付けられるのであれば、ループ継続上限値はｎないしそれ未満の値に設定する。他方、内部デバイスがせいぜい1つの処理要求しか受け付けられないなら、ループ継続上限値は１固定となる。

また、前記趣旨から、ループ継続上限値に代えて、本デバイス設定処理に費やした時間の上限値を用いる実施形態も考えられる。この場合、デバイス設定処理の開始時にタイマ等により現在時刻を取得し、ステップ２６２にて再度タイマ等により現在時刻を取得して開始時刻からの経過時刻を算出し、その値が上限値を越えていたらデバイス設定を終了する、という動作の流れになる。

ステップ２６４〜ステップ２６６にて、要求待ちリストから１つの処理要求構造体インスタンスを取り出す。取り出すインスタンスは、要求待ちリスト内に蓄積されている全インスタンスの中から、一定ルールで選び出す。例えば、時間的に先に到着したものを先に取り出す（ＦＩＦＯ）というルールを用いる。

また、要求待ちリストは本デバイス設定部以外にＯＳ−Ａ４０及びＯＳ−Ｂ５０のタスクインタフェース部からもアクセスされるため、排他制御のためのロック−アンロック操作を前後にはさむ。このロック−アンロックは、ＯＳによる排他制御サービス関数呼び出しあるいはＣＰＵが有する排他制御命令の組み合わせで実現される。このロック操作はビジーウェイト型すなわち、既にロック中の場合はロックが確保できるまで繰り返す形式で行う。ＯＳのサービス関数を使う場合は、割り込みハンドラから安全に呼び出せるものに限る。

ステップ２６７にて、処理要求構造体７０のデバイス設定情報フィールド７４を参照して、内部デバイス１４に対して設定値を書き込み、内部デバイス１４を目的の動作状態に遷移させる。

このステップ２６７は対象となるデバイスごとに異なる実装になるが、例えばＤＭＡコントローラであれば、転送元アドレスレジスタ、転送先アドレスレジスタ、転送サイズレジスタに設定値を書き込み、制御レジスタの所定ビットを設定してＤＭＡ転送を開始させる、といった処理を行う。また他の例としてグラフィックアクセラレータをとりあげると、デバイス設定情報フィールド７４の内容に従ってワークメモリ上に描画コマンド列を作成し、制御レジスタの所定ビットを設定することで、グラフィックアクセラレータの描画処理を起動する、といった処理を行う。これらの処理は、関連技術のデバイスドライバ、例えば一般的なＤＭＡデバイスドライバ、グラフィックアクセラレータデバイスドライバがそれぞれの内部デバイスに対して行っている処理と同様である。

内部デバイス１４が複数の処理要求を受け付けるタイプのデバイスである場合、ステップ２６７では上記に加え、デバイスに投入した複数の処理を識別するための識別子の値を、処理要求構造体７０の処理要求識別子フィールド７１に設定する。この識別子はデバイスによって異なるが、例えばトランザクションＩＤやコマンドキューイングＩＤなどである。

最後にステップ２６８にて、前述のステップ２６５で取り出した処理要求構造体７０のインスタンスを、処理中リスト４７に登録する。処理中リスト４７はＯＳ−Ａのタスクインタフェース部（Ａ）４４からもアクセスされるが、タスクインタフェース部（Ａ）４４とデバイスインタフェース部４５とは、割り込み禁止/許可操作によって既に排他制御が行われているため、ステップ２６８前後には特段の排他制御処理は不要である。

以上が、デバイス設定部４５１の動作の流れの説明である。

次に、図１４を参照して、デバイス割り込み処理部４５２の動作の流れを説明する。デバイス割り込み処理部４５２は、内部デバイスからＯＳ−Ａ４０への割り込みに対するハンドラとして呼び出されるため、その処理全体が割り込み禁止状態で実行される。

まずステップ２７１にて、すみやかに内部デバイス１４からデバイス状態を読み出す。これは、デバイスに対する次の外部イベント、例えば後続のグラフィック描画処理の完了や後続のディスク読み出し処理の完了等が起きてデバイス状態が変化してしまうことを回避すること、あるいはシリアルポート等、デバイスによってはデバイス状態を読み出さない限り次のデバイス処理が進まないことがあり、その事態を回避すること、などの理由による。

ステップ２７２にて、処理中リスト４７から、今回の完了割り込みに対応する処理要求構造体７０のインスタンスを取り出す。内部デバイス１４が複数の処理要求を受け付けるタイプのデバイスである場合、前述のステップ２６７で設定した処理要求識別子フィールド７１の値を内部デバイス側と照合することで、対応する処理要求構造体７０のインスタンスを一意に特定する。

ステップ２７３にて、ステップ２７１で読み出したデバイス状態の値を、ステップ２７２で取り出した処理要求構造体７０のデバイス状態フィールド７５に格納する。これにより、内部デバイスの処理完了後の状態が処理要求構造体７０のインスタンス内に退避できたことになる。

ステップ２７４にて、処理要求構造体インスタンスの要求元ＯＳ識別子７２を参照して要求元ＯＳを判断する。

もし要求元ＯＳがＯＳ−Ａ４０であった場合、ステップ２７５にて、前記処理要求構造体７０のインスタンスを引数として、待機タスク再開部（Ａ）４４２を呼び出す。待機タスク再開部Ａでの処理の流れは、図１０のステップ２３１からステップ２３３で説明した通りである。この操作により、デバイス処理完了を待っていたＯＳ−Ａ４０上の呼び出し元ユーザタスク（Ａ０）４３の動作が再開される。

もし要求元ＯＳがＯＳ−Ａ以外であった場合、ステップ２７７にて、以下のパラメータを指定してデバイスドライバ間通信部（Ａ）４２を呼び出すことで、要求元ＯＳのデバイスインタフェース部の待機タスク再開部を遠隔呼び出しする。

呼出先ＯＳ＝要求元ＯＳ、呼出ルーチン識別子＝要求元ＯＳのタスク再開ルーチンの識別子（ステップ２１１で登録したもの）、呼出パラメータ＝前記処理要求構造体インスタンス

この操作により、要求元ＯＳ上でデバイス処理完了を待っていた呼び出し元ユーザタスク（この説明の例ではユーザタスク（Ｂ０）５３）の動作が再開される。

最後にステップ２７６にて、デバイス設定部４５１にあるデバイス設定ルーチンを呼び出し、次の処理を内部デバイス１４に設定する。この部分の動作は、図１３のステップ２６１からステップ２６８にて説明した通りである。

以上がＯＳ−Ａ側にあるデバイスインタフェース部４５の動作の説明である。

次に、異なるＯＳ上のデバイスドライバ間で直接通信を行う、デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２の動作の流れについて説明する。１組の通信は片方のデバイスドライバからもう片方のデバイスドライバへの単方向通信であり、同種のものを２組用いることで双方向通信を実現することができる。そこで以下では１組の単方向通信の動作について説明する。

デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２は、遠隔呼び出しのためのパラメータ、すなわち、通信相手のＯＳと、そのＯＳ上で呼び出したい呼出ルーチン識別子、及びそのルーチンに渡す呼出パラメータ、の３つを指定して各ＯＳのデバイスドライバから呼び出される。

図１６を参照すると、デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２はまずステップ２８１にて、与えられたパラメータのうち、呼出ルーチン識別子と呼出パラメータの２つを用いて図５に示す呼出要求構造体８０のインスタンスを作成する。要求元ＯＳ識別子フィールド８１には、呼び出し元のＯＳを識別する値を設定する。

ステップ２８３では上記呼出要求構造体８０のインスタンスを、呼び出す相手ＯＳの呼出要求リスト（Ａ）４２３又は（Ｂ）５２３に追加する。この呼出要求リストは相手ＯＳからもアクセスされるため、排他制御のために直前のステップ２８２にてロックを獲得する。このロックはＣＰＵ自身が備える排他制御命令あるいはそれ相当のＯＳサービス関数で行う。

ステップ２８４にて、相手ＯＳのデバイスドライバ間通信部が処理中か否かを判断する。これは相手側のデバイスドライバ通信部内の被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグを直接参照することで判断する。

もし相手のデバイスドライバ間通信部が処理中でなければ、ステップ２８５にて、相手ＯＳへのコア間割り込みを発生させる。これはＣＰＵ自身のハードウェア操作命令ないしそれに相当するＯＳサービス関数により、コア間割り込み発生部１３に対して相手ＯＳが動作するＣＰＵコアへのＣＰＵコア間割り込みを要求することで行う。これにより相手のデバイスドライバ間通信部が呼出要求リスト５２３、５２３内に蓄積されている新規要求を処理し始める。これはすぐ後で説明する。

もし相手のデバイスドライバ間通信部が処理中であれば、ステップ２８３で呼出要求リスト４２３、５２３に追加した要求がやがて処理されるので、ステップ２８５は単純にスキップして次へ進む。

ステップ２８６にて、ステップ２８２で獲得したロックをアンロックし、排他制御区間を抜ける。

ステップ２８５で相手ＯＳへのコア間割り込みを起こすと、相手ＯＳ側では、図１５のステップ２０６で設定した被呼出処理部が呼び出される。この被呼出処理部の動作の流れを図１７を参照して説明する。以下の被呼出処理部の説明においては、この相手ＯＳすなわち被呼出側ＯＳのことを「自ＯＳ」と呼ぶ。

被呼出処理部４２５、５２５は、ステップ２９２にて自ＯＳの呼出要求リスト４２３、５２３を調べ、それが空であれば、ステップ２９７にて被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグをオフ（処理中でない）にして、被呼出処理部４２５、５２５全体の処理を終える。

もし呼出要求リスト４２３、５２３が空でなければ、ステップ２９３にて呼出要求リスト４２３、５２３の先頭から呼出要求構造体８０のインスタンスを１つ取り出し、ステップ２９４にて被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグをオン（処理中）にしてから、ステップ２９６にて事前登録済みルーチンを呼び出す。

ここで呼出要求リスト（図４の４２３ないし５２３）は呼出元のデバイスドライバ間通信部でもアクセスする可能性があるため、ステップ２９２からステップ２９４およびステップ２９７をロック−アンロックによる排他制御によって保護する。このロックはＣＰＵ自身が備える排他制御命令あるいはそれ相当のＯＳサービス関数で行う。

再度ステップ２９６の説明に戻ると、ここでは、呼出要求構造体８０の呼出ルーチン識別子フィールド８２をキーとして自ＯＳ内の被呼出ルーチン登録表（図４の４２２ないし５２２）を検索することで、呼び出すべきルーチンを特定する。そして、呼出要求構造体８０の呼出パラメータフィールド８３に格納された値を前記ルーチンの引数として被呼出ルーチンの呼び出しを行う。

以上が、デバイスドライバ間通信部による処理の流れの説明である。

さらに理解を助けるために、各部の流れを通して示した図面を参照して、ＯＳ−Ａ４０上のタスクからのデバイスアクセス、ＯＳ−Ｂ５０上のタスクからのデバイスアクセスの様子について説明する。

図１８は、ＯＳ−Ａ４０上で実行されている２つのタスクすなわちユーザタスク（Ａ０）とユーザタスク（Ａ１）が、あるデバイスを共有アクセスしている様子を示している。図１８において、上から下方向に時間が流れており、縦方向の細長い矩形はそのタスクや構成部分が動作している部分を示し、縦方向の細長い斜線ハッチング付きの矩形はその構成部分にデータ（インスタンス）が存在していることを示している。また、横方向の実線矢印はルーチンの呼出しや割り込みを示し、点線矢印はそれらの処理からの戻りを示している。

図１８右上で、ユーザタスク（Ａ０）がデバイスに対して処理「ＸＸＸ」を要求している。この処理要求はＯＳ−Ａ４０のタスクインタフェース部（Ａ）４４から直接デバイス設定部４５１に到達し、デバイス設定部４５１が内部デバイス１４を設定して「ＸＸＸ」の処理が開始される。その「ＸＸＸ」処理が完了する前に、他のユーザタスク（Ａ１）から処理「ＹＹＹ」が要求されると、その要求はデバイス設定部４５１まで到達するが、内部デバイス１４は「ＸＸＸ」処理中のため、処理要求構造体７０が要求待ちリスト４６に入ったままになる。いずれの場合も、呼出元であるユーザタスク（Ａ０）、ユーザタスク（Ａ１）はＯＳ−Ａ４０上で待ち状態にされる。

内部デバイス１４が「ＸＸＸ」処理を終えるとＯＳ−Ａ４０に対し割り込みが入り、ＯＳ−Ａ４０の割り込みハンドラからデバイス割り込み処理部４５２が呼び出される。

デバイス割り込み処理部４５２は、内部デバイス１４の「ＸＸＸ」処理結果を処理中リスト４７に格納してからＯＳ−Ａタスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２を呼び出す。

待機タスク再開部（Ａ）４４２は、処理中リスト４７を読み出して処理結果を取得し、待ち状態になっていたユーザタスクＡ０を再開させる。デバイス割り込み処理部４５２は、更に、デバイス設定部４５１を呼び出して、要求待ちリスト４６で待機していた次の処理「ＹＹＹ」を取り出し、内部デバイス１４に設定する。

その後、内部デバイス１４が「ＹＹＹ」処理も終えると、上と同様にＯＳ−Ａ４０に完了割り込みが入り、デバイス割り込み処理部４５２が処理結果を一旦処理中リスト４７に格納してから、タスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２がユーザタスク（Ａ１）を再開させる。

次に、図１９を参照して、デバイス操作を行うＯＳとは別のＯＳからデバイスアクセス要求を出す場合を説明する。ここではＯＳ−Ｂ５０上の２つのタスクすなわちユーザタスク（Ｂ０）とユーザタスク（Ｂ１）が、ＯＳ−Ａ４０側を介してデバイスにアクセスする場合を例にとって説明する。

図１９右上にて、ユーザタスク（Ｂ０）とユーザタスク（Ｂ１）が相次いでデバイスアクセス要求「ＸＸＸ」及び「ＹＹＹ」をそれぞれ発行している。これらの要求はＯＳ−Ｂ５０側のタスクインタフェース部（Ｂ）５４で受理された後、デバイスドライバ間通信部（Ｂ）５２及び（Ａ）４２を介してＯＳ−Ａ４０側のデバイス設定部４５１に送り込まれる。

このとき、デバイスドライバ間通信部（Ｂ）５２及び（Ａ）４２の内部で、コア間割り込み発生部１３によるＣＰＵコア間割り込みが使用され、ＯＳ−Ａ４０側の割り込みハンドラからデバイス設定部４５１が呼び出されている。デバイス設定部４５１が内部デバイス１４に対して設定を行う部分は、図１８の場合と同様である。

内部デバイス１４が処理「ＸＸＸ」を終えると、図１８の場合と同様にＯＳ−Ａ４０に割り込みが入り、デバイス割り込み処理部４５２がデバイス完了割込処理を行うが、デバイス割り込み処理部４５２は処理要求構造体の要求元ＯＳ識別子を見て呼出元タスクがＯＳ−Ｂ５０であることを知り、デバイスドライバ間通信部（Ａ）４２及び（Ｂ）５２を用いてＯＳ−Ｂ５０側のタスクインタフェース部（Ｂ）５４を呼び出す。

このとき、デバイスドライバ間通信（Ａ）４２及び（Ｂ）５２の内部で、コア間割り込み発生部１３によるＣＰＵコア間割り込みが使用され、ＯＳ−Ｂ５０側の割り込みハンドラから待機タスク再開部（Ｂ）５４２が呼び出されている。

タスクインタフェース部Ｂの待機タスク再開部（Ｂ）５４２がユーザタスクを再開する部分は、図１８の場合と同様である。

（第１の実施の形態による効果）
第１の実施の形態によれば、クライアント側であるＯＳ−Ｂ５０上のタスクからのデバイスアクセス性能を向上させることができる。その理由は、ＯＳ間の通信においてデバイスドライバ間での高速な通信手段を用いること、及びデバイスドライバ内のデータ構造を両デバイスドライバ間で直接アクセスすることで、通信を介したデータのやりとりを減少させたためである。

また、デバイス共有のためのソフトウェア開発コストを低く抑えることができる。その理由は、ソフトウェア階層において最も低い階層にあり、少数の基本的な機能のみを実現するデバイスドライバの間で通信させる方式を用いたことで、ＯＳ間（クライアント-サーバ）通信に対応させるために改造を要する機能が最小限となるためである。

本実施の形態では、サーバ-クライアント（ＯＳ−Ａ４０とＯＳ−Ｂ５０）間のやりとりにおいて、別途プロキシタスクを介することなく、デバイスドライバ間通信を使ったカーネルレベルの通信を用いる。また、ＯＳ−Ｂ５０（クライアント側）のデバイスドライバ５１は、ＯＳ−Ａ４０（サーバ側）のデバイスドライバ４１内の要求待ちリスト４６および処理中リスト４７に直接アクセスする。

一般に、ソフトウェア階層においては、より低い階層の機能を組み合わせたり、あるいはそのバリエーションを増やして使いやすくした形で、より高い階層の機能を構成するため、より高い階層になるほど多くの種類のＡＰＩを備える傾向にある。逆に、最も低い層にあるデバイスドライバが備える機能は、一般に、オープン、クローズ、読み取り、書き込み、など少数の種類にとどまる。本実施の形態では、デバイスドライバという最も低い階層における通信を用いることで、デバイスドライバ間で通信させるための改造箇所を最小限にとどめることを可能にしている。

（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。

図２０を参照すると、第２の実施の形態は、デバイスインタフェース部（Ａ）４５に新たに判定部４５３を備えることを特徴としている。それ以外の部分は上述した第１の実施の形態と同様である。

判定部４５３は、要求待ちリスト４６に蓄積されている１つ以上の処理要求構造体７０のインスタンスに対し、一定の規則に従って受理／却下の判定を下す機能、あるいは、一定の規則に従って次に処理すべきインスタンスを選定する機能を有する。

デバイス設定部４５１には、判定部４５３が受理と判定した処理要求構造体７０のインスタンス、あるいは次に処理すべきと選定した処理要求構造体７０のインスタンスが渡される。

具体的には、判定部４５３は、例えば、要求待ちリスト４６中の処理要求構造体７０のインスタンスのうち、あらかじめ指定されているＯＳ（例えばＯＳ−Ａ４０）以外のＯＳから要求されたインスタンスを破棄し、あるいは、あらかじめ指定されているＯＳ−タスクの組（例えばＯＳ−Ｂ５０上のタスク＃２とＯＳ−Ｂ５０上のタスク＃４等）から要求されたインスタンスを破棄するようにすることが可能である。

このような判定部４５３を導入することにより、内部デバイスに対するＯＳ−タスクレベルでのアクセス制御を行うことができるという、新たな効果が得られる。

また、他の具体例では、判定部４５３は、要求待ちリスト４６中の処理要求構造体７０のインスタンスを選択する際、直前の判定時に選択したインスタンスの要求元ＯＳとは異なる要求元ＯＳ値をもつインスタンスを優先して選択する、あるいは、あらかじめ指定されたＯＳ−タスクの組（例えばＯＳ−Ｂ上のタスク＃３）を要求元とするインスタンスが存在すれば必ずそれを選択するようにすることが可能である。

このような判定部４５３を導入することにより、内部デバイスへアクセス要求を出す各ＯＳに対して公平なスケジューリングが可能になるという新たな効果が得られる。また、特定のＯＳ−タスクに対して優先的なデバイスアクセス権を与えることができるという、デバイスリソーススケジューリングに関する新たな効果が得られる。

（第３の実施の形態）
次に、本発明の第３の実施の形態について説明する。

図２１を参照すると、第３の実施の形態は、ＯＳ−Ａ４０内の要求待ちリスト４６が異なる目的の複数のリストから構成されていることを特徴とする。それ以外の部分は第１の実施の形態と同様である。

この第３の実施の形態では、上記要求待ちリスト４６の内部の各リストは、各ＯＳに対応づけられることを特徴とする。

すなわち、リスト４６１はＯＳ−Ａ４０に、リスト４６２はＯＳ−Ｂ５０に対応している。この例ではＯＳは２種類のみ示されているためリスト４６３は使用されない。

そして、各ＯＳの要求解釈部（図２１の４４１、５４１）は、それぞれのＯＳに対応したリストに処理要求構造体７０のインスタンスを投入する。デバイス設定部４５１は、一定の規則、例えば各リストを順番に見て、処理要求構造体７０のインスタンスを取り出し、処理していく。タスクインタフェース部とデバイスインタフェース部は要求待ちリスト４６内の各リスト４６１〜４６３毎に排他制御用のロック−アンロック操作を行う。

上記第３の実施の形態によれば、要求待ちリストのロック−アンロックがＯＳ毎に実施されるため、本発明の第１の実施の形態に比べ、ロック獲得時に衝突が発生して待たされる可能性が低くなる。つまり、デバイスアクセスを行う際の性能オーバヘッドを低減する効果が得られる。この効果は、内部デバイスに対して細かなアクセス要求を高頻度に行う場合に特に顕著である。

また、第３の実施の形態における変形例として、上記要求待ちリスト４６の内部の各リストが、異なる処理優先度で対応付けられるように構成することも可能である。

すなわち、要求待ちリスト４６のリスト４６１を最高優先度、リスト４６２を普通の優先度、リスト４６３を最低優先度に対応付ける。これにより、例えば、デバイス設定部４５１は、リスト４６１を２回参照した後、リスト４６２を１回参照し、最初に見つかった処理要求構造体７０のインスタンスを取り出して処理するといった制御が可能となる。デバイス設定部４５１は、リスト４６１、４６２がいずれも空だった場合に限りリスト４６３を参照する。

上記実施の形態の変形例によれば、デバイス設定部４５１は参照回数ベースの簡単な規則に従ってリスト４６１〜４６３を参照することで内部デバイスへのアクセス優先度制御が行える。すなわち、内部デバイスに対するアクセス優先度制御を容易かつ低いＣＰＵオーバヘッドで実現できるという効果が得られる。

なお、上記第２、第３の実施の形態を組み合わせて構成することも可能である。例えば、要求待ちリスト４６内に、ＯＳ毎に専用のリストを設けた上で、判定部４５３にて要求元タスクを調べて要求受理／却下判定を行う、といった構成により、性能オーバヘッドを抑えつつＯＳ−タスク毎のアクセス制御機能を搭載したＯＳ間デバイス共有機構を構築することができる。

（第４の実施の形態）
次に、本発明の第４の実施の形態について説明する。

図２２を参照すると、第４の実施の形態は、ＯＳ−Ａ４０にはタスクインタフェース部を備えず、デバイスインタフェース部のみを具備することを特徴とする。それ以外の部分は第１の実施の形態と同様である。

上記実施の形態によれば、ＯＳ−Ａ４０では内部デバイスをアクセスするユーザタスクは一切稼動せず、ＯＳ−Ａ４０は内部デバイスの制御や管理に専念することになる。

そのため本実施の形態は、内部デバイスのリアルタイム制御が行いやすいという効果をもたらす。この効果はＯＳ−Ａ４０としてリアルタイム処理（実時間処理）に適したＯＳ、例えばＴ−Ｋｅｒｎｅｌ等のリアルタイムＯＳを使用する場合に特に顕著である。

更には、ＯＳ−Ａ４０としてリアルタイムＯＳを使用することに加え、ＯＳ−Ｂ５０としてＵＮＩＸやＷｉｎｄｏｗｓのようなアプリケーション向けの高度な機能を有するＯＳを使用すれば、デバイス制御のためのリアルタイム性能とアプリケーション向けの豊富な機能を両立したシステムを、１つのマルチコアプロセッサ上で実現することができる、という効果も実現できる。

以上好ましい実施の形態と実施例をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態及び実施例に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。

この出願は、２００８年３月１１日に出願された日本出願特願２００８−０６０８０４を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、マルチコアプロセッサ上で複数ＯＳを稼動させることで多様な動作要求を同時に満たす必要がある製品分野に適用可能である。例えば、無線ネットワーク処理とユーザ向けアプリケーション処理を行う携帯端末機器、放送受信と映像メディア処理とユーザインタフェース処理を行う情報家電機器、パワートレイン系とボデー系と情報メディア系の処理をあわせもつ車載機器、メカトロニクス制御と知能処理と対人インタフェース処理とを行うロボット搭載機器、などへの適用が想定される。

Claims (13)

1. 複数のＯＳが動作するマルチプロセッサシステムにおいて、
   前記複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有し、
   特定のＯＳ上の前記デバイスドライバが、操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、前記ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行うタスクインタフェース部と、前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持する要求待ちリストと、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持する処理中リストとを備え、
   他のＯＳ上の前記デバイスドライバが、前記特定のＯＳ上の前記デバイスドライバの前記タスクインタフェース部と同じ機能を有し、前記デバイスインタフェース部とＯＳ間通信を行うタスクインタフェース部を備え、
   前記タスクインタフェース部は、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、前記デバイスインタフェース部に通知し、
   前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させ、
   前記デバイスの動作完了後に、前記デバイスインタフェース部は、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、当該処理の要求元の前記タスクインタフェース部に通知し、
   前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部は、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却し、
   前記ＯＳが、前記ＯＳ間通信を行うデバイスドライバ間通信部を備え、
   前記デバイスドライバ間通信部は、
   １つ以上の被呼出ルーチンを登録する登録部と、
   自ＯＳの登録済み被呼出ルーチンを呼び出す被呼出処理部と、
   通信先ＯＳの被呼出ルーチンを遠隔で呼び出す呼出処理部とを有し、
   前記被呼出ルーチンは少なくとも、対象のデバイスを設定して動作させる処理を前記デバイスインタフェース部に実行させるデバイス設定ルーチンを含み、
   前記他のＯＳの前記タスクインタフェース部が、前記タスクからデバイスアクセス要求があった場合に、前記他のＯＳのデバイスドライバ間通信部を呼び出し、
   呼び出された前記他のＯＳのデバイスドライバ間通信部の前記呼出処理部が、前記デバイス設定ルーチンの識別子と、前記デバイス設定ルーチンに渡す引数とを、ＯＳ間共有メモリ領域とプロセッサ間割り込み機構を用いて前記特定のＯＳの被呼出処理部に通知し、
   前記特定のＯＳは、プロセッサ間割り込みのハンドラの中で前記被呼出処理部を呼び出し、
   前記特定のＯＳの前記被呼出処理部は、前記他のＯＳの前記呼出処理部から通知された前記被呼出ルーチン識別子とその引数に基づいて、前記デバイス設定ルーチンを呼び出し、前記デバイスを設定する
   ことを特徴とするマルチプロセッサシステム。
2. 前記デバイスインタフェース部は、前記タスクインタフェース部からのデバイスアクセス要求の優先度に基づいて、操作対象のデバイスへの複数のデバイスアクセス要求の順序を決定することを特徴とする請求項１に記載のマルチプロセッサシステム。
3. 前記デバイスインタフェース部は、前記デバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項１に記載のマルチプロセッサシステム。
4. 前記要求待ちリストが、前記複数のＯＳの各ＯＳ毎に対応付けられた複数のリストから構成されることを特徴とする請求項１に記載のマルチプロセッサシステム。
5. 前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
   前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項１に記載のマルチプロセッサシステム。
6. 複数のＯＳが動作するマルチプロセッサシステムにおいて、
   前記複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有し、
   特定のＯＳ上の前記デバイスドライバが、操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、前記ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行うタスクインタフェース部と、前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持する要求待ちリストと、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持する処理中リストとを備え、
   他のＯＳ上の前記デバイスドライバが、前記特定のＯＳ上の前記デバイスドライバの前記タスクインタフェース部と同じ機能を有し、前記デバイスインタフェース部とＯＳ間通信を行うタスクインタフェース部を備え、
   前記タスクインタフェース部は、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、前記デバイスインタフェース部に通知し、
   前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させ、
   前記デバイスの動作完了後に、前記デバイスインタフェース部は、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、当該処理の要求元の前記タスクインタフェース部に通知し、
   前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部は、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却し、
   前記ＯＳが、前記ＯＳ間通信を行うデバイスドライバ間通信部を備え、
   前記デバイスドライバ間通信部は、
   １つ以上の被呼出ルーチンを登録する登録部と、
   自ＯＳの登録済み被呼出ルーチンを呼び出す被呼出処理部と、
   通信先ＯＳの被呼出ルーチンを遠隔で呼び出す呼出処理部とを有し、
   前記被呼出ルーチンは少なくとも、対象のデバイスを設定して動作させる処理を前記デバイスインタフェース部に実行させるデバイス設定ルーチンを含み、
   前記他のＯＳの前記タスクインタフェース部が、前記タスクからデバイスアクセス要求があった場合に、前記他のＯＳのデバイスドライバ間通信部を呼び出し、
   呼び出された前記他のＯＳのデバイスドライバ間通信部の前記呼出処理部が、前記デバイス設定ルーチンの識別子と、前記デバイス設定ルーチンに渡す引数とを、ＯＳ間共有メモリ領域とプロセッサ間割り込み機構を用いて前記特定のＯＳの被呼出処理部に通知し、
   前記特定のＯＳは、プロセッサ間割り込みのハンドラの中で前記被呼出処理部を呼び出し、
   前記特定のＯＳの前記被呼出処理部は、前記他のＯＳの前記呼出処理部から通知された前記被呼出ルーチン識別子とその引数に基づいて、前記デバイス設定ルーチンを呼び出し、前記デバイスを設定する
   ことを特徴とするマルチプロセッサシステムで実行されるプログラムであって、
   前記特定のＯＳ上で実行される前記デバイスドライバと、前記他のＯＳ上で実行される前記デバイスドライバと、前記ＯＳが備えるデバイスドライバ間通信部と、を包含する
   ことを特徴とするＯＳ間デバイス共有プログラム。
7. 前記デバイスインタフェース部は、前記タスクインタフェース部からのデバイスアクセス要求の優先度に基づいて、操作対象のデバイスへの複数のデバイスアクセス要求の順序を決定することを特徴とする請求項６に記載のＯＳ間デバイス共有プログラム。
8. 前記デバイスインタフェース部は、前記デバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項６に記載のＯＳ間デバイス共有プログラム。
9. 前記要求待ちリストが、前記複数のＯＳの各ＯＳ毎に対応付けられた複数のリストから構成されることを特徴とする請求項６に記載のＯＳ間デバイス共有プログラム。
10. 前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
    前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項６に記載のＯＳ間デバイス共有プログラム。
11. ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有する複数のＯＳが動作するマルチプロセッサシステムのＯＳ間デバイス共有方法であって、
    特定のＯＳ上の前記デバイスドライバが、操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、前記ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行うタスクインタフェース部と、前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持する要求待ちリストと、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持する処理中リストとを備え、
    他のＯＳ上の前記デバイスドライバが、前記特定のＯＳ上の前記デバイスドライバの前記タスクインタフェース部と同じ機能を有し、前記デバイスインタフェース部とＯＳ間通信を行うタスクインタフェース部を備え、
    前記タスクインタフェース部が、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、前記デバイスインタフェース部に通知するステップと、
    前記デバイスインタフェース部が、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させるステップと、
    前記デバイスの動作完了後に、前記デバイスインタフェース部が、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、当該処理の要求元の前記タスクインタフェース部に通知するステップと、
    前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部が、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却するステップとを有し、
    前記ＯＳが備え、前記ＯＳ間通信を行うデバイスドライバ間通信部が、あらかじめ１つ以上の被呼出ルーチンを登録しておき、
    前記被呼出ルーチンは少なくとも、対象のデバイスを設定して動作させる処理を前記デバイスインタフェース部に実行させるデバイス設定ルーチンを含み、
    前記他のＯＳの前記タスクインタフェース部が、前記タスクからデバイスアクセス要求があった場合に、前記他のＯＳのデバイスドライバ間通信部を呼び出し、呼び出された前記他のＯＳのデバイスドライバ間通信部が、前記デバイス設定ルーチンの識別子と、前記デバイス設定ルーチンに渡す引数とをＯＳ間共有メモリ領域に格納した上で、マルチプロセッサシステムのプロセッサ間割り込み機構を用いて前記特定のＯＳのデバイスドライバ間通信部に通知し、
    前記特定のＯＳの割り込みハンドラは、前記プロセッサ間割り込みを受けて前記デバイスドライバ間通信部を呼び出し、前記デバイスドライバ間通信部は、ＯＳ間共有メモリ領域から前記デバイス設定ルーチンの識別子と前記デバイス設定ルーチンに渡す引数とを読み出し、それに基づいて前記デバイス設定ルーチンを呼び出し、前記デバイスを設定する
    ことを特徴とするＯＳ間デバイス共有方法。
12. 前記デバイスインタフェース部は、前記デバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項１１に記載のＯＳ間デバイス共有方法。
13. 前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
    前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項１１に記載のＯＳ間デバイス共有方法。

Images