JP4072271B2 - 複数のオペレーティングシステムを実行する計算機 - Google Patents
複数のオペレーティングシステムを実行する計算機 Download PDFInfo
- Publication number
- JP4072271B2 JP4072271B2 JP04103299A JP4103299A JP4072271B2 JP 4072271 B2 JP4072271 B2 JP 4072271B2 JP 04103299 A JP04103299 A JP 04103299A JP 4103299 A JP4103299 A JP 4103299A JP 4072271 B2 JP4072271 B2 JP 4072271B2
- Authority
- JP
- Japan
- Prior art keywords
- priority
- operating system
- interrupt
- thread
- common
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Executing Machine-Instructions (AREA)
- Debugging And Monitoring (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
- Document Processing Apparatus (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は複数個のオペレーティングシステムを切り替えつつ動作させる計算機およびそのオペレーティングシステム切り替え方式を対象分野とし、特に、相異なる優先順位体系を有するオペレーティングシステムの切替え方式に関連する。
【０００２】
【従来の技術】
一つの計算機で複数のオペレーティングシステムを動作させる技術として、従来から大型計算機において、「仮想計算機(Virtual Machine：ＶＭ）」が知られている。該従来技術では、計算機内で並行して動作する複数個の仮想計算機それぞれの上で複数のユーザタスク（以降、プロセスおよびスレッドを統一してタスクと呼ぶ）を切り替えて処理を実行する。仮想計算機は、通常、大型計算機内の一つのプロセスとして実現されるが、仮想計算機とユーザタスクとの関連を考慮すると、一つのオペレーティングシステムであると見なすことも可能である。
【０００３】
一般に、それぞれの仮想計算機には、該仮想計算機の優先順位にしたがって一定のタイムスライス（ＣＰＵ割当て時間）を与える。各仮想計算機は、与えられたタイムスライスの範囲内でユーザタスクを切り替えて動作させる。このような仮想計算機技術の実行効率を高める技術として、特開平5−197577 号に開示された「仮想計算機における仮想計算機実行プライオリティ制御方式」がある。
【０００４】
該従来技術は、複数の仮想計算機と、該複数の仮想計算機を制御するための仮想計算機モニタとから構成される。仮想計算機は、システムタスクのように実行優先順位の高いタスクの実行開始・実行終了時に、仮想計算機モニタに対してタスクの優先順位を通知する。これを受けた仮想計算機モニタは、仮想計算機の実行優先順位を、通知された優先順位に変更する。仮想計算機の実行優先順位を仮想計算機内で実行されるタスクの優先順位に変更することにより、仮想計算機制御を効率的に行うことができるとしている。
【０００５】
【発明が解決しようとする課題】
マイクロプロセッサ、特に、組込み向けマイクロプロセッサの性能向上と、オペレーティングシステムの機能向上に伴って、複数個の相違なるオペレーティングシステムを一つの計算機上で同時に動作させ、これらを動的に切り替えて処理を行うというユーザニーズが現われている。
【０００６】
一般に、工場・プラントなどの機械制御，車載ナビゲーションシステムといった分野では、外部環境変化に対して即座に応答するというリアルタイム性，長時間連続運転を可能とする信頼性などが重要視されている。このため、割込み応答性が高く、かつ、コンパクトでモジュール構成を有するリアルタイム用オペレーティングシステム（リアルタイムＯＳ）が用いられることが多い。しかしながら、リアルタイムＯＳは、リアルタイム性・信頼性を重要視する反面、人間とのインタフェースに優れているとは言い難い。
【０００７】
一方、一般のパソコン（ＰＣ）に用いられている事務処理用オペレーティングシステム（事務処理ＯＳ）は、画像を用いて操作を行えるようにするなど、対人間インタフェースに優れている。このため、従来はリアルタイムＯＳを使用していた分野にも事務処理ＯＳのユーザインタフェースを使用したいという要求が高まっている。しかし、事務処理ＯＳは人間との対話を主な処理としているため、割込み応答性よりも処理のスループットを重要視し、比較的長時間割込み禁止状態のまま処理を実行することもある。また、コンパクトな構成を有するリアルタイムＯＳに対し、信頼性において匹敵するとは言い難く、２４時間連続運転などに向いていないという側面もある。
【０００８】
しかしながら、大型計算機上で複数の仮想計算機(オペレーティングシステム)を並行して動作させる方式と同様に、同一計算機上で事務処理ＯＳとリアルタイムＯＳとを動作させ、必要に応じてこれらのオペレーティングシステムを切り替えることができれば、優れたユーザインタフェースとリアルタイム性・信頼性とを両立させることができる。マイクロプロセッサの性能向上を考慮すれば、複数のオペレーティングシステムを一つの計算機上で動作させることは、大型計算機だけに許された技術ではなくなってきている。
【０００９】
このとき、それぞれのオペレーティングシステムの重要性を考慮すると、常にリアルタイムＯＳを優先的に動作させ、リアルタイムＯＳ上で実行させるタスクが存在しなくなった場合にのみ、事務処理ＯＳを動作させるという方法が最も単純なオペレーティングシステム切替え方式である。しかしながら、各オペレーティングシステム上で動作する個々のタスクの重要性が、このように（リアルタイムＯＳ上のタスクは、常に、事務処理ＯＳ上のタスクよりも重要性が高いというように）単純に切り分けられるとは限らない。
【００１０】
図２７に単純な切り分けを行えない例を示す。図２７は車載ナビゲーションシステムの構成例を示したものである。ここでは、システムを簡略化し、車載ナビゲーションシステムが、（１）運転位置を認識する位置認識タスク３７０，(２)目標地点までの最短経路を導出する経路探索タスク３７１，（３）ボタン・タッチパネルなどからの入力を処理するインタフェースタスク３７２，（４）運転休憩中に起動していたゲームタスク３７３、という四つのタスクから構成されていると仮定する。通常、高速応答性・信頼性が求められる位置認識タスク・経路探索タスクはリアルタイムＯＳ１１１上で実行され、ユーザインタフェースに優れた事務処理ＯＳ１１０では、インタフェースタスク・ゲームタスクなどを実行する。しかしながら、一般に、経路探索は非常に計算量の大きい処理であり、数秒オーダの計算時間を要することもある。上記に示した単純な重要性の切り分けを行うと、この間、インタフェースタスクの処理は停止し、ユーザがいくらボタンを押しても認識されないという問題が発生する。
【００１１】
図２７に示した車載ナビゲーションシステムではインタフェースタスクの重要性が高く、これが実行可能状態に移行した場合には、事務処理ＯＳを優先的に実行する必要がある。しかしながら、前記従来技術「仮想計算機における仮想計算機実行プライオリティ制御方式」は、各仮想計算機(オペレーティングシステム)の機能が同一であることを前提としている。一般に、リアルタイムＯＳは環境変化に高速に応答するため、事務処理ＯＳに比べて極めて多くの優先順位レベルを有することが多い。また、極端な場合、リアルタイムＯＳ上では、優先順位の「数値」が小さい（０に近い）ほど優先順位が高く、事務処理ＯＳ上では、優先順位の「数値」が大きいほど優先順位が高い、といった逆の意味付けがなされていることもある。このような場合、たとえ二つのオペレーティングシステムから優先順位を通知されても、いずれのオペレーティングシステムを優先的に起動してよいか判断できないことになる。このため、前記従来技術では、異なった機能を有する事務処理ＯＳとリアルタイムＯＳとを統一して管理することはできない。
【００１２】
本発明の目的は、複数の相異なるオペレーティングシステムを一つの計算機上で動作させるマルチオペレーティングシステム制御装置において、各オペレーティングシステム上で実行されているタスクの重要性を考慮して、動作させるべきオペレーティングシステムを選択・切り替えることであり、これによって、重要性のあるタスクが優先的に実行されるようにすることである。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明では、複数のタスクをそれぞれのタスクに割当てられた優先順位にしたがって実行する複数のオペレーティングシステムと、この複数のオペレーティングシステムを切り替えて実行する計算機において、下記に示す処理を行う。
【００１４】
（１）各オペレーティングシステムが実行しているタスクの優先順位を確認する優先順位監視処理を行う。若しくは、各オペレーティングシステム内に、自分が実行しているタスクの優先順位を通知する優先順位通知処理を行う。事務処理ＯＳ，リアルタイムＯＳでは、内部に優先順位通知処理を追加することが不
可能なこともある。このとき、前者の優先順位監視処理行う必要がある。
【００１５】
（２）各オペレーティングシステムから入手した実行中タスクの優先順位を、それぞれのオペレーティングシステムで共通の優先順位に変換する優先順位変換処理を行う(以降、該共通の優先順位のことを「正規化優先順位」と呼ぶ。)。（３）優先順位変換処理によって得られた各オペレーティングシステムの正規化優先順位を比較して、動作させるべきオペレーティングシステムを決定し、かつ、オペレーティングシステムの切り替えを実行する優先順位比較処理を行う。
【００１６】
本発明によれば、優先順位通知処理は各オペレーティングシステム内に設けられ、オペレーティングシステムがタスク切り替えを行うたびに、該タスクの優先順位を通知する。
【００１７】
タスク切り替え機能はオペレーティングシステムの中核を構成するものであるため、市販されているオペレーティングシステム内に優先順位通知手段を組込むことが不可能なことも多い。しかしながら、一般に、オペレーティングシステムは実行中タスクの管理情報を計算機のメモリ上に保持し、この管理情報の一部にタスクの実行優先順位がある。また、タスク切り替え処理を高速化するため、現在実行中のタスクの優先順位を特定の変数（優先順位保持変数）に格納しておく場合もある。優先順位監視処理は、タスク管理情報または優先順位保持変数を読み出して、各オペレーティングシステムが実行しているタスクの優先順位を確認する。優先順位監視処理は、外部割込み，タイマ割込みなどのタイミングで優先順位の確認を行う。
【００１８】
優先順位変換処理は、各オペレーティングシステムから入手した実行中タスクの優先順位を、計算機内で共通の正規化優先順位に変換する。このため、優先順位変換処理は、各オペレーティングシステムに対応する優先順位変換テーブルを有することがある。優先順位変換テーブルは、各オペレーティングシステム固有の優先順位から正規化優先順位を取り出すための対応表である。簡単な数式によって個々のオペレーティングシステムの優先順位を正規化優先順位に変換することも可能であるが、高速かつ柔軟なオペレーティングシステム切り替えを実行するためには、優先順位変換テーブルを用いるほうがよい。例えば、優先順位変換テーブルに格納する正規化優先順位の値を適切に定めることにより、個々のオペレーティングシステムから得られる正規化優先順位が互いに等しくならないように変換を行うことも可能である。
【００１９】
優先順位比較処理は、各オペレーティングシステムの正規化優先順位を優先順位変換処理から入手し、現在動作させているオペレーティングシステムより高い正規化優先順位を有するオペレーティングシステムが存在すれば、オペレーティングシステムの切り替えを行う。
【００２０】
【発明の実施の形態】
本発明の実施例を図面を用いて説明する。
【００２１】
図１に本発明の第一の実施例における全体構成を示す。通常、計算機は、プロセッサ１００，メモリ１０１，入出力制御装置１０２，ディスク装置１０４，ディスプレイ１０５などから構成される。プロセッサ１００，メモリ１０１，入出力制御装置１０２はプロセッサバス１０３によって接続される。プロセッサ100は複数個のオペレーティングシステムを動作させるためのマイクロプロセッサである。メモリ１０１は、オペレーティングシステムである事務処理ＯＳ１１０，リアルタイムＯＳ１１１，各オペレーティングシステム上で動作するタスク112〜１１７，オペレーティングシステム切り替えプログラム１１８を記憶する。これらのプログラムはプロセッサ１００によって読み出されて実行される。
【００２２】
入出力制御装置１０２には、プログラム・データを保存するためのディスク装置１０４，画面表示用デバイスであるディスプレイ１０５が接続される。また、工場・プラント制御用、あるいは、組込み向け計算機を実現する場合、入出力制御装置１０２には、リアルタイム制御ネットワーク１０６が接続されることがある。リアルタイム制御ネットワーク１０６には、センサ，アクチュエータなどの入出力機器が接続される。なお、入出力制御装置１０２に接続されるディスク装置１０４，ディスプレイ１０５，リアルタイム制御ネットワーク１０６の入出力装置１０４〜１０６のうち、いずれかまたは全ては、システム構成によって省略されることもある。入出力制御装置１０２は、割込み信号線１０７によってプロセッサ１００と接続され、入出力動作完了などを通知することができる。図１中では、説明のため、割込み信号線１０７とプロセッサバス１０３が別の装置であるように記載しているが、実際には、割込み信号線１０７はプロセッサバス103の一部である。プロセッサ１００内部にはタイマ装置１０８が設けられており、一定周期毎に内部割込みを発生させる。タイマ装置１０８からの割込みは、オペレーティングシステムの計時などに使用される。
【００２３】
プロセッサ１００は割込み信号線１０７によって通知される外部割込みやタイマ装置１０８などからの内部割込みをマスクできる機能を装備する。割込みマスクとは、プログラムが割込みマスクを解除するまで、特定の割込みが入ることを遅延させる機能である。一般に、割込みマスク機能には、下記の三種類が存在する。
【００２４】
（１）全割込みマスク：全ての割込みをマスクする。
【００２５】
（２）個別割込みマスク：個々の割込みをそれぞれマスクできるようにする。
【００２６】
（３）割込みレベルマスク：各割込みにレベルを設定し、指定レベル以下の割込みをマスクする。
【００２７】
プロセッサ１００の種類によって、上記（１）（２）の組合せ、または、(１)（３）の組合せのいずれかで構成することが多い。後者の組合せで構成するプロセッサを採用する場合、対応する入出力装置の重要性にしたがって割込みレベルを割当てることになる。例えば、リアルタイム制御ネットワーク１０６からの割込みを、ディスク装置１０４，ディスプレイ１０５などからの割込みより高いレベルに設定する。
【００２８】
本実施例では、計算機内に二つのオペレーティングシステムである事務処理ＯＳ１１０，リアルタイムＯＳ１１１が存在する。このオペレーティングシステムは、各自に割当てられたメモリ・プロセッサ資源を用い、それぞれ、タスク１１２〜１１４，タスク１１５〜１１７を実行させる。ここでは、オペレーティングシステム数が２個、タスク数が６個（各オペレーティングシステムに対して３個ずつ）の例を示しているが、これらの数値よりも多い、または、少ないオペレーティングシステム，タスクを実装することも可能である。本実施例では、オペレーティングシステム数の動的な変更は想定しないが、各オペレーティングシステムが動的にタスク生成・削除を行うことは可能である。また、本実施例では、事務処理ＯＳ１１０，リアルタイムＯＳ１１１について説明するが、実際に、各オペレーティングシステムがいかなる種類であっても、本発明で述べる技術は適用可能である。タスク１１２〜１１４は事務処理ＯＳで実行される事務処理タスクであり、タスク１１５〜１１７はリアルタイムＯＳで実行されるリアルタイムタスクである。事務処理ＯＳ１１０とリアルタイムＯＳ１１１は、各々独立にタスクの優先順位を定義している。図１に示す実施例では、事務処理ＯＳ１１０環境下で、タスク１１２〜１１４が、それぞれ、優先順位０，７，３１を有し、リアルタイムＯＳ１１１環境下で、タスク１１５〜１１７が、それぞれ、優先順位０，９９，２５５を有する。尚、本実施例においてタスクとはプロセス又はスレッドの総称を意味する。プロセスとは、個別のメモリ空間を有して動作するプログラムを意味する。このため、通常あるプロセスは別のプロセスのデータを変更することはできない。スレッドとは、プロセスのメモリ空間を共有して動作するプログラムを指す。従って、同一プロセス内で動作するスレッド同士の間ではデータ保護機能は存在しない。
【００２９】
各オペレーティングシステム内には、優先順位通知モジュール１２０，１２１が存在する。優先順位通知モジュール１２０，１２１は、各オペレーティングシステムのタスク切り替え時に実行され、オペレーティングシステム切り替えプログラム１１８に対して次に実行すべきタスクの優先順位を通知する。
【００３０】
一般に、事務処理ＯＳとリアルタイムＯＳとは異なった優先順位体系を有することが多い。リアルタイムＯＳでは、比較的多くの優先順位レベルを有することにより、重要な割込みに対する高速応答性を実現する。一方、事務処理ＯＳでは、比較的少ない優先順位レベルを用いて、スループットを向上させる方式を採用する。また、オペレーティングシステムの種類によっては、優先順位の数値が小さい（０に近い）ほど優先順位が高い場合と、優先順位の数値が大きいほど優先順位が高い場合とがある。このため、優先順位通知モジュール１２０，１２１から得られた優先順位をそのまま比較しても意味がない。なお、以降、事務処理ＯＳ１１０では、優先順位の数値が大きいほどタスクの優先順位が高く（図１中では、タスク１１４が最も優先される）、リアルタイムＯＳ１１１では、逆に、優先順位の数値が小さいほどタスクの優先順位が高い（図１中では、タスク115が最も優先される）ものとして説明する。また、事務処理ＯＳ１１０における優先順位は０〜３１の範囲で指定でき、リアルタイムＯＳ１１１における優先順位は０〜２５５の範囲で指定できるものとする。
【００３１】
二つのオペレーティングシステムにおける優先順位体系の違いを解消するため、オペレーティングシステム切り替えプログラム１１８は、優先順位変換モジュール１２２，１２３と優先順位比較モジュール１２４とを構成要素として有する。優先順位変換モジュール１２２，１２３は、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１から得られた優先順位をシステム内で共通の比較基準である正規化優先順位に変換する。各オペレーティングシステムの優先順位をそのまま比較することは不可能であるが、一旦両者を正規化優先順位に変換すれば、両オペレーティングシステムが実行しているタスクの優先順位を比較することができる。なお、ここで、正規化優先順位が一方のオペレーティングシステムの優先順位と全く同一であってもよい。この場合、当該オペレーティングシステムの優先順位がそのまま正規化優先順位となる。優先順位比較モジュール１２４は、両オペレーティングシステムから得られた正規化優先順位を比較し、かつ、より高い正規化優先順位を有するオペレーティングシステムに切り替えて実行させる役割を有する。
【００３２】
図２に、プロセッサ１００の内部構成例を示す。キャッシュメモリ１３１はメモリ１０１上のデータまたは命令を一時的に格納するバッファ記憶装置である。CPU130は演算回路であり、メモリ１０１若しくはキャッシュメモリ１３１上に存在する命令を順次読み出して実行する。命令実行に際して、演算結果を一時的に保持するための汎用レジスタ１３２，命令アドレスを指定するプログラムカウンタ１３３，実行状態を保持するステータスレジスタ１３４を用いる。CPU130，キャッシュメモリ１３１，汎用レジスタ１３２，プログラムカウンタ１３３，ステータスレジスタ１３４は、互いに、データ転送を行う複数の信号線であるデータバス１３６，アドレス指定を行う複数の信号線であるアドレスバス１３７によって接続されている。
【００３３】
割込み信号線１０７とタイマ装置１０８は割込みコントローラ１３５に接続される。割込みコントローラ１３５は、CPU130に対して割込み状態信号１３８を生成する役割を有する。割込み状態信号１３８は、プロセッサ１００に対して現在如何なる種類の割込みが発生しているかを示す信号である。通常、ステータスレジスタ１３４は現在の割込みマスクに関する情報を有しており、割込み状態信号１３８で指定される割込みを受け付けるか否かを決定する。割込みを受け付ける場合、割込みコントローラ１３５は、プログラムカウンタ１３３，ステータスレジスタ１３４などの値を書き替え、対応する割込み処理プログラムを実行させる。
【００３４】
ステータスレジスタ１３４の構成を図３に示す。ここでは、プロセッサ１００が全割込みマスク機能と割込みレベルマスク機能とを装備している場合を示している。図３では、ステータスレジスタ１３４が割込みブロックビット１４０と割込みマスクレベルフィールド１４１を有する。割込みブロックビット１４０がＯＮである場合、プロセッサ１００に対する全ての割込みがマスクされる。割込みマスクレベルフィールド１４１は現在の割込みマスクレベル値を示し、これ以下の割込みレベルは受け付けられない。図３では、割込みマスクレベルフィールド１４１は４ビット長である。このため、合計１６種類のマスクレベルを指定可能であるが（通常、割込みレベル０は「割込みが発生していない」ことを意味し、割込みマスクレベルを０とすることは「割込みマスクを行わない」ことを意味するため、実質的には１５種類となる）、割込みマスクレベルフィールド１４１のビット数を変更することにより、受理できる割込みレベルの種類を増減させることができる。
【００３５】
図４は、プロセッサ１００が全割込みマスク機能と個別割込みマスク機能とを装備している場合のステータスレジスタ１３４の構成を示したものである。この例では、ステータスレジスタ１３４は実際には二つのレジスタ（実行状態レジスタ１４２と割込みマスクレジスタ１４３）から構成される。図３と同様、実行状態レジスタ１４２内に割込みブロックビット１４０が設けられている。割込みマスクレジスタ１４３内の割込みマスクビット１４４〜１４７はそれぞれ別々の割込みに対応しており、この割込みマスクビットのいずれかをＯＮとした場合、対応する割込みが受け付けられなくなる。図３に示すステータスレジスタは、図４のステータスレジスタの特殊なものである。例えば、割込みマスクビット１４４のみＯＮとなっている状態をレベル１とし、割込みマスクビット１４４，１４５の二つがＯＮとなっている状態をレベル２、割込みマスクビット１４４〜１４６の三つがＯＮとなっている状態をレベル３，…、のように対応させることができる。このため、以降、ステータスレジスタ１３４は図４に示す構成として、本発明の説明を行う。
【００３６】
一般的なプロセッサでは、割込みを受理すると、ハードウェアによって自動的に割込みブロックビット１４０がＯＮに書き替えられ、プログラムカウンタ133に割込み処理プログラムのアドレスが格納される。必要に応じて、割込み処理プログラムが割込みブロックビット１４０をＯＦＦに書き替えて割込み受け付けを許可することができる。また、オペレーティングシステムおよびタスクが、一時的に割込みブロックビット１４０や割込みマスクレジスタ１４３の内容を書き替え、特定割込みの受け付けを待たせることもできる。割込みマスク機能は、排他制御の実現や、割込み処理実行中に再び同一割込みが発生することを避けるために用いられる。
【００３７】
次に、このようなハードウェア上に実現される本発明のソフトウェア構成について説明する。図５に、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の内部構成を示した。図中、全てのコンポーネントはメモリ１０１上に格納されている。事務処理ＯＳ，リアルタイムＯＳとも、実行可能タスクの情報を待ち行列１５０，１５１の形で管理する。実行可能待ち行列１５０，１５１は優先順位毎に設けられる場合もあるが、本実施例では、全ての実行可能なタスクが一つの待ち行列によって管理される。なお、実行可能待ち行列が一つであっても、優先順位毎に設けられていても、本発明の内容には影響を与えない。各タスクは、（ａ）実行状態、（ｂ）実行可能状態、（ｃ）待ち状態の三種の状態を順次とるのでオペレーティングシステムは、実行可能タスク以外に、待ち状態タスク，停止状態タスクなどを別の待ち行列で管理する。尚、図５ではこれらの待ち行列の記載を省略している。実行可能待ち行列１５０および１５１によって管理されるタスク管理テーブル１６０〜１６５は、実行すべきタスクの優先順位，タスク実行時のプログラムカウンタ・ステータスレジスタ・汎用レジスタの値などを保存する。
【００３８】
実行可能タスクを一つの待ち行列で管理する場合、実行可能待ち行列に登録されるタスク管理テーブルは優先順位の高い順に配置される。すなわち、次に実行すべきタスクの管理テーブルが待ち行列の先頭に来るように構成する。前述したように、本実施例で述べる事務処理ＯＳ１１０は、０〜３１までの優先順位を有し、優先順位の数値が大きいほど優先順位が高い。また、リアルタイムOS111 は、０〜２５５までの優先順位を有し、優先順位の数値が小さいほど優先順位が高い。このため、事務処理ＯＳでは、タスク１１４（優先順位「３１」）に対応する管理テーブル１６２が実行可能待ち行列１５０の先頭に配置され、以下、タスク１１３（優先順位「７」）の管理テーブル１６１，タスク１１２（優先順位「０」）の管理テーブル１６０の順に配置される。逆に、リアルタイムＯＳでは、タスク１１５（優先順位「０」）に対応する管理テーブル１６３が実行可能待ち行列１５１の先頭に配置され、次に、タスク１１６（優先順位「９９」）の管理テーブル１６４，タスク１１７（優先順位「２５５」）の管理テーブル１６５の順に配置される。
【００３９】
各オペレーティングシステムは、また、割込み処理を行う割込みハンドラ152,１５３，タスクに対してサービスを提供するシステムコールプログラム１５６，１５７、および、タスク切り替えを行うリスケジューラ１５４，１５５を有する。タスクの生成・削除・停止・再開や、外部割込み・内部割込み発生に伴ってタスク切り替えを行わなければならない場合、リスケジューラ１５４，１５５が起動される。リスケジューラ１５４，１５５は、直前に実行していたタスクの実行環境（レジスタなど）をタスク管理テーブルに格納した後に呼び出され、新たに実行すべきタスク決定して、その実行環境をタスク管理テーブルから取り出す。これをプログラムカウンタ，ステータスレジスタ，汎用レジスタなどに設定することにより、選択したタスクを実行する。
【００４０】
リスケジューラ１５４，１５５は、その内部に優先順位通知モジュール１２０，１２１を有する。優先順位通知モジュール１２０，１２１は、新たに実行すべきタスクの実行環境をレジスタに設定する直前に起動され、タスクの優先順位をオペレーティングシステム切り替えプログラム１１８内の優先順位変換モジュール１２２，１２３に通知する。
【００４１】
図６には、オペレーティングシステム切り替えプログラム１１８の内部構成を示したものである。優先順位変換モジュール１２２，１２３は、各オペレーティングシステムでの優先順位を正規化優先順位に変更するため、優先順位変換テーブル１７０，１７１をそれぞれ所有する。正規化優先順位は、本実施例では、０〜２５５の範囲の整数であり、「正規化優先順位の数値が大きいほど、正規化優先順位が高い」と定義する。勿論、正規化優先順位の数値の範囲を変更したり、「正規化優先順位の数値が小さいほど、正規化優先順位が高い」と定義することも可能である。
【００４２】
前述したように、事務処理ＯＳ１１０は０〜３１までの優先順位を有している。このとき、優先順位変換テーブル１７０は、３２個のエントリを有する配列となる。各配列要素は０〜２５５の範囲の整数を有し、かつ、以下の不等式を満足する（ここでは、配列の名称をprioBusinessとする）。
【００４３】
ｉ＞ｊ⇔prioBusiness［ｉ］＞prioBusiness［ｊ］
（ただし、０≦ｉ，ｊ≦３１）
事務処理ＯＳ１１０の優先順位、および、正規化優先順位ともに、数値が大きいほど優先順位が高いとしているため、この条件が成立する必要がある。
【００４４】
同様に、リアルタイムＯＳ１１１が０〜２５５までの優先順位を有している場合、優先順位変換テーブル１７１は、２５６個のエントリを有する配列となる。各配列要素は０〜２５５の範囲の整数を有し、かつ、以下の不等式を満足する
（配列の名称をprioRealtimeとする）。
【００４５】
ｉ＞ｊ⇔prioRealtime［ｉ］＜prioRealtime［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
事務処理ＯＳと不等号の向きが異なる理由は、リアルタイムＯＳでは、優先順位の数値が小さいほど優先順位が高いとしているためである。
【００４６】
図６では、事務処理ＯＳ１１０上でタスク１１４が次に実行可能であると判定された場合、優先順位通知モジュール１２０から優先順位の数値「３１」が通知される。優先順位変換モジュール１２２は、優先順位変換テーブル１７０を利用し、正規化優先順位の数値「１２４」を入手することができる。逆に、リアルタイムＯＳ１１１上でタスク１１５が次に実行可能となった場合、優先順位通知モジュール１２１からリアルタイムＯＳでの優先順位の数値「０」が通知される。優先順位変換モジュール１２３は、優先順位変換テーブル１７１を使用して、正規化優先順位の数値「２５５」を入手する。ここで、本実施例では、事務処理ＯＳ１１０のタスクの優先順位がいくら高くても、正規化優先順位の数値が「１２４」を越えないことに注意する必要がある。これは、優先順位変換テーブルの設定方法の極端な例であり、リアルタイムＯＳ上のタスクをできる限り優先して実行させるという目的のためのものである（リアルタイムＯＳ上のタスクでも、優先順位が低いものに対しては、事務処理ＯＳ上のタスクが優先することがある）。しかし、勿論、二つのオペレーティングシステムの優先順位ができるだけ対等に正規化優先順位に変換されるように、優先順位変換テーブル１７０の構成を変更することも可能である。
【００４７】
優先順位変換モジュール１２２，１２３が変換した正規化優先順位は、いずれも、優先順位比較モジュール１２４に通知される。優先順位比較モジュール124は、通知された事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３とを保持する。この場合、事務処理ＯＳ正規化優先順位１７２の数値は「１２４」であり、リアルタイムＯＳ正規化優先順位１７３の数値は「255」である。
【００４８】
前述したように、優先順位通知モジュール１２０，１２１はリスケジューラ内に存在し、タスク切り替え時に実行される。タスク切り替えから次のタスク切り替えまでの期間は一つのタスクしか実行されないため、タスクの優先順位が動的に変化しない限り、この間、当該オペレーティングシステムに対する正規化優先順位も変化しない。優先順位通知モジュール１２０，１２１は、タスク切り替え時に必ず優先順位を通知してくるため、優先順位比較モジュール１２４内に保持している事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３が、実際の各オペレーティングシステムでのタスクの優先順位を反映した数値となる。
【００４９】
優先順位比較モジュール１２４は、保持している各オペレーティングシステムの正規化優先順位１７２，１７３の数値を相互に比較して、より高い正規化優先順位を有するオペレーティングシステムを優先的に実行させる。図６の例では、より高い正規化優先順位を有するリアルタイムＯＳ１１１を実行させることになる。
【００５０】
オペレーティングシステム切り替えプログラム１１８は、優先順位変換モジュール１２２，１２３，優先順位比較モジュール１２４の他に、発生した割込みを各オペレーティングシステムに振り分ける共通割込みハンドラ１７４，オペレーティングシステム間での協調処理を実行するＯＳ間通信機能モジュール１７５，二つのオペレーティングシステムの実行環境切り替えを行うＯＳコンテクスト切り替えモジュール１７６，タスクの優先順位によって割込みマスクを変更する割込みマスクレベル計算モジュール１７７を有する。このプログラムの詳細は後述する。
【００５１】
図７に事務処理ＯＳ１１０におけるリスケジューラ１５４の処理フローを示した。リアルタイムＯＳ１１１のリスケジューラ１５５も同様の処理を行う。リスケジューラ１５４は、一般に、（１）タイマ割込み処理終了時、（２）外部割込み処理終了時、（３）システムコール実行時などにおいて、現在実行中のタスクが実行可能でなくなるか、実行中タスクより高い優先順位のタスクが実行可能となった場合、実行中タスクのレジスタをタスク管理テーブルに退避した後に起動されるモジュールである。リスケジューラ１５４を起動する可能性のあるシステムコールには、（ａ）タスクの生成・終了・停止・再開（例えば、自分より優先順位の高いタスクを生成した場合）、（ｂ）排他制御の実行・終了（排他制御待ち状態に移行した場合など）に加え、（ｃ）タスクの優先順位変更（自己の優先順位を低下させた場合など）、といったものがある。
【００５２】
リスケジューラ１５４は、第一に、実行可能待ち行列１５０から最高優先順位のタスク管理テーブルを取り出す（処理１８１）。ここで、全てのタスクが待ち状態や停止状態となっていて、実行可能タスクが存在しないこともある。これを処理１８２で判定する。
【００５３】
実行可能タスクが存在しなければ、優先順位変換モジュール１２２にidle状態であることを通知する（処理１８４）。このとき、実行可能タスクが存在しないのであるから、idleループへ移行する（処理１８６）。idleループとは、実行すべき処理が現れるまで何も行わないプログラムである。ここで注意すべきことは、処理１８４において、優先順位変換モジュール１２２に対してidle状態を通知したことである。事務処理ＯＳ１１０がidle状態であれば、優先順位比較モジュール１２４はリアルタイムＯＳ１１１を優先して実行させる。したがって、両オペレーティングシステムが同時にidle状態に移行した場合を除いて、実際に処理１８６でidleループが実行されることはない。再び事務処理ＯＳ１１０が実行される場合には、何らかの実行すべき処理が存在するのであるから、直ちにidleループを抜けて処理１８１に移行することになる。
【００５４】
処理１８２で実行すべきタスクが存在すると判定した場合、次に実行すべきタスクの優先順位をタスク管理テーブルから取り出して、優先順位変換モジュール１２２に通知する。通知した優先順位がリアルタイムＯＳ１１１の優先順位よりも低かった場合（正規化優先順位による比較）、この時点で、リアルタイムＯＳ１１１に切り替えられることになる。リアルタイムＯＳ１１１から逆に事務処理ＯＳ１１０へ切り替えが行われる場合、割込み処理などによって、実行しようとしているタスクが実行可能でなくなったり、更に高い優先順位のタスクが実行可能となったりしない限り、処理１８３の直後から再実行することになる（処理１８１で選択したタスクを起動する）。なお、当然のことながら、現在実行中のタスクが実行可能でなくなるか、実行中タスクより高い優先順位のタスクが実行可能となった場合には、リスケジューラ１５４自体が再起動される。処理185で、タスク管理テーブルからレジスタを復帰してプロセッサ１００のレジスタに登録することにより、選択したタスクの処理を実行する。
【００５５】
ここで、リスケジューラ１５４中、処理１８３，１８４が優先順位通知モジュール１２０に相当する。リスケジューラ１５５内にも同様に優先順位通知モジュール１２１が埋め込まれる。
【００５６】
次に、図８に、事務処理ＯＳ１１０に対応する優先順位変換モジュール１２２の処理フローを示す。優先順位変換モジュール１２２は優先順位通知モジュール１２０から呼び出され、直ちに、優先順位変換処理を実行する。最初に、優先順位通知モジュール１２０がidle状態を通知してきたか否かを判定する（処理190)。idle状態はあらゆる優先順位よりも低い優先順位を有すると見なすこともできるので、ここでは、いずれの正規化優先順位よりも低くなるように、（−１）という正規化優先順位の数値を有していると考える。処理１９３では、この数値（−１）を優先順位比較モジュール１２４に通知する。idle状態でなければ、優先順位変換テーブル１７０から対応するエントリを読み出し（処理１９１）、これを優先順位比較モジュール１２４に通知する（処理１９２）。リアルタイムＯＳ１１１に対応する優先順位変換モジュール１２３の処理も同様である。
【００５７】
図９は優先順位比較モジュール１２４の処理フローである。優先順位比較モジュール１２４は、第一に、事務処理ＯＳ１１０からの正規化優先順位であるか、リアルタイムＯＳ１１１からの正規化優先順位であるかを判定する(処理２００)。事務処理ＯＳ１１０の正規化優先順位であれば、事務処理ＯＳ正規化優先順位１７２に入手した正規化優先順位を格納する（処理２０１）。リアルタイムＯＳ１１１からの正規化優先順位であれば、リアルタイムＯＳ正規化優先順位１７３に当該正規化優先順位を記憶する（処理２０２）。
【００５８】
正規化優先順位が通知されてくるのは、いずれか一方の正規化優先順位が変化した可能性がある場合のみであるため、ここで、事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３の数値を比較する(処理２０３)。本実施例では、正規化優先順位の数値が大きいオペレーティングシステムを優先的に起動するとしている。したがって、事務処理ＯＳ１１０の正規化優先順位の数値がリアルタイムＯＳ１１１の正規化優先順位の数値より大きければ、次に実行すべきオペレーティングシステムを事務処理ＯＳ１１０とする(処理２０４)。これ以外の場合には、次にリアルタイムＯＳ１１１を実行させるものとする(処理２０５)。なお、ここでは、事務処理ＯＳ１１０とリアルタイムＯＳ１１１の正規化優先順位が等しくても、リアルタイムＯＳ１１１を実行させる。これを変更し、正規化優先順位が互いに等しい場合には事務処理ＯＳ１１０を実行させるとしても問題はない。また、優先順位変換テーブル１７０，１７１の内容を設定するにあたって、各オペレーティングシステムから得られる正規化優先順位が互いに等しくならないようにすることも、システムを単純化させるための一つの方法である。
【００５９】
次に処理２０６で、新たに実行すべきオペレーティングシステムが今まで実行していたオペレーティングシステムに等しいか否かを判定する。今までと異なったオペレーティングシステムを実行させる場合、ＯＳコンテクスト切り替えモジュール１７６に依頼して、オペレーティングシステム実行環境の退避・復帰を行わせる（処理２０７）。
【００６０】
図１０に割込みハンドラ１５２，１５３，共通割込みハンドラ１７４，ＯＳ間通信機能モジュール１７５，ＯＳコンテクスト切り替えモジュール１７６の詳細を示す（割込みマスクレベル計算モジュール１７７については、別の図面で詳細を説明する）。
【００６１】
割込みハンドラ１５２，１５３は、割込み発生時のレジスタなどの保存、一時変数の保持を行うための領域として、それぞれ、割込みスタック２１４，２１５を所有する。割込み発生時には、割込み発生直前のレジスタ値を保存し、このレジスタ値を割込み処理終了後に復帰してやらなければならない。このため、割込みスタック２１４，２１５が必要とされる。使用するプロセッサ１００の種類によっては、割込み発生時に自動的にレジスタが切り替わり、かつ、割込み処理終了後に切り替え前のレジスタに戻す機能を備えているものもある。しかしながら、多重割込みが可能なシステムを考慮した場合には、このようなハードウェアを使用していても、割込みスタックが必要となる（割込み処理中により高い緊急性を有する割込みが発生した場合、新たに発生した割込み処理を優先的に実行し、次いで、元の割込み処理に戻る必要がある）。
【００６２】
割込みハンドラ１５２，１５３は、更に、割込みスタック２１４，２１５中、どの領域まで使用したかを示すためのポインタとして、割込みスタックポインタ２１６，２１７を所有する。割込みハンドラ１５２，１５３は、割込みスタック、および、割込みスタックポインタを用いて割込み発生前の実行環境（レジスタなど）を保存し、必要な割込み処理を実行する。割込み処理終了後、割込み発生前の実行環境を復帰して元々動作していたプログラムの実行を継続させる。
【００６３】
共通割込みハンドラ１７４は、発生した割込みを割込みハンドラ１５２，153に対して振り分ける役割を有する。このため、共通割込みハンドラ１７４は、現在実行しているオペレーティングシステムが事務処理ＯＳ１１０であるかリアルタイムＯＳ１１１であるかを記憶する領域として、実行ＯＳ記憶変数２１０を所有する。例えば、図１０に示した時点で事務処理ＯＳが処理を実行しているものと仮定すると、この場合、実行ＯＳ記憶変数２１０には、「事務処理ＯＳ」が記憶されている。勿論、実行ＯＳ記憶変数２１０が文字列「事務処理ＯＳ」を記憶することは非常に非効率的であるため、例えば、
・事務処理ＯＳ→０
・リアルタイムＯＳ→１
といった整数形式で記憶するとよい。共通割込みハンドラ１７４は、更に、発生した割込みがいずれのオペレーティングシステムに対応するかを示す割込み対応テーブル２１１を有する。割込み対応テーブル２１１は、個々の割込みがどちらのオペレーティングシステムで処理されるべきかを示す対応表である。本実施例では、図４に示したように、３２種類の割込み要因が存在する。このため、割込み対応テーブル２１１も３２個のエントリ(０〜３１)から構成される。図１０の例では、割込み要因０が事務処理ＯＳで、割込み要因１がリアルタイムＯＳで，…，割込み要因３１がリアルタイムＯＳでというように、いずれのオペレーティングシステムで処理が実行されるべきかが定義されている。なお、効率上、割込み対応テーブル２１１の内容も、実行ＯＳ記憶変数２１０と同様、文字列形式ではなく、整数形式で記憶すべきである。
【００６４】
さて、計算機の種類によっては、一つの入出力機器を二つのオペレーティングシステムが共用することもある（例えば、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の両者がディスプレイに文字や映像を出力する場合）。このようなシステムを実現するためには、割込み振り分け先のオペレーティングシステムを動的に変更できることが必要となる。本実施例で、振り分け先オペレーティングシステムを固定化するのではなく、割込み対応テーブル２１１から入手しているのは、このためである。割込み対応テーブル２１１の内容を入出力機器の使用状況によって変更することにより、割込みの振り分け先を動的に変更することができる。
【００６５】
共通割込みハンドラ１７４は、実行ＯＳ記憶変数２１０を用いて現在実行しているオペレーティングシステムの種類を判定し、これが割込み対応テーブル211から得られた振り分け先オペレーティングシステムに一致しなければ、ＯＳコンテクスト切り替えモジュール１７６に切り替えを依頼する。オペレーティングシステムが一致するか、オペレーティングシステム切り替え終了後、該当するオペレーティングシステムの割込みハンドラに処理を依頼する。なお、実行ＯＳ記憶変数２１０はＯＳコンテクスト切り替えモジュール１７６からも参照される。このように、オペレーティングシステム切り替えプログラム１１８内の各モジュールが有する内部構造は、個々のモジュールによって占有されるものとは限らず、各モジュールが必要に応じて共用できる。
【００６６】
ＯＳコンテクスト切り替えモジュール１７６は、優先順位比較の結果、若しくは、割込み発生の結果、オペレーティングシステムを切り替えなければならない場合に起動される。二つのオペレーティングシステムを切り替えるため、これらの実行環境（すなわち、レジスタ値）を保存しておくための領域を所有しなければならない。ここでは、事務処理ＯＳの実行環境を保存するための領域として、事務処理ＯＳ用保存コンテクスト２１２，リアルタイムＯＳの実行環境を保存するための領域として、リアルタイムＯＳ用保存コンテクスト２１３を用意する。ＯＳコンテクスト切り替えモジュール１７６は、現在実行しているオペレーティングシステムに対応する保存コンテクストに実行環境を保存し、次に、もう一方の保存コンテクストから実行環境を読み出して、プロセッサ１００のレジスタに設定する。これにより、オペレーティングシステムの切り替えを実施できる。
【００６７】
ＯＳ間通信機能モジュール１７５は、二つのオペレーティングシステム上のタスクが相互に通信・協調するためのプログラムである。ここでは、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の両者が使用できる共有メモリ２１８、並びに、オペレーティングシステム間で排他制御を行うためのロック取得モジュール２１９，ロック解放モジュール２２０が存在するとしている。共有メモリ218は、メモリ１０１の一部であり、両オペレーティングシステムから参照を行える領域である。共有メモリ２１８以外のメモリは、基本的に、事務処理ＯＳ用領域，リアルタイムＯＳ用領域，オペレーティングシステム切り替えプログラム用領域に分割され、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１，オペレーティングシステム切り替えプログラム１１８に占有されて使用される。二つのオペレーティングシステム上のタスクが共有メモリ２１８を使用する場合、通常、排他制御を行って共有メモリ２１８上のデータの一貫性を保つ。アプリケーションプログラムがオペレーティングシステム間に跨る排他制御を行う場合、ロック取得モジュール２１９，ロック解放モジュール２２０が提供する機能を利用する。
【００６８】
このとき、優先順位逆転現象と呼ばれる状況について注意しておかなければならない。優先順位逆転現象とは、一般に、以下の状態を意味する。
【００６９】
（１）低優先順位であるタスクαが最初に起動されてロックを取得する。
【００７０】
（２）次に高優先順位であるタスクβが起動されてロック待ち状態に移行する。
（３）次に中優先順位であるタスクγが起動され、タスクα（低優先順位）からタスクγ（中優先順位）への切り替えが行われる。
【００７１】
このとき、タスクγの実行によってタスクαの実行が妨げられ、結果的に、高優先順位タスクβがロックを取得するまでの時間が延びてしまうことになる。優先順位逆転現象は、通常、優先順位上昇方式または優先順位継承方式を用いて解決する。
【００７２】
優先順位上昇方式は、ロック取得を行ったタスクの優先順位を一定のレベルまで高くする方式である。これによって、ロック取得を行ったタスクαの優先順位が一時的にタスクγ（中優先順位）よりも高くなり、タスクγが起動されても、ロック解放まではタスクαが実行される。この後、高優先順位であるタスクβがロックを取得し、処理を継続することになる。
【００７３】
優先順位継承方式は、前記優先順位上昇方式を変更して柔軟性を持たせたものである。優先順位継承方式では、ロック待ち状態に移行したタスク（例では、タスクβ）の優先順位がロックを取得しているタスク（タスクα）よりも高ければ、この優先順位をロック取得中タスクに継承させる方式である。ここでは、ロック取得中の間だけ、タスクαがタスクβの優先順位を受け継ぐことになる。低優先順位のタスク同志で排他制御を行う場合など、必ずしも優先順位を一定レベルまで上昇させる必要がない場合もあり、優先順位継承方式は、このような状況にも対処できる方式である。
【００７４】
本実施例で述べるロック取得モジュール２１９，ロック解放モジュール２２０は、このような優先順位上昇もしくは優先順位継承方式をオペレーティングシステム間で実施できるものとする。オペレーティングシステム間での優先順位上昇・継承は、正規化優先順位を用いて行われる。
【００７５】
以降、図１０で示したモジュールのうち、ＯＳコンテクスト切り替えモジュール１７６，共通割込みハンドラ１７４，割込みハンドラ１５２，ロック取得モジュール２１９，ロック解放モジュール２２０の処理フローの説明を行う。割込みハンドラ１５３に関しては、割込みハンドラ１５２と同様の処理フローを有するため、説明を省略する。
【００７６】
図１１はＯＳコンテクスト切り替えモジュール１７６の処理フローである。
【００７７】
ＯＳコンテクスト切り替えモジュール１７６は、オペレーティングシステムを切り替えなければならない場合にのみ呼び出され、切り替えが必要か否かのチェックは呼出し前に行われている。したがって、最初に、どちらのオペレーティングシステムへ切り替えなければならないかのみをチェックする（処理２３０）。ここで、事務処理ＯＳ１１０からリアルタイムＯＳ１１１への切り替えを行う場合（現実行オペレーティングシステムが事務処理ＯＳ１１０であって、リアルタイムＯＳ１１１の優先順位が高くなった場合）、事務処理ＯＳ用保存コンテクスト２１２内に使用中レジスタの値を退避する（処理２３１）。次に、リアルタイムＯＳ用保存コンテクスト２１３から実行環境を復帰して、レジスタに設定することにより（処理２３２）、以前退避した状態からリアルタイムＯＳ１１１を再実行させることができる。リアルタイムＯＳ１１１から事務処理ＯＳ１１０への切り替えを行う場合、逆に、リアルタイムＯＳ用保存コンテクスト２１３に使用中レジスタの値を退避し（処理２３３）、次に、事務処理ＯＳ用保存コンテクスト２１２からレジスタを復帰する（処理２３４）。いずれの場合においても、最後に、切り替え後のオペレーティングシステムの種類を実行ＯＳ記憶変数２１０に書き込む（処理２３５）。
【００７８】
図１２には、共通割込みハンドラ１７４の処理フローを示している。一般に、単一のオペレーティングシステムによって制御される計算機では、一旦、全ての割込みを割込みハンドラと呼ばれるモジュールが処理し、次いで、各プログラムに振り分ける。しかしながら、本実施例で説明するような複数個のオペレーティングシステムを動作させる計算機では、この更に前に、共通割込みハンドラが全ての割込みを受け付け、これを対応するオペレーティングシステムの割込みハンドラに振り分ける形となる。各オペレーティングシステムに割込みを振り分けるに当たって、割込み発生時に、割込み対象とは別のオペレーティングシステムが処理を実行していることもある。この場合、割込みに対応するオペレーティングシステムに切り替える必要があり、共通割込みハンドラはこのような役割も有することになる。
【００７９】
共通割込みハンドラ１７４は、割込み発生後、第一に、実行ＯＳ記憶変数210の内容を取り出して、現在実行中のオペレーティングシステムが事務処理OS110であるかリアルタイムＯＳ１１１であるかをチェックする（処理２４０）。次に、割込み対応テーブル２１１を用いて、発生した割込みがいずれのオペレーティングシステムに対応しているかを入手する（処理２４１）。例えば、図１０の割込み対応テーブル２１１を用いるとすると、割込み「０」が発生した場合には事務処理ＯＳ１１０，割込み「１」が発生した場合にはリアルタイムＯＳ１１１，…，割込み「３１」が発生した場合にはリアルタイムＯＳ１１１、というように対応するオペレーティングシステムを入手することができる。ここで、割込み対象オペレーティングシステムが実行中オペレーティングシステムに等しいか否かをチェックする（処理２４２）。
【００８０】
発生した割込みが現在実行中のオペレーティングシステムに対するものでなければ、一旦、オペレーティングシステムの切り替えを行わなければならない。この切り替え処理は、ＯＳコンテクスト切り替えモジュール１７６に依頼することによって行う（処理２４３）。次に割込み対象オペレーティングシステムが事務処理ＯＳ１１０であるかリアルタイムＯＳ１１１であるかをチェックし（処理２４４）、対象が事務処理ＯＳ１１０であれば、事務処理ＯＳの割込みハンドラ１５２を起動する（処理２４５）。リアルタイムＯＳ１１１への割込みが発生していれば、リアルタイムＯＳの割込みハンドラ１５３を起動することになる（処理２４６）。一般に、割込みハンドラ１５２，１５３は、割込み処理によってタスク切り替えを行わなければならないとき、リスケジューラ１５４，１５５を呼び出し、共通割込みハンドラ１７４に制御を戻すことはない。しかし、タスク切り替えが発生しない場合、そのまま割込みハンドラの処理を終了する。このとき、割込みハンドラ１５２，１５３は、共通割込みハンドラへ制御を戻し（図１３で後述）、共通割込みハンドラは処理２４７から動作を再開する。処理２４７は、割込み発生時にオペレーティングシステムを切り替えたかどうかをチェックする処理である。処理２４３によってオペレーティングシステムを切り替えた場合、ここで再び、オペレーティングシステムを切り替え、元の実行環境に戻す必要がある。タスク切り替えが発生しないということは、両オペレーティングシステムの正規化優先順位が変化しなかったということを意味し、割込み発生前の実行状態に戻さなければならないわけである。このため、もう一度ＯＳコンテクスト切り替えモジュール１７６に依頼して、切り替え処理を実行させる(処理２４８)。
【００８１】
各オペレーティングシステムの割込みハンドラがリスケジューラ１５４，155を実行した場合、前述したように、共通割込みハンドラの処理２４７に制御が戻ることはない。この場合、リスケジューラ１５４，１５５が新たなタスクの優先順位を優先順位変換モジュール１２２，１２３に通知してくる。これによって、優先順位比較モジュール１２４がオペレーティングシステムの切り替えを行うか否かの判定を行う。
【００８２】
なお、共通割込みハンドラ１７４の構成を図２８のように変更することも可能である。図２９に示した共通割込みハンドラ１７４は、図１０に示した共通割込みハンドラの構成要素の他に、割込み優先順位対応テーブル３８０を所有する。割込み優先順位対応テーブル３８０は、割込みハンドラがいかなる正規化優先順位で動作しなければならないかをしめす対応表である。図２９の例では、割込み要因０に対応する割込みハンドラは、正規化優先順位２５５で動作しなければならず、また、割込み要因３１に対応する割込みハンドラは、正規化優先順位224で動作しなければならない。共通割込みハンドラ１７４は各オペレーティングシステムの割込みハンドラを起動する際に、割込み優先順位対応テーブル３８０にしたがって、当該オペレーティングシステムの正規化優先順位を更新し、また、割込みハンドラ終了後、元の正規化優先順位を復帰させる。なお、この例では共通割込みハンドラ１７４が割込み優先順位対応テーブル３８０を有するものとしているが、割込み優先順位対応テーブル３８０を優先順位変換モジュール１２２，１２３内に設け、共通割込みハンドラ１７４から優先順位変換を依頼する構成を採ることも可能である。
【００８３】
なお、図２９のように、割込みに対しても正規化優先順位を割当てることができるのならば、各オペレーティングシステムのあらゆる動作状態にも正規化優先順位を割当てることができる。例えば、オペレーティングシステムは、一般に以下の四種類の動作状態を持つ。
【００８４】
（１）idle状態
（２）タスク実行状態
（３）オペレーティングシステム自体の処理状態（例えば初期化処理）
（４）割込み処理状態
これら全てに正規化優先順位を割当てることも可能である。この場合、一般に考えて、割込み処理状態が最も優先して動作しなければならず、最も高い正規化優先順位を割当てる。次にオペレーティングシステム自体の処理状態，タスク実行状態，idle状態の順に正規化優先順位を割当てていくことになる。
【００８５】
図１３は共通割込みハンドラ１７４から呼び出される事務処理ＯＳの割込みハンドラ１５２の処理フローを示したものである。第一に、使用中レジスタを割込みスタック２１４に退避し（処理２５０）、割込み処理を実行する(処理２５１)。ここで、オペレーティングシステムがリスケジューリング中か否か（すなわち、リスケジューラ１５４の処理実行中か否か）をチェックする（処理２５２）。リスケジューリング中とは、次に実行すべきタスクを選択している最中であり、実際にはタスクを実行していないことを意味する。したがって、オペレーティングシステムの処理を単純化させるならば、この場合、再びリスケジューリングを最初からやり直せば良いことになる。すなわち、リスケジューリング中であると判定した場合、割込みスタックの退避レジスタを破棄し（処理２５７）、リスケジューラ１５４を最初から起動する（処理２５８）。なお、リスケジューリング中に割込みが発生しても、実行すべきタスクを新たに選択し直す必要がない場合もある。本方式は、この状況でもリスケジューリングを最初から行うことになり、効率的でないこともある。このため、リスケジューリング中に発生し、リスケジューラ１５４の実行に影響を与える処理（例えば、タスク起動・終了など）を待ち行列などに登録しておく方法を用いることもできる。この場合、リスケジューラ１５４の終了前や優先順位通知モジュール１２０内で、該待ち行列に登録しておいた処理を纏めて実行する。この方式を採用すると、割込み発生のたびに途中まで実行していたリスケジューリングをやり直す必要が無い。しかしながら、当該待ち行列に登録していた処理を纏めて実行した後、これによってリスケジューリングが再び必要となるか否かを再チェックしなければならない。
【００８６】
なお、本実施例では、単純化のため、前者の方式で説明を行う。しかし、後者の方式を用いる場合、
（ａ）リスケジューリング中か否かを示すフラグ
（ｂ）処理待ち行列
を用意すればよい。オペレーティングシステムが提供するシステムコールなどにおいて、リスケジューラ１５４の実行に影響を与える処理を、リスケジューリング中であれば、該待ち行列に登録する。更に、リスケジューラ１５４の処理フロー中に、該待ち行列に登録された処理を一括して実行するモジュールを挿入する。
【００８７】
割込みハンドラ１５２がリスケジューリング中でないと判定した場合、当該オペレーティングシステムはその時点で何らかのタスクを実行している。このため、第一に、タスク切り替えが必要か否かを判定する（処理２５３）。タスク切り替えが必要なければ（現実行タスクが最高優先順位であり、かつ、実行可能であれば）、このまま、割込みハンドラ１５２の処理を終了する。このため、割込みスタック２１４上に退避しておいたレジスタ値を復帰し（処理２５４）、共通割込みハンドラへ制御を戻す（処理２５５）。タスク切り替えが必要であると判定した場合、割込みスタック２１４上に退避したレジスタの値をタスク管理テーブルにコピーし（処理２５６）、割込みスタック上の退避レジスタを破棄する（処理２５７）。この後、リスケジューラ１５４を起動する（処理２５８）。なお、プロセッサ１００に、メモリ１０１上データの参照を行って、同時に、割込みスタックポインタ２１６の値を増減できる機能が備わっていれば、処理２５６と処理２５７を纏めて実行することができる。
【００８８】
次に、ロック取得モジュール２１９，ロック解放モジュール２２０の処理フローを説明する。ここでは、優先順位上昇方式を用いる例を説明し、優先順位継承方式を使用する実施例については後述する。なお、ここでは、ロック取得・解放を要求したタスク、および、それを管理するオペレーティングシステムを自タスク，自オペレーティングシステムと呼び、もう一方のオペレーティングシステムを別オペレーティングシステムと呼んでいる。
【００８９】
図１４が優先順位上昇方式を用いるロック取得モジュール２１９の処理フローである。ロック取得モジュール２１９は、第一に、別オペレーティングシステムのタスクがロック取得中か否かをチェックし（処理２６０）、取得中でなければ、自オペレーティングシステムがロックの所有者であるように設定する（処理２６１）。別オペレーティングシステムのタスクがロック取得中であれば、ロックが解放されるまでタスクを待ち状態に移行させる（処理２６３）。このとき、別オペレーティングシステムを優先して実行させ、当該ロックを速やかに解放させるようにしなければならない。このため、優先順位比較モジュール１２４内に記憶されている別オペレーティングシステムの正規化優先順位を自オペレーティングシステムより高くなるように変更する（処理２６２）。ここで処理２６３においてタスクを待ち状態に移行させると、自オペレーティングシステムでリスケジューラが起動される。これにより、リスケジューラから、優先順位通知モジュール，優先順位変換モジュール，優先順位比較モジュールと順次呼び出され、正規化優先順位を高く変更した別オペレーティングシステムに切り替えが行われることになる。
【００９０】
図１５が優先順位上昇方式を用いる場合のロック解放モジュール２２０の処理フローである。第一に、自己が所有するロックを解放する（処理２７０）。次に、別オペレーティングシステムがロック取得待ちか否かをチェックする（処理２７１）。ロック取得待ちでなければ、正規化優先順位の上昇は行われていない。このため、このままロック解放モジュール２２０の処理を終了する。しかし、別オペレーティングシステムがロック取得待ちであれば、優先順位逆転現象を解決するため、正規化優先順位の上昇が行われている筈である。したがって、自オペレーティングシステムの正規化優先順位を元の値に戻し（処理２７２）、次に、別オペレーティングシステムでロック取得待ちとなっているタスクを実行可能状態に移行させる（処理２７３）。ロック取得待ちタスクを実行可能とすることによりタスク切り替えが発生すれば、別オペレーティングシステムのリスケジューラが起動され、前述のロック取得モジュールの場合と同様、最終的に、優先順位比較モジュール１２４が実行される。これにより、元の正規化優先順位を用いてオペレーティングシステムの重要性が比較され、より高い正規化優先順位を有するオペレーティングシステムが選択される。
【００９１】
次に、優先順位継承方式を用いる例を説明する。この場合、図１６に示すように、各オペレーティングシステムは、正規化優先順位にしたがってタスクの優先順位を変更する優先順位設定モジュール２８０，２８１を装備しなければならない。また、優先順位変換モジュール１２２，１２３は、優先順位を正規化優先順位に変換する機能のほか、正規化優先順位を優先順位に変換する機能を搭載しなければならない。このため、優先順位変換モジュール１２２，１２３は、正規化優先順位をインデクスとし、各オペレーティングシステムの優先順位を内容とする優先順位逆変換テーブル２８２，２８３を有する。
【００９２】
オペレーティングシステムは、一般に、システムコールとして、タスクの優先順位を変更する機能を有している。優先順位設定モジュール２８０，２８１は、与えられた正規化優先順位を各オペレーティングシステムに対応する優先順位に変換し、タスク優先順位変更システムコールなどを用いてタスクの優先順位を変更する。優先順位逆変換テーブル２８２，２８３は、優先順位設定モジュール２８０，２８１の機能をサポートする役割を有する。本実施例では、正規化優先順位が０〜２５５であるため、優先順位逆変換テーブル２８２，２８３は、256個のエントリを有する配列である。また、事務処理ＯＳ１１０の優先順位の範囲が０〜３１であるため、優先順位逆変換テーブル２８２の各配列要素は、０〜３１の範囲のいずれかの整数を有し、かつ、以下の不等式を満足する（配列の名称をrevBusinessとする）。
【００９３】
ｉ＞ｊ⇒revBusiness［ｉ］≧revBusiness［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
リアルタイムＯＳ１１１は優先順位０〜２５５を有し、かつ、優先順位の数値が小さいほど優先順位が高いという特徴を有するため、優先順位逆変換テーブル２８３の各配列要素は、０〜２５５までのいずれかの整数を有し、かつ、以下の不等式を満足する（配列の名称をrevRealtimeとする）。
【００９４】
ｉ＞ｊ⇒revRealtime［ｉ］≦revRealtime［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
さて、本実施例では、正規化優先順位の数値が０〜２５５、リアルタイムＯＳの優先順位の数値が０〜２５５であるとしているため、正規化優先順位とリアルタイムＯＳの優先順位との対応付けを一対一に行うことができている。したがって、優先順位変換テーブル１７１から一意に優先順位逆変換テーブル２８３を導出することができる。しかしながら、事務処理ＯＳの優先順位の数値は０〜３１であるため、優先順位逆変換テーブル２８２を一意に定めることはできない。この場合、例えば、正規化優先順位「１」に対応する事務処理ＯＳの優先順位を、優先順位変換テーブル１７０から導き出すことができない。このため、一意に定めることのできない正規化優先順位に対しては、上記不等式を満たすように、事務処理ＯＳの優先順位を適宜に定めている。
【００９５】
優先順位変換モジュール１２２のうち、優先順位逆変換機能の処理フローについて図１７に示した。ここでは、指定正規化優先順位に対応する事務処理ＯＳの優先順位を優先順位逆変換テーブル２８２から取り出し（処理２９０）、当該優先順位を優先順位設定モジュール２８０に通知する（処理２９１）。優先順位変換モジュール１２３も同様の優先順位逆変換機能を有する。
【００９６】
これに対する優先順位設定モジュール２８０の処理フローを図１８に示す。優先順位設定モジュール２８０は、第一に、優先順位変換モジュール１２２に依頼して、正規化優先順位から事務処理ＯＳの優先順位への変換を行わせる（処理２９２）。次に、事務処理ＯＳの優先順位変更システムコールなどを用いてタスクの優先順位を変更させる（処理２９３）。リアルタイムＯＳ１１１における優先順位設定モジュール２８１の処理も同様である。
【００９７】
次に、これらの優先順位逆変換機能，優先順位設定モジュールを用いた優先順位継承方式の実現方法について述べる。
【００９８】
図１９は優先順位継承方式を用いるロック取得モジュール２１９の処理フローである。ロック取得モジュール２１９は、第一に、別タスクがロック取得中か否かをチェックし（処理３００）、取得中でなければ、自タスクがロックの所有者であるように設定する（処理３０１）。別タスクがロック取得中であれば、ロックが解放されるまでタスクを待ち状態に移行させる必要がある（処理３０４）。このとき、ロック取得中タスクを優先して実行させ、当該ロックを速やかに解放させるようにしなければならない。ロック取得中タスクの正規化優先順位と自タスクの正規化優先順位を比較し（処理３０２）、ロック取得中タスクの正規化優先順位が低ければ、当該タスクに自タスクの優先順位を継承させる(処理３０３)。優先順位継承は、ロック取得中タスクを実行するオペレーティングシステムの優先順位設定モジュールに対し、自タスクの正規化優先順位を指定して優先順位設定を依頼することによって行うことができる。ロック取得中タスクの正規化優先順位が既に自タスクの正規化優先順位より高ければ、優先順位継承を行う必要はなく、直ちにタスクを待ち状態に移行させることができる。
【００９９】
図２０は優先順位継承方式を用いるロック解放モジュール２２０の処理フローである。第一に、自己が所有するロックを解放する（処理３１０）。次に、別タスクがロック取得待ちか否かをチェックする（処理３１１）。ロック取得待ちでなければ、正規化優先順位継承が行われていないことになり、このままロック解放モジュール２２０の処理を終了する。しかし、別タスクがロック取得待ちであれば、正規化優先順位継承が行われている筈である。したがって、優先順位設定モジュールに依頼して自タスクの正規化優先順位を元の値に戻し(処理３１２)、次に、ロック取得待ちとなっているタスクを実行可能状態に移行させる（処理３１３）。
【０１００】
本実施例では説明を省略したが、ロック取得モジュール２１９，ロック解放モジュール２２０などを実行している途中に割込みが発生し、タスク切り替えなどが起こると、ロック所有者を示すデータなどに不整合が生じる可能性がある。したがって、通常、これらの処理実行中には、割込みマスク機能によって割込み発生を抑止する。
【０１０１】
図１６〜図２０に示したプログラムモジュール，処理フローにより、オペレーティングシステム間での排他制御において、優先順位継承方式を用いることが可能となる。なお、実際には、図１９，図２０に示した処理フローを用いることにより、一つのオペレーティングシステム内で正規化優先順位の継承を行うことも可能である。
【０１０２】
図２１に、割込みマスクレベル計算モジュール１７７の内部構造を示した。割込みマスクレベル計算モジュール１７７は、正規化優先順位を割込みマスクレベルに変換し、一定以上の正規化優先順位であれば、特定の割込みをマスクする機能である。これは、ある一定以上の正規化優先順位を有するタスクは、割込み処理よりも優先して実行されなければならないという考えに基づく機能である。したがって、システムコールなどで割込みをマスクする機能が備わっていれば、本機能が存在しなくても十分システムは成立する。ただし、割込みマスクレベル計算モジュール１７７の利点として、正規化優先順位が一定値以上になれば、自動的に割込みマスクを実行することがある。
【０１０３】
割込みマスクを実行するため、割込みマスクレベル計算モジュール１７７は、割込みマスク変換テーブル３２０を所有する。割込みマスク変換テーブル３２０は、正規化優先順位から割込みマスク値を入手するための変換テーブルである。本実施例では、図４に示したように、３２種類の割込み要因を個別にマスクできる計算機アーキテクチャを対象としているため、割込みマスク変換テーブル320の各エントリは３２ビット長データを有する。しかしながら、図３に示したように、４ビットの割込みマスクレベルを使用すると、割込みマスク変換テーブル３２０の各エントリを４ビット長に縮少させることができる。ここで、図２１に示した実施例では、例えば、正規化優先順位「０」に対応する割込みマスク値が0x00000000であり、正規化優先順位「２５５」に対応する割込みマスク値は 0xffffffffである。これは、正規化優先順位が「０」であれば全ての割込みを許可し、最高の正規化優先順位でシステムが動作しているならば、全ての割込みをマスクすることを意味する。優先順位比較モジュール１２４が割込みマスクレベル計算モジュール１７７に対して、現在実行中オペレーティングシステムの正規化優先順位を通知することにより、必要な割込みマスクを自動的に行うことができる。
【０１０４】
図２２に割込みマスクレベル計算モジュール１７７の処理フローを示す。ここでは、第一に、正規化優先順位に対応する割込みマスク値を割込みマスク変換テーブル３２０から取り出す（処理３３０）。次に、入手した割込みマスク値を割込みマスクレジスタ１４３などに設定して、割込みマスクを実施する（処理331)。
【０１０５】
以上に本発明の第一の実施例について説明した。本実施例を用いることにより、各オペレーティングシステムが実行しているタスクの優先順位にしたがって、オペレーティングシステムの切り替えを行うことができる。本実施例では、各オペレーティングシステム内に優先順位通知モジュールを組み込み、リスケジューリングのたびに優先順位の変更を通知するように改造しなければならない。しかしながら、市販オペレーティングシステムを使用する場合など、このような改造を施せないことも多い。以下、これに対処する本発明の第二の実施例について説明する。
【０１０６】
図２３は本発明の第二の実施例を示した構成図である。事務処理ＯＳ１１０，リアルタイムＯＳ１１１は、それぞれ、現在実行中タスクの優先順位（実行優先順位３４０，３４１）を保持するものとする。各オペレーティングシステムは、図５に示す実行可能待ち行列１５０，１５１の先頭に存在するタスク管理テーブル１６２，１６３内に格納されている優先順位の数値が実行優先順位３４０，３４１となる。また、実行可能待ち行列が優先順位毎に複数個存在する場合には、一般に、現時点で最高優先順位の実行可能待ち行列がどこに存在するかを示すポインタや、最高優先順位の数値そのものを示す変数（優先順位保持変数）を用意することが多い。前者の場合には、該ポインタから実行可能待ち行列を辿り、タスク管理テーブルを参照することにより、後者の場合には、該優先順位保持変数自体を読み出すことにより、実行優先順位３４０，３４１を入手できる。
【０１０７】
オペレーティングシステム切り替えプログラム１１８内には、新たに、優先順位監視モジュール３４４を設ける。これ以外のモジュールである、優先順位変換モジュール１２２，１２３，優先順位比較モジュール１２４，共通割込みハンドラ１７４，ＯＳ間通信機能モジュール１７５，ＯＳコンテクスト切り替えモジュール１７６，割込みマスクレベル計算モジュール１７７は、第一の実施例で説明した内容と同様の構成，処理フローを有する。各オペレーティングシステム内には、優先順位通知モジュール１２０，１２１は存在しない。
【０１０８】
優先順位監視モジュール３４４は、事務処理ＯＳ実行優先順位記憶値３４２とリアルタイムＯＳ実行優先順位記憶値３４３を所有する。優先順位監視モジュール３４４は定期的に起動され、各オペレーティングシステムの実行優先順位340,３４１を監視する。ここで、記憶している実行優先順位３４２または３４３と、現在の実行優先順位３４０または３４１が異なっていれば、優先順位が変化したと認識して、優先順位変換モジュール１２２または１２３に新たな実行優先順位を通知する。
【０１０９】
優先順位監視モジュール３４４の処理フローを図２４に示す。第一に、事務処理ＯＳの実行優先順位３４０を読み出して、これを事務処理ＯＳ実行優先順位記憶値３４２と比較する（処理３５０）。これにより、事務処理ＯＳの優先順位が変化したか否かを認識できる。優先順位が変化していなければ何も実行せず、処理３５３に移行する。優先順位が変化していれば、事務処理ＯＳの実行優先順位３４０を事務処理ＯＳ実行優先順位記憶値３４２に登録し（処理３５１）、次に、当該優先順位を事務処理ＯＳの優先順位変換モジュール１２２に通知する（処理３５２）。リアルタイムＯＳ１１１の実行優先順位変化に対しても同様の処理を行う。第一に、リアルタイムＯＳの実行優先順位３４１とリアルタイムＯＳ実行優先順位記憶値３４３との比較を行い（処理３５３）、優先順位の変化が無ければ処理を終了する。優先順位が変化していれば、リアルタイムＯＳの実行優先順位３４１をリアルタイムＯＳ実行優先順位記憶値３４３に登録し(処理３５４)、これをリアルタイムＯＳの優先順位変換モジュール１２３に通知する（処理
３５５）。
【０１１０】
なお、優先順位変換モジュールに優先順位を通知した結果、オペレーティングシステムの切り替えが行われると、優先順位監視モジュール３４４に制御が戻ってこないことに注意しなければならない。このため、図２４の監視方法は、常に事務処理ＯＳ１１０の優先順位変化を優先して監視するものであると言える。両オペレーティングシステムの監視を対等なものとするためには、優先順位監視モジュール３４４の起動回数を計数しておき、
（１）起動回数が奇数であれば事務処理ＯＳ１１０の優先順位変化を監視し、
（２）起動回数が偶数であればリアルタイムＯＳ１１１の優先順位変化を監視する
といった処理フローなどに改める必要がある。
【０１１１】
ここで、優先順位監視モジュール３４４は、「定期的に」起動され、優先順位の変化を監視することに注意しなければならない。定期的な処理を実現するためには、タイマ割込みによって優先順位監視モジュール３４４を起動すればよい。ここでは、タイマ割込み，外部割込みを含む全ての割込みが共通割込みハンドラ１７４で一括処理されることに着目し、共通割込みハンドラ１７４内に優先順位監視モジュール３４４を埋め込む方法について説明する。図２５が優先順位監視モジュール３４４を埋め込んだ共通割込みハンドラ１７４の処理フローである。図中、処理２４０〜２４８は全て図１２に等しい。優先順位監視モジュール344の起動（処理３６０）はオペレーティングシステム切り替えを行う可能性がある。このため、割込みハンドラの実行（処理２４５，２４６）後に埋め込まなければならない。割込みハンドラ１５２，１５３が共通割込みハンドラ１７４に制御を戻すと、自動的に優先順位変化が監視され、必要に応じてオペレーティングシステムの切り替えが行われる。優先順位監視モジュール３４４がオペレーティングシステムの切り替えを行う必要がないと判断した場合、そのまま共通割込みハンドラ１７４の処理を終了する。
【０１１２】
なお、本発明の第二の実施例では、リスケジューリング直後の優先順位変化を優先順位変換モジュールに通知する手段が存在しない。すなわち、一定間隔毎に優先順位の変化をチェックするのであって、優先順位の変化に直ちに反応してオペレーティングシステムを切り替えることにはならない。このため、本発明の第二の実施例は、オペレーティングシステム内部の改造を伴わない計算機を実現できるが、第一の実施例に比べ、切り替え効率的に劣るという特徴がある。
【０１１３】
本発明の第二の実施例は、両オペレーティングシステムの内部を改造しないという条件を満たすものであるが、例えば、リアルタイムＯＳ１１１は改造できるが、事務処理ＯＳ１１０を改造することができない、といった条件が発生することもある。この場合、本発明の第三の実施例として、リアルタイムＯＳ１１１内部に優先順位通知モジュール１２１を搭載し、優先順位監視モジュール３４４は事務処理ＯＳ１１０の優先順位変化のみを監視するといった計算機を実現することも可能である（図２６）。
【０１１４】
また、リスケジューラ内部に優先順位通知モジュールを組み込むのではなく、各オペレーティングシステムのタイマ割込み処理モジュール内部など、定期的に起動される部分に優先順位通知モジュールを組込み、優先順位監視モジュール
３４４の代用とすることも可能である。
【０１１５】
以上説明した本発明を図２７に示す車載ナビゲーションシステムに適用した場合、処理時間の長い経路探索タスクが動作している場合でもユーザからの入力を受け付けることができる。つまり、この場合はインタフェースタスクに対して、経路探索タスクよりも高い正規化優先順位を与える。このとき、ユーザがボタンを押してインタフェースタスクが動作すれば、より正規化優先順位の高いタスクを動作させる事務処理ＯＳに切り替えが行われ、結果として、処理の長い経路探索タスクが動作している場合にもインターフェースタスクが実行されることになる。
【０１１６】
更に、複数のオペレーティングシステムを実行する仮想計算機においても、本発明を適用することにより異なった優先順位体系を有しているオペレーティングシステムを、実行すべきタスクの優先順位にしたがって実行させることができる。
【０１１７】
以上より、本発明によれば事務処理用ＯＳのユーザインタフェースとリアルタイムＯＳの信頼性を併せ持つ計算機を構築することができる。
【０１１８】
前記第一乃至第三の実施例は、全て、オペレーティングシステム切替えプログラム１１８の内部で優先順位の変換を行う構成を有している。しかしながら、優先順位変換モジュール１２２，１２３は、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１に個別に対応しているため、これらを、各オペレーティングシステム内部に搭載しても良い。このような変更を加えた第四の実施例を図２９に示す。
【０１１９】
本実施例では、第一に、優先順位変換モジュール１２２，１２３が各オペレーティングシステムでの優先順位を正規化優先順位に変換する。これを受けて、優先順位通知モジュール１２０，１２１が、優先順位比較モジュール１２４に対して各オペレーティングシステムの正規化優先順位を通知する。
【０１２０】
この実施例では、事務処理ＯＳ１１０，リアルタイムＯＳ１１１とオペレーティングシステム切替えプログラム１０８とのインタフェースが全て正規化優先順位によって行われる。前記第一乃至第三の実施例では、実行可能タスクが存在する場合には、タスクの優先順位を通知し、実行可能タスクが存在しない場合には、idle状態であることを通知していた。これらの場合、idle状態や、オペレーティングシステム自体が何らかの処理を実行しなければならない状態を、自由に正規化優先順位にマッピングすることができない。本実施例（第四実施例）では、各オペレーティングシステム内で優先順位を正規化優先順位に変換するため、タスク実行中以外の状態も自由に正規化優先順位にマッピングすることが可能となる。
【０１２１】
【発明の効果】
本発明によれば、複数個のオペレーティングシステムを単一プロセッサで動作させる計算機において、各オペレーティングシステムが実行するタスクの優先順位にしたがって、オペレーティングシステムの切り替えを行うことができ、より重要なタスクを優先して実行させることができる。また、本発明では、優先順位変換モジュールによって正規化優先順位に変換し、これによってオペレーティングシステム間の優先順位比較を行うため、異なった優先順位体系を有するオペレーティングシステム同士を実行させる計算機であっても、リアルタイム性・効率性を損なうことがない。
【図面の簡単な説明】
【図１】本発明の第一の実施例におけるシステム構成を示す図である。
【図２】計算機のハードウェア構成を示す図である。
【図３】割込みレベルマスク機能を装備する場合のステータスレジスタを示す図である。
【図４】個別割込みマスク機能を装備する場合のステータスレジスタを示す図である。
【図５】オペレーティングシステム内部構成を詳細に示す図である。
【図６】オペレーティングシステム切り替えプログラム内部構成を詳細に示す第一の図である。
【図７】リスケジューラの処理フローを示す図である。
【図８】優先順位変換モジュールの処理フローを示す図である。
【図９】優先順位比較モジュールの処理フローを示す図である。
【図１０】オペレーティングシステム切り替えプログラム内部構成を詳細に示す第二の図である。
【図１１】ＯＳコンテクスト切り替えモジュールの処理フローを示す図である。
【図１２】共通割込みハンドラの処理フローを示す図である。
【図１３】割込みハンドラの処理フローを示す図である。
【図１４】優先順位上昇方式におけるロック取得モジュールの処理フローを示す図である。
【図１５】優先順位上昇方式におけるロック解放モジュールの処理フローを示す図である。
【図１６】優先順位設定モジュール内部構成を詳細に示す図である。
【図１７】優先順位変換モジュールにおける優先順位逆変換機能の処理フローを示す図である。
【図１８】優先順位設定モジュールの処理フローを示す図である。
【図１９】優先順位継承方式におけるロック取得モジュールの処理フローを示す図である。
【図２０】優先順位継承方式におけるロック解放モジュールの処理フローを示す図である。
【図２１】割込みマスクレベル計算モジュール内部構成を詳細に示す図である。
【図２２】割込みマスクレベル計算モジュールの処理フローを示す図である。
【図２３】本発明の第二の実施例におけるシステム構成を示す図である。
【図２４】優先順位監視モジュールの処理フローを示す図である。
【図２５】優先順位監視モジュールを起動する共通割込みハンドラの処理フローを示す図である。
【図２６】本発明の第三の実施例におけるシステム構成を示す図である。
【図２７】オペレーティングシステム間でのタスク振り分け例を示す図である。
【図２８】共通割込みハンドラの別の構成を示した図である。
【図２９】本発明の第四の実施例におけるシステム構成を示す図である。
【符号の説明】
１００…プロセッサ、１０１…メモリ、１０２…入出力制御装置、１０３…プロセッサバス、１０４…ディスク装置、１０５…ディスプレイ、１０６…リアルタイム制御ネットワーク、１０７…割込み信号線、１０８…タイマ装置、１１０…事務処理ＯＳ、１１１…リアルタイムＯＳ、１１２〜１１７，３７０〜３７３…タスク、１１８…オペレーティングシステム切り替えプログラム、１２０，１２１…優先順位通知モジュール、１２２，１２３…優先順位変換モジュール、１２４…優先順位比較モジュール、１３０…ＣＰＵ、１３１…キャッシュメモリ、１３２…汎用レジスタ、１３３…プログラムカウンタ、１３４…ステータスレジスタ、１３５…割込みコントローラ、１３６…データバス、１３７…アドレスバス、１３８…割込み状態信号、１４０…割込みブロックビット、１４１…割込みマスクレベルフィールド、１４２…実行状態レジスタ、１４３…割込みマスクレジスタ、１４４〜１４７…割込みマスクビット、１５０，１５１…実行可能待ち行列、１５２，１５３…割込みハンドラ、１５４，１５５…リスケジューラ、１５６，１５７…システムコールプログラム、１６０〜１６５…タスク管理テーブル、１７０，１７１…優先順位変換テーブル、１７２…事務処理ＯＳ正規化優先順位、１７３…リアルタイムＯＳ正規化優先順位、１７４…共通割込みハンドラ、１７５…ＯＳ間通信機能モジュール、１７６…ＯＳコンテクスト切り替えモジュール、１７７…割込みマスクレベル計算モジュール、２１０…実行ＯＳ記憶変数、２１１…割込み対応テーブル、２１２…事務処理ＯＳ用保存コンテクスト、２１３…リアルタイムＯＳ用保存コンテクスト、２１４，２１５…割込みスタック、２１６，２１７…割込みスタックポインタ、２１８…共有メモリ、２１９…ロック取得モジュール、２２０…ロック解放モジュール、２８０，２８１…優先順位設定モジュール、２８２，２８３…優先順位逆変換テーブル、３２０…割込みマスク変換テーブル、３４０，３４１…実行優先順位、３４２…事務処理ＯＳ実行優先順位記憶値、３４３…リアルタイムＯＳ実行優先順位記憶値、344…優先順位監視モジュール、３８０…割込み優先順位対応テーブル。
【発明の属する技術分野】
本発明は複数個のオペレーティングシステムを切り替えつつ動作させる計算機およびそのオペレーティングシステム切り替え方式を対象分野とし、特に、相異なる優先順位体系を有するオペレーティングシステムの切替え方式に関連する。
【０００２】
【従来の技術】
一つの計算機で複数のオペレーティングシステムを動作させる技術として、従来から大型計算機において、「仮想計算機(Virtual Machine：ＶＭ）」が知られている。該従来技術では、計算機内で並行して動作する複数個の仮想計算機それぞれの上で複数のユーザタスク（以降、プロセスおよびスレッドを統一してタスクと呼ぶ）を切り替えて処理を実行する。仮想計算機は、通常、大型計算機内の一つのプロセスとして実現されるが、仮想計算機とユーザタスクとの関連を考慮すると、一つのオペレーティングシステムであると見なすことも可能である。
【０００３】
一般に、それぞれの仮想計算機には、該仮想計算機の優先順位にしたがって一定のタイムスライス（ＣＰＵ割当て時間）を与える。各仮想計算機は、与えられたタイムスライスの範囲内でユーザタスクを切り替えて動作させる。このような仮想計算機技術の実行効率を高める技術として、特開平5−197577 号に開示された「仮想計算機における仮想計算機実行プライオリティ制御方式」がある。
【０００４】
該従来技術は、複数の仮想計算機と、該複数の仮想計算機を制御するための仮想計算機モニタとから構成される。仮想計算機は、システムタスクのように実行優先順位の高いタスクの実行開始・実行終了時に、仮想計算機モニタに対してタスクの優先順位を通知する。これを受けた仮想計算機モニタは、仮想計算機の実行優先順位を、通知された優先順位に変更する。仮想計算機の実行優先順位を仮想計算機内で実行されるタスクの優先順位に変更することにより、仮想計算機制御を効率的に行うことができるとしている。
【０００５】
【発明が解決しようとする課題】
マイクロプロセッサ、特に、組込み向けマイクロプロセッサの性能向上と、オペレーティングシステムの機能向上に伴って、複数個の相違なるオペレーティングシステムを一つの計算機上で同時に動作させ、これらを動的に切り替えて処理を行うというユーザニーズが現われている。
【０００６】
一般に、工場・プラントなどの機械制御，車載ナビゲーションシステムといった分野では、外部環境変化に対して即座に応答するというリアルタイム性，長時間連続運転を可能とする信頼性などが重要視されている。このため、割込み応答性が高く、かつ、コンパクトでモジュール構成を有するリアルタイム用オペレーティングシステム（リアルタイムＯＳ）が用いられることが多い。しかしながら、リアルタイムＯＳは、リアルタイム性・信頼性を重要視する反面、人間とのインタフェースに優れているとは言い難い。
【０００７】
一方、一般のパソコン（ＰＣ）に用いられている事務処理用オペレーティングシステム（事務処理ＯＳ）は、画像を用いて操作を行えるようにするなど、対人間インタフェースに優れている。このため、従来はリアルタイムＯＳを使用していた分野にも事務処理ＯＳのユーザインタフェースを使用したいという要求が高まっている。しかし、事務処理ＯＳは人間との対話を主な処理としているため、割込み応答性よりも処理のスループットを重要視し、比較的長時間割込み禁止状態のまま処理を実行することもある。また、コンパクトな構成を有するリアルタイムＯＳに対し、信頼性において匹敵するとは言い難く、２４時間連続運転などに向いていないという側面もある。
【０００８】
しかしながら、大型計算機上で複数の仮想計算機(オペレーティングシステム)を並行して動作させる方式と同様に、同一計算機上で事務処理ＯＳとリアルタイムＯＳとを動作させ、必要に応じてこれらのオペレーティングシステムを切り替えることができれば、優れたユーザインタフェースとリアルタイム性・信頼性とを両立させることができる。マイクロプロセッサの性能向上を考慮すれば、複数のオペレーティングシステムを一つの計算機上で動作させることは、大型計算機だけに許された技術ではなくなってきている。
【０００９】
このとき、それぞれのオペレーティングシステムの重要性を考慮すると、常にリアルタイムＯＳを優先的に動作させ、リアルタイムＯＳ上で実行させるタスクが存在しなくなった場合にのみ、事務処理ＯＳを動作させるという方法が最も単純なオペレーティングシステム切替え方式である。しかしながら、各オペレーティングシステム上で動作する個々のタスクの重要性が、このように（リアルタイムＯＳ上のタスクは、常に、事務処理ＯＳ上のタスクよりも重要性が高いというように）単純に切り分けられるとは限らない。
【００１０】
図２７に単純な切り分けを行えない例を示す。図２７は車載ナビゲーションシステムの構成例を示したものである。ここでは、システムを簡略化し、車載ナビゲーションシステムが、（１）運転位置を認識する位置認識タスク３７０，(２)目標地点までの最短経路を導出する経路探索タスク３７１，（３）ボタン・タッチパネルなどからの入力を処理するインタフェースタスク３７２，（４）運転休憩中に起動していたゲームタスク３７３、という四つのタスクから構成されていると仮定する。通常、高速応答性・信頼性が求められる位置認識タスク・経路探索タスクはリアルタイムＯＳ１１１上で実行され、ユーザインタフェースに優れた事務処理ＯＳ１１０では、インタフェースタスク・ゲームタスクなどを実行する。しかしながら、一般に、経路探索は非常に計算量の大きい処理であり、数秒オーダの計算時間を要することもある。上記に示した単純な重要性の切り分けを行うと、この間、インタフェースタスクの処理は停止し、ユーザがいくらボタンを押しても認識されないという問題が発生する。
【００１１】
図２７に示した車載ナビゲーションシステムではインタフェースタスクの重要性が高く、これが実行可能状態に移行した場合には、事務処理ＯＳを優先的に実行する必要がある。しかしながら、前記従来技術「仮想計算機における仮想計算機実行プライオリティ制御方式」は、各仮想計算機(オペレーティングシステム)の機能が同一であることを前提としている。一般に、リアルタイムＯＳは環境変化に高速に応答するため、事務処理ＯＳに比べて極めて多くの優先順位レベルを有することが多い。また、極端な場合、リアルタイムＯＳ上では、優先順位の「数値」が小さい（０に近い）ほど優先順位が高く、事務処理ＯＳ上では、優先順位の「数値」が大きいほど優先順位が高い、といった逆の意味付けがなされていることもある。このような場合、たとえ二つのオペレーティングシステムから優先順位を通知されても、いずれのオペレーティングシステムを優先的に起動してよいか判断できないことになる。このため、前記従来技術では、異なった機能を有する事務処理ＯＳとリアルタイムＯＳとを統一して管理することはできない。
【００１２】
本発明の目的は、複数の相異なるオペレーティングシステムを一つの計算機上で動作させるマルチオペレーティングシステム制御装置において、各オペレーティングシステム上で実行されているタスクの重要性を考慮して、動作させるべきオペレーティングシステムを選択・切り替えることであり、これによって、重要性のあるタスクが優先的に実行されるようにすることである。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明では、複数のタスクをそれぞれのタスクに割当てられた優先順位にしたがって実行する複数のオペレーティングシステムと、この複数のオペレーティングシステムを切り替えて実行する計算機において、下記に示す処理を行う。
【００１４】
（１）各オペレーティングシステムが実行しているタスクの優先順位を確認する優先順位監視処理を行う。若しくは、各オペレーティングシステム内に、自分が実行しているタスクの優先順位を通知する優先順位通知処理を行う。事務処理ＯＳ，リアルタイムＯＳでは、内部に優先順位通知処理を追加することが不
可能なこともある。このとき、前者の優先順位監視処理行う必要がある。
【００１５】
（２）各オペレーティングシステムから入手した実行中タスクの優先順位を、それぞれのオペレーティングシステムで共通の優先順位に変換する優先順位変換処理を行う(以降、該共通の優先順位のことを「正規化優先順位」と呼ぶ。)。（３）優先順位変換処理によって得られた各オペレーティングシステムの正規化優先順位を比較して、動作させるべきオペレーティングシステムを決定し、かつ、オペレーティングシステムの切り替えを実行する優先順位比較処理を行う。
【００１６】
本発明によれば、優先順位通知処理は各オペレーティングシステム内に設けられ、オペレーティングシステムがタスク切り替えを行うたびに、該タスクの優先順位を通知する。
【００１７】
タスク切り替え機能はオペレーティングシステムの中核を構成するものであるため、市販されているオペレーティングシステム内に優先順位通知手段を組込むことが不可能なことも多い。しかしながら、一般に、オペレーティングシステムは実行中タスクの管理情報を計算機のメモリ上に保持し、この管理情報の一部にタスクの実行優先順位がある。また、タスク切り替え処理を高速化するため、現在実行中のタスクの優先順位を特定の変数（優先順位保持変数）に格納しておく場合もある。優先順位監視処理は、タスク管理情報または優先順位保持変数を読み出して、各オペレーティングシステムが実行しているタスクの優先順位を確認する。優先順位監視処理は、外部割込み，タイマ割込みなどのタイミングで優先順位の確認を行う。
【００１８】
優先順位変換処理は、各オペレーティングシステムから入手した実行中タスクの優先順位を、計算機内で共通の正規化優先順位に変換する。このため、優先順位変換処理は、各オペレーティングシステムに対応する優先順位変換テーブルを有することがある。優先順位変換テーブルは、各オペレーティングシステム固有の優先順位から正規化優先順位を取り出すための対応表である。簡単な数式によって個々のオペレーティングシステムの優先順位を正規化優先順位に変換することも可能であるが、高速かつ柔軟なオペレーティングシステム切り替えを実行するためには、優先順位変換テーブルを用いるほうがよい。例えば、優先順位変換テーブルに格納する正規化優先順位の値を適切に定めることにより、個々のオペレーティングシステムから得られる正規化優先順位が互いに等しくならないように変換を行うことも可能である。
【００１９】
優先順位比較処理は、各オペレーティングシステムの正規化優先順位を優先順位変換処理から入手し、現在動作させているオペレーティングシステムより高い正規化優先順位を有するオペレーティングシステムが存在すれば、オペレーティングシステムの切り替えを行う。
【００２０】
【発明の実施の形態】
本発明の実施例を図面を用いて説明する。
【００２１】
図１に本発明の第一の実施例における全体構成を示す。通常、計算機は、プロセッサ１００，メモリ１０１，入出力制御装置１０２，ディスク装置１０４，ディスプレイ１０５などから構成される。プロセッサ１００，メモリ１０１，入出力制御装置１０２はプロセッサバス１０３によって接続される。プロセッサ100は複数個のオペレーティングシステムを動作させるためのマイクロプロセッサである。メモリ１０１は、オペレーティングシステムである事務処理ＯＳ１１０，リアルタイムＯＳ１１１，各オペレーティングシステム上で動作するタスク112〜１１７，オペレーティングシステム切り替えプログラム１１８を記憶する。これらのプログラムはプロセッサ１００によって読み出されて実行される。
【００２２】
入出力制御装置１０２には、プログラム・データを保存するためのディスク装置１０４，画面表示用デバイスであるディスプレイ１０５が接続される。また、工場・プラント制御用、あるいは、組込み向け計算機を実現する場合、入出力制御装置１０２には、リアルタイム制御ネットワーク１０６が接続されることがある。リアルタイム制御ネットワーク１０６には、センサ，アクチュエータなどの入出力機器が接続される。なお、入出力制御装置１０２に接続されるディスク装置１０４，ディスプレイ１０５，リアルタイム制御ネットワーク１０６の入出力装置１０４〜１０６のうち、いずれかまたは全ては、システム構成によって省略されることもある。入出力制御装置１０２は、割込み信号線１０７によってプロセッサ１００と接続され、入出力動作完了などを通知することができる。図１中では、説明のため、割込み信号線１０７とプロセッサバス１０３が別の装置であるように記載しているが、実際には、割込み信号線１０７はプロセッサバス103の一部である。プロセッサ１００内部にはタイマ装置１０８が設けられており、一定周期毎に内部割込みを発生させる。タイマ装置１０８からの割込みは、オペレーティングシステムの計時などに使用される。
【００２３】
プロセッサ１００は割込み信号線１０７によって通知される外部割込みやタイマ装置１０８などからの内部割込みをマスクできる機能を装備する。割込みマスクとは、プログラムが割込みマスクを解除するまで、特定の割込みが入ることを遅延させる機能である。一般に、割込みマスク機能には、下記の三種類が存在する。
【００２４】
（１）全割込みマスク：全ての割込みをマスクする。
【００２５】
（２）個別割込みマスク：個々の割込みをそれぞれマスクできるようにする。
【００２６】
（３）割込みレベルマスク：各割込みにレベルを設定し、指定レベル以下の割込みをマスクする。
【００２７】
プロセッサ１００の種類によって、上記（１）（２）の組合せ、または、(１)（３）の組合せのいずれかで構成することが多い。後者の組合せで構成するプロセッサを採用する場合、対応する入出力装置の重要性にしたがって割込みレベルを割当てることになる。例えば、リアルタイム制御ネットワーク１０６からの割込みを、ディスク装置１０４，ディスプレイ１０５などからの割込みより高いレベルに設定する。
【００２８】
本実施例では、計算機内に二つのオペレーティングシステムである事務処理ＯＳ１１０，リアルタイムＯＳ１１１が存在する。このオペレーティングシステムは、各自に割当てられたメモリ・プロセッサ資源を用い、それぞれ、タスク１１２〜１１４，タスク１１５〜１１７を実行させる。ここでは、オペレーティングシステム数が２個、タスク数が６個（各オペレーティングシステムに対して３個ずつ）の例を示しているが、これらの数値よりも多い、または、少ないオペレーティングシステム，タスクを実装することも可能である。本実施例では、オペレーティングシステム数の動的な変更は想定しないが、各オペレーティングシステムが動的にタスク生成・削除を行うことは可能である。また、本実施例では、事務処理ＯＳ１１０，リアルタイムＯＳ１１１について説明するが、実際に、各オペレーティングシステムがいかなる種類であっても、本発明で述べる技術は適用可能である。タスク１１２〜１１４は事務処理ＯＳで実行される事務処理タスクであり、タスク１１５〜１１７はリアルタイムＯＳで実行されるリアルタイムタスクである。事務処理ＯＳ１１０とリアルタイムＯＳ１１１は、各々独立にタスクの優先順位を定義している。図１に示す実施例では、事務処理ＯＳ１１０環境下で、タスク１１２〜１１４が、それぞれ、優先順位０，７，３１を有し、リアルタイムＯＳ１１１環境下で、タスク１１５〜１１７が、それぞれ、優先順位０，９９，２５５を有する。尚、本実施例においてタスクとはプロセス又はスレッドの総称を意味する。プロセスとは、個別のメモリ空間を有して動作するプログラムを意味する。このため、通常あるプロセスは別のプロセスのデータを変更することはできない。スレッドとは、プロセスのメモリ空間を共有して動作するプログラムを指す。従って、同一プロセス内で動作するスレッド同士の間ではデータ保護機能は存在しない。
【００２９】
各オペレーティングシステム内には、優先順位通知モジュール１２０，１２１が存在する。優先順位通知モジュール１２０，１２１は、各オペレーティングシステムのタスク切り替え時に実行され、オペレーティングシステム切り替えプログラム１１８に対して次に実行すべきタスクの優先順位を通知する。
【００３０】
一般に、事務処理ＯＳとリアルタイムＯＳとは異なった優先順位体系を有することが多い。リアルタイムＯＳでは、比較的多くの優先順位レベルを有することにより、重要な割込みに対する高速応答性を実現する。一方、事務処理ＯＳでは、比較的少ない優先順位レベルを用いて、スループットを向上させる方式を採用する。また、オペレーティングシステムの種類によっては、優先順位の数値が小さい（０に近い）ほど優先順位が高い場合と、優先順位の数値が大きいほど優先順位が高い場合とがある。このため、優先順位通知モジュール１２０，１２１から得られた優先順位をそのまま比較しても意味がない。なお、以降、事務処理ＯＳ１１０では、優先順位の数値が大きいほどタスクの優先順位が高く（図１中では、タスク１１４が最も優先される）、リアルタイムＯＳ１１１では、逆に、優先順位の数値が小さいほどタスクの優先順位が高い（図１中では、タスク115が最も優先される）ものとして説明する。また、事務処理ＯＳ１１０における優先順位は０〜３１の範囲で指定でき、リアルタイムＯＳ１１１における優先順位は０〜２５５の範囲で指定できるものとする。
【００３１】
二つのオペレーティングシステムにおける優先順位体系の違いを解消するため、オペレーティングシステム切り替えプログラム１１８は、優先順位変換モジュール１２２，１２３と優先順位比較モジュール１２４とを構成要素として有する。優先順位変換モジュール１２２，１２３は、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１から得られた優先順位をシステム内で共通の比較基準である正規化優先順位に変換する。各オペレーティングシステムの優先順位をそのまま比較することは不可能であるが、一旦両者を正規化優先順位に変換すれば、両オペレーティングシステムが実行しているタスクの優先順位を比較することができる。なお、ここで、正規化優先順位が一方のオペレーティングシステムの優先順位と全く同一であってもよい。この場合、当該オペレーティングシステムの優先順位がそのまま正規化優先順位となる。優先順位比較モジュール１２４は、両オペレーティングシステムから得られた正規化優先順位を比較し、かつ、より高い正規化優先順位を有するオペレーティングシステムに切り替えて実行させる役割を有する。
【００３２】
図２に、プロセッサ１００の内部構成例を示す。キャッシュメモリ１３１はメモリ１０１上のデータまたは命令を一時的に格納するバッファ記憶装置である。CPU130は演算回路であり、メモリ１０１若しくはキャッシュメモリ１３１上に存在する命令を順次読み出して実行する。命令実行に際して、演算結果を一時的に保持するための汎用レジスタ１３２，命令アドレスを指定するプログラムカウンタ１３３，実行状態を保持するステータスレジスタ１３４を用いる。CPU130，キャッシュメモリ１３１，汎用レジスタ１３２，プログラムカウンタ１３３，ステータスレジスタ１３４は、互いに、データ転送を行う複数の信号線であるデータバス１３６，アドレス指定を行う複数の信号線であるアドレスバス１３７によって接続されている。
【００３３】
割込み信号線１０７とタイマ装置１０８は割込みコントローラ１３５に接続される。割込みコントローラ１３５は、CPU130に対して割込み状態信号１３８を生成する役割を有する。割込み状態信号１３８は、プロセッサ１００に対して現在如何なる種類の割込みが発生しているかを示す信号である。通常、ステータスレジスタ１３４は現在の割込みマスクに関する情報を有しており、割込み状態信号１３８で指定される割込みを受け付けるか否かを決定する。割込みを受け付ける場合、割込みコントローラ１３５は、プログラムカウンタ１３３，ステータスレジスタ１３４などの値を書き替え、対応する割込み処理プログラムを実行させる。
【００３４】
ステータスレジスタ１３４の構成を図３に示す。ここでは、プロセッサ１００が全割込みマスク機能と割込みレベルマスク機能とを装備している場合を示している。図３では、ステータスレジスタ１３４が割込みブロックビット１４０と割込みマスクレベルフィールド１４１を有する。割込みブロックビット１４０がＯＮである場合、プロセッサ１００に対する全ての割込みがマスクされる。割込みマスクレベルフィールド１４１は現在の割込みマスクレベル値を示し、これ以下の割込みレベルは受け付けられない。図３では、割込みマスクレベルフィールド１４１は４ビット長である。このため、合計１６種類のマスクレベルを指定可能であるが（通常、割込みレベル０は「割込みが発生していない」ことを意味し、割込みマスクレベルを０とすることは「割込みマスクを行わない」ことを意味するため、実質的には１５種類となる）、割込みマスクレベルフィールド１４１のビット数を変更することにより、受理できる割込みレベルの種類を増減させることができる。
【００３５】
図４は、プロセッサ１００が全割込みマスク機能と個別割込みマスク機能とを装備している場合のステータスレジスタ１３４の構成を示したものである。この例では、ステータスレジスタ１３４は実際には二つのレジスタ（実行状態レジスタ１４２と割込みマスクレジスタ１４３）から構成される。図３と同様、実行状態レジスタ１４２内に割込みブロックビット１４０が設けられている。割込みマスクレジスタ１４３内の割込みマスクビット１４４〜１４７はそれぞれ別々の割込みに対応しており、この割込みマスクビットのいずれかをＯＮとした場合、対応する割込みが受け付けられなくなる。図３に示すステータスレジスタは、図４のステータスレジスタの特殊なものである。例えば、割込みマスクビット１４４のみＯＮとなっている状態をレベル１とし、割込みマスクビット１４４，１４５の二つがＯＮとなっている状態をレベル２、割込みマスクビット１４４〜１４６の三つがＯＮとなっている状態をレベル３，…、のように対応させることができる。このため、以降、ステータスレジスタ１３４は図４に示す構成として、本発明の説明を行う。
【００３６】
一般的なプロセッサでは、割込みを受理すると、ハードウェアによって自動的に割込みブロックビット１４０がＯＮに書き替えられ、プログラムカウンタ133に割込み処理プログラムのアドレスが格納される。必要に応じて、割込み処理プログラムが割込みブロックビット１４０をＯＦＦに書き替えて割込み受け付けを許可することができる。また、オペレーティングシステムおよびタスクが、一時的に割込みブロックビット１４０や割込みマスクレジスタ１４３の内容を書き替え、特定割込みの受け付けを待たせることもできる。割込みマスク機能は、排他制御の実現や、割込み処理実行中に再び同一割込みが発生することを避けるために用いられる。
【００３７】
次に、このようなハードウェア上に実現される本発明のソフトウェア構成について説明する。図５に、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の内部構成を示した。図中、全てのコンポーネントはメモリ１０１上に格納されている。事務処理ＯＳ，リアルタイムＯＳとも、実行可能タスクの情報を待ち行列１５０，１５１の形で管理する。実行可能待ち行列１５０，１５１は優先順位毎に設けられる場合もあるが、本実施例では、全ての実行可能なタスクが一つの待ち行列によって管理される。なお、実行可能待ち行列が一つであっても、優先順位毎に設けられていても、本発明の内容には影響を与えない。各タスクは、（ａ）実行状態、（ｂ）実行可能状態、（ｃ）待ち状態の三種の状態を順次とるのでオペレーティングシステムは、実行可能タスク以外に、待ち状態タスク，停止状態タスクなどを別の待ち行列で管理する。尚、図５ではこれらの待ち行列の記載を省略している。実行可能待ち行列１５０および１５１によって管理されるタスク管理テーブル１６０〜１６５は、実行すべきタスクの優先順位，タスク実行時のプログラムカウンタ・ステータスレジスタ・汎用レジスタの値などを保存する。
【００３８】
実行可能タスクを一つの待ち行列で管理する場合、実行可能待ち行列に登録されるタスク管理テーブルは優先順位の高い順に配置される。すなわち、次に実行すべきタスクの管理テーブルが待ち行列の先頭に来るように構成する。前述したように、本実施例で述べる事務処理ＯＳ１１０は、０〜３１までの優先順位を有し、優先順位の数値が大きいほど優先順位が高い。また、リアルタイムOS111 は、０〜２５５までの優先順位を有し、優先順位の数値が小さいほど優先順位が高い。このため、事務処理ＯＳでは、タスク１１４（優先順位「３１」）に対応する管理テーブル１６２が実行可能待ち行列１５０の先頭に配置され、以下、タスク１１３（優先順位「７」）の管理テーブル１６１，タスク１１２（優先順位「０」）の管理テーブル１６０の順に配置される。逆に、リアルタイムＯＳでは、タスク１１５（優先順位「０」）に対応する管理テーブル１６３が実行可能待ち行列１５１の先頭に配置され、次に、タスク１１６（優先順位「９９」）の管理テーブル１６４，タスク１１７（優先順位「２５５」）の管理テーブル１６５の順に配置される。
【００３９】
各オペレーティングシステムは、また、割込み処理を行う割込みハンドラ152,１５３，タスクに対してサービスを提供するシステムコールプログラム１５６，１５７、および、タスク切り替えを行うリスケジューラ１５４，１５５を有する。タスクの生成・削除・停止・再開や、外部割込み・内部割込み発生に伴ってタスク切り替えを行わなければならない場合、リスケジューラ１５４，１５５が起動される。リスケジューラ１５４，１５５は、直前に実行していたタスクの実行環境（レジスタなど）をタスク管理テーブルに格納した後に呼び出され、新たに実行すべきタスク決定して、その実行環境をタスク管理テーブルから取り出す。これをプログラムカウンタ，ステータスレジスタ，汎用レジスタなどに設定することにより、選択したタスクを実行する。
【００４０】
リスケジューラ１５４，１５５は、その内部に優先順位通知モジュール１２０，１２１を有する。優先順位通知モジュール１２０，１２１は、新たに実行すべきタスクの実行環境をレジスタに設定する直前に起動され、タスクの優先順位をオペレーティングシステム切り替えプログラム１１８内の優先順位変換モジュール１２２，１２３に通知する。
【００４１】
図６には、オペレーティングシステム切り替えプログラム１１８の内部構成を示したものである。優先順位変換モジュール１２２，１２３は、各オペレーティングシステムでの優先順位を正規化優先順位に変更するため、優先順位変換テーブル１７０，１７１をそれぞれ所有する。正規化優先順位は、本実施例では、０〜２５５の範囲の整数であり、「正規化優先順位の数値が大きいほど、正規化優先順位が高い」と定義する。勿論、正規化優先順位の数値の範囲を変更したり、「正規化優先順位の数値が小さいほど、正規化優先順位が高い」と定義することも可能である。
【００４２】
前述したように、事務処理ＯＳ１１０は０〜３１までの優先順位を有している。このとき、優先順位変換テーブル１７０は、３２個のエントリを有する配列となる。各配列要素は０〜２５５の範囲の整数を有し、かつ、以下の不等式を満足する（ここでは、配列の名称をprioBusinessとする）。
【００４３】
ｉ＞ｊ⇔prioBusiness［ｉ］＞prioBusiness［ｊ］
（ただし、０≦ｉ，ｊ≦３１）
事務処理ＯＳ１１０の優先順位、および、正規化優先順位ともに、数値が大きいほど優先順位が高いとしているため、この条件が成立する必要がある。
【００４４】
同様に、リアルタイムＯＳ１１１が０〜２５５までの優先順位を有している場合、優先順位変換テーブル１７１は、２５６個のエントリを有する配列となる。各配列要素は０〜２５５の範囲の整数を有し、かつ、以下の不等式を満足する
（配列の名称をprioRealtimeとする）。
【００４５】
ｉ＞ｊ⇔prioRealtime［ｉ］＜prioRealtime［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
事務処理ＯＳと不等号の向きが異なる理由は、リアルタイムＯＳでは、優先順位の数値が小さいほど優先順位が高いとしているためである。
【００４６】
図６では、事務処理ＯＳ１１０上でタスク１１４が次に実行可能であると判定された場合、優先順位通知モジュール１２０から優先順位の数値「３１」が通知される。優先順位変換モジュール１２２は、優先順位変換テーブル１７０を利用し、正規化優先順位の数値「１２４」を入手することができる。逆に、リアルタイムＯＳ１１１上でタスク１１５が次に実行可能となった場合、優先順位通知モジュール１２１からリアルタイムＯＳでの優先順位の数値「０」が通知される。優先順位変換モジュール１２３は、優先順位変換テーブル１７１を使用して、正規化優先順位の数値「２５５」を入手する。ここで、本実施例では、事務処理ＯＳ１１０のタスクの優先順位がいくら高くても、正規化優先順位の数値が「１２４」を越えないことに注意する必要がある。これは、優先順位変換テーブルの設定方法の極端な例であり、リアルタイムＯＳ上のタスクをできる限り優先して実行させるという目的のためのものである（リアルタイムＯＳ上のタスクでも、優先順位が低いものに対しては、事務処理ＯＳ上のタスクが優先することがある）。しかし、勿論、二つのオペレーティングシステムの優先順位ができるだけ対等に正規化優先順位に変換されるように、優先順位変換テーブル１７０の構成を変更することも可能である。
【００４７】
優先順位変換モジュール１２２，１２３が変換した正規化優先順位は、いずれも、優先順位比較モジュール１２４に通知される。優先順位比較モジュール124は、通知された事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３とを保持する。この場合、事務処理ＯＳ正規化優先順位１７２の数値は「１２４」であり、リアルタイムＯＳ正規化優先順位１７３の数値は「255」である。
【００４８】
前述したように、優先順位通知モジュール１２０，１２１はリスケジューラ内に存在し、タスク切り替え時に実行される。タスク切り替えから次のタスク切り替えまでの期間は一つのタスクしか実行されないため、タスクの優先順位が動的に変化しない限り、この間、当該オペレーティングシステムに対する正規化優先順位も変化しない。優先順位通知モジュール１２０，１２１は、タスク切り替え時に必ず優先順位を通知してくるため、優先順位比較モジュール１２４内に保持している事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３が、実際の各オペレーティングシステムでのタスクの優先順位を反映した数値となる。
【００４９】
優先順位比較モジュール１２４は、保持している各オペレーティングシステムの正規化優先順位１７２，１７３の数値を相互に比較して、より高い正規化優先順位を有するオペレーティングシステムを優先的に実行させる。図６の例では、より高い正規化優先順位を有するリアルタイムＯＳ１１１を実行させることになる。
【００５０】
オペレーティングシステム切り替えプログラム１１８は、優先順位変換モジュール１２２，１２３，優先順位比較モジュール１２４の他に、発生した割込みを各オペレーティングシステムに振り分ける共通割込みハンドラ１７４，オペレーティングシステム間での協調処理を実行するＯＳ間通信機能モジュール１７５，二つのオペレーティングシステムの実行環境切り替えを行うＯＳコンテクスト切り替えモジュール１７６，タスクの優先順位によって割込みマスクを変更する割込みマスクレベル計算モジュール１７７を有する。このプログラムの詳細は後述する。
【００５１】
図７に事務処理ＯＳ１１０におけるリスケジューラ１５４の処理フローを示した。リアルタイムＯＳ１１１のリスケジューラ１５５も同様の処理を行う。リスケジューラ１５４は、一般に、（１）タイマ割込み処理終了時、（２）外部割込み処理終了時、（３）システムコール実行時などにおいて、現在実行中のタスクが実行可能でなくなるか、実行中タスクより高い優先順位のタスクが実行可能となった場合、実行中タスクのレジスタをタスク管理テーブルに退避した後に起動されるモジュールである。リスケジューラ１５４を起動する可能性のあるシステムコールには、（ａ）タスクの生成・終了・停止・再開（例えば、自分より優先順位の高いタスクを生成した場合）、（ｂ）排他制御の実行・終了（排他制御待ち状態に移行した場合など）に加え、（ｃ）タスクの優先順位変更（自己の優先順位を低下させた場合など）、といったものがある。
【００５２】
リスケジューラ１５４は、第一に、実行可能待ち行列１５０から最高優先順位のタスク管理テーブルを取り出す（処理１８１）。ここで、全てのタスクが待ち状態や停止状態となっていて、実行可能タスクが存在しないこともある。これを処理１８２で判定する。
【００５３】
実行可能タスクが存在しなければ、優先順位変換モジュール１２２にidle状態であることを通知する（処理１８４）。このとき、実行可能タスクが存在しないのであるから、idleループへ移行する（処理１８６）。idleループとは、実行すべき処理が現れるまで何も行わないプログラムである。ここで注意すべきことは、処理１８４において、優先順位変換モジュール１２２に対してidle状態を通知したことである。事務処理ＯＳ１１０がidle状態であれば、優先順位比較モジュール１２４はリアルタイムＯＳ１１１を優先して実行させる。したがって、両オペレーティングシステムが同時にidle状態に移行した場合を除いて、実際に処理１８６でidleループが実行されることはない。再び事務処理ＯＳ１１０が実行される場合には、何らかの実行すべき処理が存在するのであるから、直ちにidleループを抜けて処理１８１に移行することになる。
【００５４】
処理１８２で実行すべきタスクが存在すると判定した場合、次に実行すべきタスクの優先順位をタスク管理テーブルから取り出して、優先順位変換モジュール１２２に通知する。通知した優先順位がリアルタイムＯＳ１１１の優先順位よりも低かった場合（正規化優先順位による比較）、この時点で、リアルタイムＯＳ１１１に切り替えられることになる。リアルタイムＯＳ１１１から逆に事務処理ＯＳ１１０へ切り替えが行われる場合、割込み処理などによって、実行しようとしているタスクが実行可能でなくなったり、更に高い優先順位のタスクが実行可能となったりしない限り、処理１８３の直後から再実行することになる（処理１８１で選択したタスクを起動する）。なお、当然のことながら、現在実行中のタスクが実行可能でなくなるか、実行中タスクより高い優先順位のタスクが実行可能となった場合には、リスケジューラ１５４自体が再起動される。処理185で、タスク管理テーブルからレジスタを復帰してプロセッサ１００のレジスタに登録することにより、選択したタスクの処理を実行する。
【００５５】
ここで、リスケジューラ１５４中、処理１８３，１８４が優先順位通知モジュール１２０に相当する。リスケジューラ１５５内にも同様に優先順位通知モジュール１２１が埋め込まれる。
【００５６】
次に、図８に、事務処理ＯＳ１１０に対応する優先順位変換モジュール１２２の処理フローを示す。優先順位変換モジュール１２２は優先順位通知モジュール１２０から呼び出され、直ちに、優先順位変換処理を実行する。最初に、優先順位通知モジュール１２０がidle状態を通知してきたか否かを判定する（処理190)。idle状態はあらゆる優先順位よりも低い優先順位を有すると見なすこともできるので、ここでは、いずれの正規化優先順位よりも低くなるように、（−１）という正規化優先順位の数値を有していると考える。処理１９３では、この数値（−１）を優先順位比較モジュール１２４に通知する。idle状態でなければ、優先順位変換テーブル１７０から対応するエントリを読み出し（処理１９１）、これを優先順位比較モジュール１２４に通知する（処理１９２）。リアルタイムＯＳ１１１に対応する優先順位変換モジュール１２３の処理も同様である。
【００５７】
図９は優先順位比較モジュール１２４の処理フローである。優先順位比較モジュール１２４は、第一に、事務処理ＯＳ１１０からの正規化優先順位であるか、リアルタイムＯＳ１１１からの正規化優先順位であるかを判定する(処理２００)。事務処理ＯＳ１１０の正規化優先順位であれば、事務処理ＯＳ正規化優先順位１７２に入手した正規化優先順位を格納する（処理２０１）。リアルタイムＯＳ１１１からの正規化優先順位であれば、リアルタイムＯＳ正規化優先順位１７３に当該正規化優先順位を記憶する（処理２０２）。
【００５８】
正規化優先順位が通知されてくるのは、いずれか一方の正規化優先順位が変化した可能性がある場合のみであるため、ここで、事務処理ＯＳ正規化優先順位１７２とリアルタイムＯＳ正規化優先順位１７３の数値を比較する(処理２０３)。本実施例では、正規化優先順位の数値が大きいオペレーティングシステムを優先的に起動するとしている。したがって、事務処理ＯＳ１１０の正規化優先順位の数値がリアルタイムＯＳ１１１の正規化優先順位の数値より大きければ、次に実行すべきオペレーティングシステムを事務処理ＯＳ１１０とする(処理２０４)。これ以外の場合には、次にリアルタイムＯＳ１１１を実行させるものとする(処理２０５)。なお、ここでは、事務処理ＯＳ１１０とリアルタイムＯＳ１１１の正規化優先順位が等しくても、リアルタイムＯＳ１１１を実行させる。これを変更し、正規化優先順位が互いに等しい場合には事務処理ＯＳ１１０を実行させるとしても問題はない。また、優先順位変換テーブル１７０，１７１の内容を設定するにあたって、各オペレーティングシステムから得られる正規化優先順位が互いに等しくならないようにすることも、システムを単純化させるための一つの方法である。
【００５９】
次に処理２０６で、新たに実行すべきオペレーティングシステムが今まで実行していたオペレーティングシステムに等しいか否かを判定する。今までと異なったオペレーティングシステムを実行させる場合、ＯＳコンテクスト切り替えモジュール１７６に依頼して、オペレーティングシステム実行環境の退避・復帰を行わせる（処理２０７）。
【００６０】
図１０に割込みハンドラ１５２，１５３，共通割込みハンドラ１７４，ＯＳ間通信機能モジュール１７５，ＯＳコンテクスト切り替えモジュール１７６の詳細を示す（割込みマスクレベル計算モジュール１７７については、別の図面で詳細を説明する）。
【００６１】
割込みハンドラ１５２，１５３は、割込み発生時のレジスタなどの保存、一時変数の保持を行うための領域として、それぞれ、割込みスタック２１４，２１５を所有する。割込み発生時には、割込み発生直前のレジスタ値を保存し、このレジスタ値を割込み処理終了後に復帰してやらなければならない。このため、割込みスタック２１４，２１５が必要とされる。使用するプロセッサ１００の種類によっては、割込み発生時に自動的にレジスタが切り替わり、かつ、割込み処理終了後に切り替え前のレジスタに戻す機能を備えているものもある。しかしながら、多重割込みが可能なシステムを考慮した場合には、このようなハードウェアを使用していても、割込みスタックが必要となる（割込み処理中により高い緊急性を有する割込みが発生した場合、新たに発生した割込み処理を優先的に実行し、次いで、元の割込み処理に戻る必要がある）。
【００６２】
割込みハンドラ１５２，１５３は、更に、割込みスタック２１４，２１５中、どの領域まで使用したかを示すためのポインタとして、割込みスタックポインタ２１６，２１７を所有する。割込みハンドラ１５２，１５３は、割込みスタック、および、割込みスタックポインタを用いて割込み発生前の実行環境（レジスタなど）を保存し、必要な割込み処理を実行する。割込み処理終了後、割込み発生前の実行環境を復帰して元々動作していたプログラムの実行を継続させる。
【００６３】
共通割込みハンドラ１７４は、発生した割込みを割込みハンドラ１５２，153に対して振り分ける役割を有する。このため、共通割込みハンドラ１７４は、現在実行しているオペレーティングシステムが事務処理ＯＳ１１０であるかリアルタイムＯＳ１１１であるかを記憶する領域として、実行ＯＳ記憶変数２１０を所有する。例えば、図１０に示した時点で事務処理ＯＳが処理を実行しているものと仮定すると、この場合、実行ＯＳ記憶変数２１０には、「事務処理ＯＳ」が記憶されている。勿論、実行ＯＳ記憶変数２１０が文字列「事務処理ＯＳ」を記憶することは非常に非効率的であるため、例えば、
・事務処理ＯＳ→０
・リアルタイムＯＳ→１
といった整数形式で記憶するとよい。共通割込みハンドラ１７４は、更に、発生した割込みがいずれのオペレーティングシステムに対応するかを示す割込み対応テーブル２１１を有する。割込み対応テーブル２１１は、個々の割込みがどちらのオペレーティングシステムで処理されるべきかを示す対応表である。本実施例では、図４に示したように、３２種類の割込み要因が存在する。このため、割込み対応テーブル２１１も３２個のエントリ(０〜３１)から構成される。図１０の例では、割込み要因０が事務処理ＯＳで、割込み要因１がリアルタイムＯＳで，…，割込み要因３１がリアルタイムＯＳでというように、いずれのオペレーティングシステムで処理が実行されるべきかが定義されている。なお、効率上、割込み対応テーブル２１１の内容も、実行ＯＳ記憶変数２１０と同様、文字列形式ではなく、整数形式で記憶すべきである。
【００６４】
さて、計算機の種類によっては、一つの入出力機器を二つのオペレーティングシステムが共用することもある（例えば、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の両者がディスプレイに文字や映像を出力する場合）。このようなシステムを実現するためには、割込み振り分け先のオペレーティングシステムを動的に変更できることが必要となる。本実施例で、振り分け先オペレーティングシステムを固定化するのではなく、割込み対応テーブル２１１から入手しているのは、このためである。割込み対応テーブル２１１の内容を入出力機器の使用状況によって変更することにより、割込みの振り分け先を動的に変更することができる。
【００６５】
共通割込みハンドラ１７４は、実行ＯＳ記憶変数２１０を用いて現在実行しているオペレーティングシステムの種類を判定し、これが割込み対応テーブル211から得られた振り分け先オペレーティングシステムに一致しなければ、ＯＳコンテクスト切り替えモジュール１７６に切り替えを依頼する。オペレーティングシステムが一致するか、オペレーティングシステム切り替え終了後、該当するオペレーティングシステムの割込みハンドラに処理を依頼する。なお、実行ＯＳ記憶変数２１０はＯＳコンテクスト切り替えモジュール１７６からも参照される。このように、オペレーティングシステム切り替えプログラム１１８内の各モジュールが有する内部構造は、個々のモジュールによって占有されるものとは限らず、各モジュールが必要に応じて共用できる。
【００６６】
ＯＳコンテクスト切り替えモジュール１７６は、優先順位比較の結果、若しくは、割込み発生の結果、オペレーティングシステムを切り替えなければならない場合に起動される。二つのオペレーティングシステムを切り替えるため、これらの実行環境（すなわち、レジスタ値）を保存しておくための領域を所有しなければならない。ここでは、事務処理ＯＳの実行環境を保存するための領域として、事務処理ＯＳ用保存コンテクスト２１２，リアルタイムＯＳの実行環境を保存するための領域として、リアルタイムＯＳ用保存コンテクスト２１３を用意する。ＯＳコンテクスト切り替えモジュール１７６は、現在実行しているオペレーティングシステムに対応する保存コンテクストに実行環境を保存し、次に、もう一方の保存コンテクストから実行環境を読み出して、プロセッサ１００のレジスタに設定する。これにより、オペレーティングシステムの切り替えを実施できる。
【００６７】
ＯＳ間通信機能モジュール１７５は、二つのオペレーティングシステム上のタスクが相互に通信・協調するためのプログラムである。ここでは、事務処理ＯＳ１１０，リアルタイムＯＳ１１１の両者が使用できる共有メモリ２１８、並びに、オペレーティングシステム間で排他制御を行うためのロック取得モジュール２１９，ロック解放モジュール２２０が存在するとしている。共有メモリ218は、メモリ１０１の一部であり、両オペレーティングシステムから参照を行える領域である。共有メモリ２１８以外のメモリは、基本的に、事務処理ＯＳ用領域，リアルタイムＯＳ用領域，オペレーティングシステム切り替えプログラム用領域に分割され、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１，オペレーティングシステム切り替えプログラム１１８に占有されて使用される。二つのオペレーティングシステム上のタスクが共有メモリ２１８を使用する場合、通常、排他制御を行って共有メモリ２１８上のデータの一貫性を保つ。アプリケーションプログラムがオペレーティングシステム間に跨る排他制御を行う場合、ロック取得モジュール２１９，ロック解放モジュール２２０が提供する機能を利用する。
【００６８】
このとき、優先順位逆転現象と呼ばれる状況について注意しておかなければならない。優先順位逆転現象とは、一般に、以下の状態を意味する。
【００６９】
（１）低優先順位であるタスクαが最初に起動されてロックを取得する。
【００７０】
（２）次に高優先順位であるタスクβが起動されてロック待ち状態に移行する。
（３）次に中優先順位であるタスクγが起動され、タスクα（低優先順位）からタスクγ（中優先順位）への切り替えが行われる。
【００７１】
このとき、タスクγの実行によってタスクαの実行が妨げられ、結果的に、高優先順位タスクβがロックを取得するまでの時間が延びてしまうことになる。優先順位逆転現象は、通常、優先順位上昇方式または優先順位継承方式を用いて解決する。
【００７２】
優先順位上昇方式は、ロック取得を行ったタスクの優先順位を一定のレベルまで高くする方式である。これによって、ロック取得を行ったタスクαの優先順位が一時的にタスクγ（中優先順位）よりも高くなり、タスクγが起動されても、ロック解放まではタスクαが実行される。この後、高優先順位であるタスクβがロックを取得し、処理を継続することになる。
【００７３】
優先順位継承方式は、前記優先順位上昇方式を変更して柔軟性を持たせたものである。優先順位継承方式では、ロック待ち状態に移行したタスク（例では、タスクβ）の優先順位がロックを取得しているタスク（タスクα）よりも高ければ、この優先順位をロック取得中タスクに継承させる方式である。ここでは、ロック取得中の間だけ、タスクαがタスクβの優先順位を受け継ぐことになる。低優先順位のタスク同志で排他制御を行う場合など、必ずしも優先順位を一定レベルまで上昇させる必要がない場合もあり、優先順位継承方式は、このような状況にも対処できる方式である。
【００７４】
本実施例で述べるロック取得モジュール２１９，ロック解放モジュール２２０は、このような優先順位上昇もしくは優先順位継承方式をオペレーティングシステム間で実施できるものとする。オペレーティングシステム間での優先順位上昇・継承は、正規化優先順位を用いて行われる。
【００７５】
以降、図１０で示したモジュールのうち、ＯＳコンテクスト切り替えモジュール１７６，共通割込みハンドラ１７４，割込みハンドラ１５２，ロック取得モジュール２１９，ロック解放モジュール２２０の処理フローの説明を行う。割込みハンドラ１５３に関しては、割込みハンドラ１５２と同様の処理フローを有するため、説明を省略する。
【００７６】
図１１はＯＳコンテクスト切り替えモジュール１７６の処理フローである。
【００７７】
ＯＳコンテクスト切り替えモジュール１７６は、オペレーティングシステムを切り替えなければならない場合にのみ呼び出され、切り替えが必要か否かのチェックは呼出し前に行われている。したがって、最初に、どちらのオペレーティングシステムへ切り替えなければならないかのみをチェックする（処理２３０）。ここで、事務処理ＯＳ１１０からリアルタイムＯＳ１１１への切り替えを行う場合（現実行オペレーティングシステムが事務処理ＯＳ１１０であって、リアルタイムＯＳ１１１の優先順位が高くなった場合）、事務処理ＯＳ用保存コンテクスト２１２内に使用中レジスタの値を退避する（処理２３１）。次に、リアルタイムＯＳ用保存コンテクスト２１３から実行環境を復帰して、レジスタに設定することにより（処理２３２）、以前退避した状態からリアルタイムＯＳ１１１を再実行させることができる。リアルタイムＯＳ１１１から事務処理ＯＳ１１０への切り替えを行う場合、逆に、リアルタイムＯＳ用保存コンテクスト２１３に使用中レジスタの値を退避し（処理２３３）、次に、事務処理ＯＳ用保存コンテクスト２１２からレジスタを復帰する（処理２３４）。いずれの場合においても、最後に、切り替え後のオペレーティングシステムの種類を実行ＯＳ記憶変数２１０に書き込む（処理２３５）。
【００７８】
図１２には、共通割込みハンドラ１７４の処理フローを示している。一般に、単一のオペレーティングシステムによって制御される計算機では、一旦、全ての割込みを割込みハンドラと呼ばれるモジュールが処理し、次いで、各プログラムに振り分ける。しかしながら、本実施例で説明するような複数個のオペレーティングシステムを動作させる計算機では、この更に前に、共通割込みハンドラが全ての割込みを受け付け、これを対応するオペレーティングシステムの割込みハンドラに振り分ける形となる。各オペレーティングシステムに割込みを振り分けるに当たって、割込み発生時に、割込み対象とは別のオペレーティングシステムが処理を実行していることもある。この場合、割込みに対応するオペレーティングシステムに切り替える必要があり、共通割込みハンドラはこのような役割も有することになる。
【００７９】
共通割込みハンドラ１７４は、割込み発生後、第一に、実行ＯＳ記憶変数210の内容を取り出して、現在実行中のオペレーティングシステムが事務処理OS110であるかリアルタイムＯＳ１１１であるかをチェックする（処理２４０）。次に、割込み対応テーブル２１１を用いて、発生した割込みがいずれのオペレーティングシステムに対応しているかを入手する（処理２４１）。例えば、図１０の割込み対応テーブル２１１を用いるとすると、割込み「０」が発生した場合には事務処理ＯＳ１１０，割込み「１」が発生した場合にはリアルタイムＯＳ１１１，…，割込み「３１」が発生した場合にはリアルタイムＯＳ１１１、というように対応するオペレーティングシステムを入手することができる。ここで、割込み対象オペレーティングシステムが実行中オペレーティングシステムに等しいか否かをチェックする（処理２４２）。
【００８０】
発生した割込みが現在実行中のオペレーティングシステムに対するものでなければ、一旦、オペレーティングシステムの切り替えを行わなければならない。この切り替え処理は、ＯＳコンテクスト切り替えモジュール１７６に依頼することによって行う（処理２４３）。次に割込み対象オペレーティングシステムが事務処理ＯＳ１１０であるかリアルタイムＯＳ１１１であるかをチェックし（処理２４４）、対象が事務処理ＯＳ１１０であれば、事務処理ＯＳの割込みハンドラ１５２を起動する（処理２４５）。リアルタイムＯＳ１１１への割込みが発生していれば、リアルタイムＯＳの割込みハンドラ１５３を起動することになる（処理２４６）。一般に、割込みハンドラ１５２，１５３は、割込み処理によってタスク切り替えを行わなければならないとき、リスケジューラ１５４，１５５を呼び出し、共通割込みハンドラ１７４に制御を戻すことはない。しかし、タスク切り替えが発生しない場合、そのまま割込みハンドラの処理を終了する。このとき、割込みハンドラ１５２，１５３は、共通割込みハンドラへ制御を戻し（図１３で後述）、共通割込みハンドラは処理２４７から動作を再開する。処理２４７は、割込み発生時にオペレーティングシステムを切り替えたかどうかをチェックする処理である。処理２４３によってオペレーティングシステムを切り替えた場合、ここで再び、オペレーティングシステムを切り替え、元の実行環境に戻す必要がある。タスク切り替えが発生しないということは、両オペレーティングシステムの正規化優先順位が変化しなかったということを意味し、割込み発生前の実行状態に戻さなければならないわけである。このため、もう一度ＯＳコンテクスト切り替えモジュール１７６に依頼して、切り替え処理を実行させる(処理２４８)。
【００８１】
各オペレーティングシステムの割込みハンドラがリスケジューラ１５４，155を実行した場合、前述したように、共通割込みハンドラの処理２４７に制御が戻ることはない。この場合、リスケジューラ１５４，１５５が新たなタスクの優先順位を優先順位変換モジュール１２２，１２３に通知してくる。これによって、優先順位比較モジュール１２４がオペレーティングシステムの切り替えを行うか否かの判定を行う。
【００８２】
なお、共通割込みハンドラ１７４の構成を図２８のように変更することも可能である。図２９に示した共通割込みハンドラ１７４は、図１０に示した共通割込みハンドラの構成要素の他に、割込み優先順位対応テーブル３８０を所有する。割込み優先順位対応テーブル３８０は、割込みハンドラがいかなる正規化優先順位で動作しなければならないかをしめす対応表である。図２９の例では、割込み要因０に対応する割込みハンドラは、正規化優先順位２５５で動作しなければならず、また、割込み要因３１に対応する割込みハンドラは、正規化優先順位224で動作しなければならない。共通割込みハンドラ１７４は各オペレーティングシステムの割込みハンドラを起動する際に、割込み優先順位対応テーブル３８０にしたがって、当該オペレーティングシステムの正規化優先順位を更新し、また、割込みハンドラ終了後、元の正規化優先順位を復帰させる。なお、この例では共通割込みハンドラ１７４が割込み優先順位対応テーブル３８０を有するものとしているが、割込み優先順位対応テーブル３８０を優先順位変換モジュール１２２，１２３内に設け、共通割込みハンドラ１７４から優先順位変換を依頼する構成を採ることも可能である。
【００８３】
なお、図２９のように、割込みに対しても正規化優先順位を割当てることができるのならば、各オペレーティングシステムのあらゆる動作状態にも正規化優先順位を割当てることができる。例えば、オペレーティングシステムは、一般に以下の四種類の動作状態を持つ。
【００８４】
（１）idle状態
（２）タスク実行状態
（３）オペレーティングシステム自体の処理状態（例えば初期化処理）
（４）割込み処理状態
これら全てに正規化優先順位を割当てることも可能である。この場合、一般に考えて、割込み処理状態が最も優先して動作しなければならず、最も高い正規化優先順位を割当てる。次にオペレーティングシステム自体の処理状態，タスク実行状態，idle状態の順に正規化優先順位を割当てていくことになる。
【００８５】
図１３は共通割込みハンドラ１７４から呼び出される事務処理ＯＳの割込みハンドラ１５２の処理フローを示したものである。第一に、使用中レジスタを割込みスタック２１４に退避し（処理２５０）、割込み処理を実行する(処理２５１)。ここで、オペレーティングシステムがリスケジューリング中か否か（すなわち、リスケジューラ１５４の処理実行中か否か）をチェックする（処理２５２）。リスケジューリング中とは、次に実行すべきタスクを選択している最中であり、実際にはタスクを実行していないことを意味する。したがって、オペレーティングシステムの処理を単純化させるならば、この場合、再びリスケジューリングを最初からやり直せば良いことになる。すなわち、リスケジューリング中であると判定した場合、割込みスタックの退避レジスタを破棄し（処理２５７）、リスケジューラ１５４を最初から起動する（処理２５８）。なお、リスケジューリング中に割込みが発生しても、実行すべきタスクを新たに選択し直す必要がない場合もある。本方式は、この状況でもリスケジューリングを最初から行うことになり、効率的でないこともある。このため、リスケジューリング中に発生し、リスケジューラ１５４の実行に影響を与える処理（例えば、タスク起動・終了など）を待ち行列などに登録しておく方法を用いることもできる。この場合、リスケジューラ１５４の終了前や優先順位通知モジュール１２０内で、該待ち行列に登録しておいた処理を纏めて実行する。この方式を採用すると、割込み発生のたびに途中まで実行していたリスケジューリングをやり直す必要が無い。しかしながら、当該待ち行列に登録していた処理を纏めて実行した後、これによってリスケジューリングが再び必要となるか否かを再チェックしなければならない。
【００８６】
なお、本実施例では、単純化のため、前者の方式で説明を行う。しかし、後者の方式を用いる場合、
（ａ）リスケジューリング中か否かを示すフラグ
（ｂ）処理待ち行列
を用意すればよい。オペレーティングシステムが提供するシステムコールなどにおいて、リスケジューラ１５４の実行に影響を与える処理を、リスケジューリング中であれば、該待ち行列に登録する。更に、リスケジューラ１５４の処理フロー中に、該待ち行列に登録された処理を一括して実行するモジュールを挿入する。
【００８７】
割込みハンドラ１５２がリスケジューリング中でないと判定した場合、当該オペレーティングシステムはその時点で何らかのタスクを実行している。このため、第一に、タスク切り替えが必要か否かを判定する（処理２５３）。タスク切り替えが必要なければ（現実行タスクが最高優先順位であり、かつ、実行可能であれば）、このまま、割込みハンドラ１５２の処理を終了する。このため、割込みスタック２１４上に退避しておいたレジスタ値を復帰し（処理２５４）、共通割込みハンドラへ制御を戻す（処理２５５）。タスク切り替えが必要であると判定した場合、割込みスタック２１４上に退避したレジスタの値をタスク管理テーブルにコピーし（処理２５６）、割込みスタック上の退避レジスタを破棄する（処理２５７）。この後、リスケジューラ１５４を起動する（処理２５８）。なお、プロセッサ１００に、メモリ１０１上データの参照を行って、同時に、割込みスタックポインタ２１６の値を増減できる機能が備わっていれば、処理２５６と処理２５７を纏めて実行することができる。
【００８８】
次に、ロック取得モジュール２１９，ロック解放モジュール２２０の処理フローを説明する。ここでは、優先順位上昇方式を用いる例を説明し、優先順位継承方式を使用する実施例については後述する。なお、ここでは、ロック取得・解放を要求したタスク、および、それを管理するオペレーティングシステムを自タスク，自オペレーティングシステムと呼び、もう一方のオペレーティングシステムを別オペレーティングシステムと呼んでいる。
【００８９】
図１４が優先順位上昇方式を用いるロック取得モジュール２１９の処理フローである。ロック取得モジュール２１９は、第一に、別オペレーティングシステムのタスクがロック取得中か否かをチェックし（処理２６０）、取得中でなければ、自オペレーティングシステムがロックの所有者であるように設定する（処理２６１）。別オペレーティングシステムのタスクがロック取得中であれば、ロックが解放されるまでタスクを待ち状態に移行させる（処理２６３）。このとき、別オペレーティングシステムを優先して実行させ、当該ロックを速やかに解放させるようにしなければならない。このため、優先順位比較モジュール１２４内に記憶されている別オペレーティングシステムの正規化優先順位を自オペレーティングシステムより高くなるように変更する（処理２６２）。ここで処理２６３においてタスクを待ち状態に移行させると、自オペレーティングシステムでリスケジューラが起動される。これにより、リスケジューラから、優先順位通知モジュール，優先順位変換モジュール，優先順位比較モジュールと順次呼び出され、正規化優先順位を高く変更した別オペレーティングシステムに切り替えが行われることになる。
【００９０】
図１５が優先順位上昇方式を用いる場合のロック解放モジュール２２０の処理フローである。第一に、自己が所有するロックを解放する（処理２７０）。次に、別オペレーティングシステムがロック取得待ちか否かをチェックする（処理２７１）。ロック取得待ちでなければ、正規化優先順位の上昇は行われていない。このため、このままロック解放モジュール２２０の処理を終了する。しかし、別オペレーティングシステムがロック取得待ちであれば、優先順位逆転現象を解決するため、正規化優先順位の上昇が行われている筈である。したがって、自オペレーティングシステムの正規化優先順位を元の値に戻し（処理２７２）、次に、別オペレーティングシステムでロック取得待ちとなっているタスクを実行可能状態に移行させる（処理２７３）。ロック取得待ちタスクを実行可能とすることによりタスク切り替えが発生すれば、別オペレーティングシステムのリスケジューラが起動され、前述のロック取得モジュールの場合と同様、最終的に、優先順位比較モジュール１２４が実行される。これにより、元の正規化優先順位を用いてオペレーティングシステムの重要性が比較され、より高い正規化優先順位を有するオペレーティングシステムが選択される。
【００９１】
次に、優先順位継承方式を用いる例を説明する。この場合、図１６に示すように、各オペレーティングシステムは、正規化優先順位にしたがってタスクの優先順位を変更する優先順位設定モジュール２８０，２８１を装備しなければならない。また、優先順位変換モジュール１２２，１２３は、優先順位を正規化優先順位に変換する機能のほか、正規化優先順位を優先順位に変換する機能を搭載しなければならない。このため、優先順位変換モジュール１２２，１２３は、正規化優先順位をインデクスとし、各オペレーティングシステムの優先順位を内容とする優先順位逆変換テーブル２８２，２８３を有する。
【００９２】
オペレーティングシステムは、一般に、システムコールとして、タスクの優先順位を変更する機能を有している。優先順位設定モジュール２８０，２８１は、与えられた正規化優先順位を各オペレーティングシステムに対応する優先順位に変換し、タスク優先順位変更システムコールなどを用いてタスクの優先順位を変更する。優先順位逆変換テーブル２８２，２８３は、優先順位設定モジュール２８０，２８１の機能をサポートする役割を有する。本実施例では、正規化優先順位が０〜２５５であるため、優先順位逆変換テーブル２８２，２８３は、256個のエントリを有する配列である。また、事務処理ＯＳ１１０の優先順位の範囲が０〜３１であるため、優先順位逆変換テーブル２８２の各配列要素は、０〜３１の範囲のいずれかの整数を有し、かつ、以下の不等式を満足する（配列の名称をrevBusinessとする）。
【００９３】
ｉ＞ｊ⇒revBusiness［ｉ］≧revBusiness［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
リアルタイムＯＳ１１１は優先順位０〜２５５を有し、かつ、優先順位の数値が小さいほど優先順位が高いという特徴を有するため、優先順位逆変換テーブル２８３の各配列要素は、０〜２５５までのいずれかの整数を有し、かつ、以下の不等式を満足する（配列の名称をrevRealtimeとする）。
【００９４】
ｉ＞ｊ⇒revRealtime［ｉ］≦revRealtime［ｊ］
（ただし、０≦ｉ，ｊ≦２５５）
さて、本実施例では、正規化優先順位の数値が０〜２５５、リアルタイムＯＳの優先順位の数値が０〜２５５であるとしているため、正規化優先順位とリアルタイムＯＳの優先順位との対応付けを一対一に行うことができている。したがって、優先順位変換テーブル１７１から一意に優先順位逆変換テーブル２８３を導出することができる。しかしながら、事務処理ＯＳの優先順位の数値は０〜３１であるため、優先順位逆変換テーブル２８２を一意に定めることはできない。この場合、例えば、正規化優先順位「１」に対応する事務処理ＯＳの優先順位を、優先順位変換テーブル１７０から導き出すことができない。このため、一意に定めることのできない正規化優先順位に対しては、上記不等式を満たすように、事務処理ＯＳの優先順位を適宜に定めている。
【００９５】
優先順位変換モジュール１２２のうち、優先順位逆変換機能の処理フローについて図１７に示した。ここでは、指定正規化優先順位に対応する事務処理ＯＳの優先順位を優先順位逆変換テーブル２８２から取り出し（処理２９０）、当該優先順位を優先順位設定モジュール２８０に通知する（処理２９１）。優先順位変換モジュール１２３も同様の優先順位逆変換機能を有する。
【００９６】
これに対する優先順位設定モジュール２８０の処理フローを図１８に示す。優先順位設定モジュール２８０は、第一に、優先順位変換モジュール１２２に依頼して、正規化優先順位から事務処理ＯＳの優先順位への変換を行わせる（処理２９２）。次に、事務処理ＯＳの優先順位変更システムコールなどを用いてタスクの優先順位を変更させる（処理２９３）。リアルタイムＯＳ１１１における優先順位設定モジュール２８１の処理も同様である。
【００９７】
次に、これらの優先順位逆変換機能，優先順位設定モジュールを用いた優先順位継承方式の実現方法について述べる。
【００９８】
図１９は優先順位継承方式を用いるロック取得モジュール２１９の処理フローである。ロック取得モジュール２１９は、第一に、別タスクがロック取得中か否かをチェックし（処理３００）、取得中でなければ、自タスクがロックの所有者であるように設定する（処理３０１）。別タスクがロック取得中であれば、ロックが解放されるまでタスクを待ち状態に移行させる必要がある（処理３０４）。このとき、ロック取得中タスクを優先して実行させ、当該ロックを速やかに解放させるようにしなければならない。ロック取得中タスクの正規化優先順位と自タスクの正規化優先順位を比較し（処理３０２）、ロック取得中タスクの正規化優先順位が低ければ、当該タスクに自タスクの優先順位を継承させる(処理３０３)。優先順位継承は、ロック取得中タスクを実行するオペレーティングシステムの優先順位設定モジュールに対し、自タスクの正規化優先順位を指定して優先順位設定を依頼することによって行うことができる。ロック取得中タスクの正規化優先順位が既に自タスクの正規化優先順位より高ければ、優先順位継承を行う必要はなく、直ちにタスクを待ち状態に移行させることができる。
【００９９】
図２０は優先順位継承方式を用いるロック解放モジュール２２０の処理フローである。第一に、自己が所有するロックを解放する（処理３１０）。次に、別タスクがロック取得待ちか否かをチェックする（処理３１１）。ロック取得待ちでなければ、正規化優先順位継承が行われていないことになり、このままロック解放モジュール２２０の処理を終了する。しかし、別タスクがロック取得待ちであれば、正規化優先順位継承が行われている筈である。したがって、優先順位設定モジュールに依頼して自タスクの正規化優先順位を元の値に戻し(処理３１２)、次に、ロック取得待ちとなっているタスクを実行可能状態に移行させる（処理３１３）。
【０１００】
本実施例では説明を省略したが、ロック取得モジュール２１９，ロック解放モジュール２２０などを実行している途中に割込みが発生し、タスク切り替えなどが起こると、ロック所有者を示すデータなどに不整合が生じる可能性がある。したがって、通常、これらの処理実行中には、割込みマスク機能によって割込み発生を抑止する。
【０１０１】
図１６〜図２０に示したプログラムモジュール，処理フローにより、オペレーティングシステム間での排他制御において、優先順位継承方式を用いることが可能となる。なお、実際には、図１９，図２０に示した処理フローを用いることにより、一つのオペレーティングシステム内で正規化優先順位の継承を行うことも可能である。
【０１０２】
図２１に、割込みマスクレベル計算モジュール１７７の内部構造を示した。割込みマスクレベル計算モジュール１７７は、正規化優先順位を割込みマスクレベルに変換し、一定以上の正規化優先順位であれば、特定の割込みをマスクする機能である。これは、ある一定以上の正規化優先順位を有するタスクは、割込み処理よりも優先して実行されなければならないという考えに基づく機能である。したがって、システムコールなどで割込みをマスクする機能が備わっていれば、本機能が存在しなくても十分システムは成立する。ただし、割込みマスクレベル計算モジュール１７７の利点として、正規化優先順位が一定値以上になれば、自動的に割込みマスクを実行することがある。
【０１０３】
割込みマスクを実行するため、割込みマスクレベル計算モジュール１７７は、割込みマスク変換テーブル３２０を所有する。割込みマスク変換テーブル３２０は、正規化優先順位から割込みマスク値を入手するための変換テーブルである。本実施例では、図４に示したように、３２種類の割込み要因を個別にマスクできる計算機アーキテクチャを対象としているため、割込みマスク変換テーブル320の各エントリは３２ビット長データを有する。しかしながら、図３に示したように、４ビットの割込みマスクレベルを使用すると、割込みマスク変換テーブル３２０の各エントリを４ビット長に縮少させることができる。ここで、図２１に示した実施例では、例えば、正規化優先順位「０」に対応する割込みマスク値が0x00000000であり、正規化優先順位「２５５」に対応する割込みマスク値は 0xffffffffである。これは、正規化優先順位が「０」であれば全ての割込みを許可し、最高の正規化優先順位でシステムが動作しているならば、全ての割込みをマスクすることを意味する。優先順位比較モジュール１２４が割込みマスクレベル計算モジュール１７７に対して、現在実行中オペレーティングシステムの正規化優先順位を通知することにより、必要な割込みマスクを自動的に行うことができる。
【０１０４】
図２２に割込みマスクレベル計算モジュール１７７の処理フローを示す。ここでは、第一に、正規化優先順位に対応する割込みマスク値を割込みマスク変換テーブル３２０から取り出す（処理３３０）。次に、入手した割込みマスク値を割込みマスクレジスタ１４３などに設定して、割込みマスクを実施する（処理331)。
【０１０５】
以上に本発明の第一の実施例について説明した。本実施例を用いることにより、各オペレーティングシステムが実行しているタスクの優先順位にしたがって、オペレーティングシステムの切り替えを行うことができる。本実施例では、各オペレーティングシステム内に優先順位通知モジュールを組み込み、リスケジューリングのたびに優先順位の変更を通知するように改造しなければならない。しかしながら、市販オペレーティングシステムを使用する場合など、このような改造を施せないことも多い。以下、これに対処する本発明の第二の実施例について説明する。
【０１０６】
図２３は本発明の第二の実施例を示した構成図である。事務処理ＯＳ１１０，リアルタイムＯＳ１１１は、それぞれ、現在実行中タスクの優先順位（実行優先順位３４０，３４１）を保持するものとする。各オペレーティングシステムは、図５に示す実行可能待ち行列１５０，１５１の先頭に存在するタスク管理テーブル１６２，１６３内に格納されている優先順位の数値が実行優先順位３４０，３４１となる。また、実行可能待ち行列が優先順位毎に複数個存在する場合には、一般に、現時点で最高優先順位の実行可能待ち行列がどこに存在するかを示すポインタや、最高優先順位の数値そのものを示す変数（優先順位保持変数）を用意することが多い。前者の場合には、該ポインタから実行可能待ち行列を辿り、タスク管理テーブルを参照することにより、後者の場合には、該優先順位保持変数自体を読み出すことにより、実行優先順位３４０，３４１を入手できる。
【０１０７】
オペレーティングシステム切り替えプログラム１１８内には、新たに、優先順位監視モジュール３４４を設ける。これ以外のモジュールである、優先順位変換モジュール１２２，１２３，優先順位比較モジュール１２４，共通割込みハンドラ１７４，ＯＳ間通信機能モジュール１７５，ＯＳコンテクスト切り替えモジュール１７６，割込みマスクレベル計算モジュール１７７は、第一の実施例で説明した内容と同様の構成，処理フローを有する。各オペレーティングシステム内には、優先順位通知モジュール１２０，１２１は存在しない。
【０１０８】
優先順位監視モジュール３４４は、事務処理ＯＳ実行優先順位記憶値３４２とリアルタイムＯＳ実行優先順位記憶値３４３を所有する。優先順位監視モジュール３４４は定期的に起動され、各オペレーティングシステムの実行優先順位340,３４１を監視する。ここで、記憶している実行優先順位３４２または３４３と、現在の実行優先順位３４０または３４１が異なっていれば、優先順位が変化したと認識して、優先順位変換モジュール１２２または１２３に新たな実行優先順位を通知する。
【０１０９】
優先順位監視モジュール３４４の処理フローを図２４に示す。第一に、事務処理ＯＳの実行優先順位３４０を読み出して、これを事務処理ＯＳ実行優先順位記憶値３４２と比較する（処理３５０）。これにより、事務処理ＯＳの優先順位が変化したか否かを認識できる。優先順位が変化していなければ何も実行せず、処理３５３に移行する。優先順位が変化していれば、事務処理ＯＳの実行優先順位３４０を事務処理ＯＳ実行優先順位記憶値３４２に登録し（処理３５１）、次に、当該優先順位を事務処理ＯＳの優先順位変換モジュール１２２に通知する（処理３５２）。リアルタイムＯＳ１１１の実行優先順位変化に対しても同様の処理を行う。第一に、リアルタイムＯＳの実行優先順位３４１とリアルタイムＯＳ実行優先順位記憶値３４３との比較を行い（処理３５３）、優先順位の変化が無ければ処理を終了する。優先順位が変化していれば、リアルタイムＯＳの実行優先順位３４１をリアルタイムＯＳ実行優先順位記憶値３４３に登録し(処理３５４)、これをリアルタイムＯＳの優先順位変換モジュール１２３に通知する（処理
３５５）。
【０１１０】
なお、優先順位変換モジュールに優先順位を通知した結果、オペレーティングシステムの切り替えが行われると、優先順位監視モジュール３４４に制御が戻ってこないことに注意しなければならない。このため、図２４の監視方法は、常に事務処理ＯＳ１１０の優先順位変化を優先して監視するものであると言える。両オペレーティングシステムの監視を対等なものとするためには、優先順位監視モジュール３４４の起動回数を計数しておき、
（１）起動回数が奇数であれば事務処理ＯＳ１１０の優先順位変化を監視し、
（２）起動回数が偶数であればリアルタイムＯＳ１１１の優先順位変化を監視する
といった処理フローなどに改める必要がある。
【０１１１】
ここで、優先順位監視モジュール３４４は、「定期的に」起動され、優先順位の変化を監視することに注意しなければならない。定期的な処理を実現するためには、タイマ割込みによって優先順位監視モジュール３４４を起動すればよい。ここでは、タイマ割込み，外部割込みを含む全ての割込みが共通割込みハンドラ１７４で一括処理されることに着目し、共通割込みハンドラ１７４内に優先順位監視モジュール３４４を埋め込む方法について説明する。図２５が優先順位監視モジュール３４４を埋め込んだ共通割込みハンドラ１７４の処理フローである。図中、処理２４０〜２４８は全て図１２に等しい。優先順位監視モジュール344の起動（処理３６０）はオペレーティングシステム切り替えを行う可能性がある。このため、割込みハンドラの実行（処理２４５，２４６）後に埋め込まなければならない。割込みハンドラ１５２，１５３が共通割込みハンドラ１７４に制御を戻すと、自動的に優先順位変化が監視され、必要に応じてオペレーティングシステムの切り替えが行われる。優先順位監視モジュール３４４がオペレーティングシステムの切り替えを行う必要がないと判断した場合、そのまま共通割込みハンドラ１７４の処理を終了する。
【０１１２】
なお、本発明の第二の実施例では、リスケジューリング直後の優先順位変化を優先順位変換モジュールに通知する手段が存在しない。すなわち、一定間隔毎に優先順位の変化をチェックするのであって、優先順位の変化に直ちに反応してオペレーティングシステムを切り替えることにはならない。このため、本発明の第二の実施例は、オペレーティングシステム内部の改造を伴わない計算機を実現できるが、第一の実施例に比べ、切り替え効率的に劣るという特徴がある。
【０１１３】
本発明の第二の実施例は、両オペレーティングシステムの内部を改造しないという条件を満たすものであるが、例えば、リアルタイムＯＳ１１１は改造できるが、事務処理ＯＳ１１０を改造することができない、といった条件が発生することもある。この場合、本発明の第三の実施例として、リアルタイムＯＳ１１１内部に優先順位通知モジュール１２１を搭載し、優先順位監視モジュール３４４は事務処理ＯＳ１１０の優先順位変化のみを監視するといった計算機を実現することも可能である（図２６）。
【０１１４】
また、リスケジューラ内部に優先順位通知モジュールを組み込むのではなく、各オペレーティングシステムのタイマ割込み処理モジュール内部など、定期的に起動される部分に優先順位通知モジュールを組込み、優先順位監視モジュール
３４４の代用とすることも可能である。
【０１１５】
以上説明した本発明を図２７に示す車載ナビゲーションシステムに適用した場合、処理時間の長い経路探索タスクが動作している場合でもユーザからの入力を受け付けることができる。つまり、この場合はインタフェースタスクに対して、経路探索タスクよりも高い正規化優先順位を与える。このとき、ユーザがボタンを押してインタフェースタスクが動作すれば、より正規化優先順位の高いタスクを動作させる事務処理ＯＳに切り替えが行われ、結果として、処理の長い経路探索タスクが動作している場合にもインターフェースタスクが実行されることになる。
【０１１６】
更に、複数のオペレーティングシステムを実行する仮想計算機においても、本発明を適用することにより異なった優先順位体系を有しているオペレーティングシステムを、実行すべきタスクの優先順位にしたがって実行させることができる。
【０１１７】
以上より、本発明によれば事務処理用ＯＳのユーザインタフェースとリアルタイムＯＳの信頼性を併せ持つ計算機を構築することができる。
【０１１８】
前記第一乃至第三の実施例は、全て、オペレーティングシステム切替えプログラム１１８の内部で優先順位の変換を行う構成を有している。しかしながら、優先順位変換モジュール１２２，１２３は、それぞれ、事務処理ＯＳ１１０，リアルタイムＯＳ１１１に個別に対応しているため、これらを、各オペレーティングシステム内部に搭載しても良い。このような変更を加えた第四の実施例を図２９に示す。
【０１１９】
本実施例では、第一に、優先順位変換モジュール１２２，１２３が各オペレーティングシステムでの優先順位を正規化優先順位に変換する。これを受けて、優先順位通知モジュール１２０，１２１が、優先順位比較モジュール１２４に対して各オペレーティングシステムの正規化優先順位を通知する。
【０１２０】
この実施例では、事務処理ＯＳ１１０，リアルタイムＯＳ１１１とオペレーティングシステム切替えプログラム１０８とのインタフェースが全て正規化優先順位によって行われる。前記第一乃至第三の実施例では、実行可能タスクが存在する場合には、タスクの優先順位を通知し、実行可能タスクが存在しない場合には、idle状態であることを通知していた。これらの場合、idle状態や、オペレーティングシステム自体が何らかの処理を実行しなければならない状態を、自由に正規化優先順位にマッピングすることができない。本実施例（第四実施例）では、各オペレーティングシステム内で優先順位を正規化優先順位に変換するため、タスク実行中以外の状態も自由に正規化優先順位にマッピングすることが可能となる。
【０１２１】
【発明の効果】
本発明によれば、複数個のオペレーティングシステムを単一プロセッサで動作させる計算機において、各オペレーティングシステムが実行するタスクの優先順位にしたがって、オペレーティングシステムの切り替えを行うことができ、より重要なタスクを優先して実行させることができる。また、本発明では、優先順位変換モジュールによって正規化優先順位に変換し、これによってオペレーティングシステム間の優先順位比較を行うため、異なった優先順位体系を有するオペレーティングシステム同士を実行させる計算機であっても、リアルタイム性・効率性を損なうことがない。
【図面の簡単な説明】
【図１】本発明の第一の実施例におけるシステム構成を示す図である。
【図２】計算機のハードウェア構成を示す図である。
【図３】割込みレベルマスク機能を装備する場合のステータスレジスタを示す図である。
【図４】個別割込みマスク機能を装備する場合のステータスレジスタを示す図である。
【図５】オペレーティングシステム内部構成を詳細に示す図である。
【図６】オペレーティングシステム切り替えプログラム内部構成を詳細に示す第一の図である。
【図７】リスケジューラの処理フローを示す図である。
【図８】優先順位変換モジュールの処理フローを示す図である。
【図９】優先順位比較モジュールの処理フローを示す図である。
【図１０】オペレーティングシステム切り替えプログラム内部構成を詳細に示す第二の図である。
【図１１】ＯＳコンテクスト切り替えモジュールの処理フローを示す図である。
【図１２】共通割込みハンドラの処理フローを示す図である。
【図１３】割込みハンドラの処理フローを示す図である。
【図１４】優先順位上昇方式におけるロック取得モジュールの処理フローを示す図である。
【図１５】優先順位上昇方式におけるロック解放モジュールの処理フローを示す図である。
【図１６】優先順位設定モジュール内部構成を詳細に示す図である。
【図１７】優先順位変換モジュールにおける優先順位逆変換機能の処理フローを示す図である。
【図１８】優先順位設定モジュールの処理フローを示す図である。
【図１９】優先順位継承方式におけるロック取得モジュールの処理フローを示す図である。
【図２０】優先順位継承方式におけるロック解放モジュールの処理フローを示す図である。
【図２１】割込みマスクレベル計算モジュール内部構成を詳細に示す図である。
【図２２】割込みマスクレベル計算モジュールの処理フローを示す図である。
【図２３】本発明の第二の実施例におけるシステム構成を示す図である。
【図２４】優先順位監視モジュールの処理フローを示す図である。
【図２５】優先順位監視モジュールを起動する共通割込みハンドラの処理フローを示す図である。
【図２６】本発明の第三の実施例におけるシステム構成を示す図である。
【図２７】オペレーティングシステム間でのタスク振り分け例を示す図である。
【図２８】共通割込みハンドラの別の構成を示した図である。
【図２９】本発明の第四の実施例におけるシステム構成を示す図である。
【符号の説明】
１００…プロセッサ、１０１…メモリ、１０２…入出力制御装置、１０３…プロセッサバス、１０４…ディスク装置、１０５…ディスプレイ、１０６…リアルタイム制御ネットワーク、１０７…割込み信号線、１０８…タイマ装置、１１０…事務処理ＯＳ、１１１…リアルタイムＯＳ、１１２〜１１７，３７０〜３７３…タスク、１１８…オペレーティングシステム切り替えプログラム、１２０，１２１…優先順位通知モジュール、１２２，１２３…優先順位変換モジュール、１２４…優先順位比較モジュール、１３０…ＣＰＵ、１３１…キャッシュメモリ、１３２…汎用レジスタ、１３３…プログラムカウンタ、１３４…ステータスレジスタ、１３５…割込みコントローラ、１３６…データバス、１３７…アドレスバス、１３８…割込み状態信号、１４０…割込みブロックビット、１４１…割込みマスクレベルフィールド、１４２…実行状態レジスタ、１４３…割込みマスクレジスタ、１４４〜１４７…割込みマスクビット、１５０，１５１…実行可能待ち行列、１５２，１５３…割込みハンドラ、１５４，１５５…リスケジューラ、１５６，１５７…システムコールプログラム、１６０〜１６５…タスク管理テーブル、１７０，１７１…優先順位変換テーブル、１７２…事務処理ＯＳ正規化優先順位、１７３…リアルタイムＯＳ正規化優先順位、１７４…共通割込みハンドラ、１７５…ＯＳ間通信機能モジュール、１７６…ＯＳコンテクスト切り替えモジュール、１７７…割込みマスクレベル計算モジュール、２１０…実行ＯＳ記憶変数、２１１…割込み対応テーブル、２１２…事務処理ＯＳ用保存コンテクスト、２１３…リアルタイムＯＳ用保存コンテクスト、２１４，２１５…割込みスタック、２１６，２１７…割込みスタックポインタ、２１８…共有メモリ、２１９…ロック取得モジュール、２２０…ロック解放モジュール、２８０，２８１…優先順位設定モジュール、２８２，２８３…優先順位逆変換テーブル、３２０…割込みマスク変換テーブル、３４０，３４１…実行優先順位、３４２…事務処理ＯＳ実行優先順位記憶値、３４３…リアルタイムＯＳ実行優先順位記憶値、344…優先順位監視モジュール、３８０…割込み優先順位対応テーブル。
Claims (8)
- 複数のオペレーティングシステムと、
それぞれの前記オペレーティングシステム上で実行される複数のプロセス又はスレッドとを記憶したメモリと、
前記複数のオペレーティングシステム、ならびに前記複数のプロセス又はスレッドを読み出して実行するプロセッサとを備え、
該プロセッサは前記各オペレーティングシステム内部のスケジューラ処理において、該オペレーティングシステムがそれぞれの前記プロセス又はスレッドに割り当てられた優先順位に基づいて、次に実行すべきプロセス又はスレッドを決定する際に、該プロセス又はスレッドの優先順位を該オペレーティングシステムから読み出し、
前記それぞれ読み出された優先順位を上記複数のオペレーティングシステム間に共通の表現による優先順位に変換して比較し、より高い優先順位を有するプロセス又はスレッドが属するオペレーティングシステムを選択し実行する処理を行う計算機であって、
前記メモリは複数の前記オペレーティングシステムで定義されているプロセス又はスレッドの優先順位を上記共通の優先順位に変換するための優先順位変換テーブルを有し、かつ、
前記プロセッサは上記優先順位変換テーブルに基づいて、上記各オペレーティングシステムにおいて決定される次に実行すべきプロセス又はスレッドの優先順位を上記共通の優先順位に変換して比較し、該共通の表現においてより高い優先順位を有するプロセス又はスレッドが属するオペレーティングシステムを選択し実行することを特徴とする計算機。 - 請求項１の計算機において、
前記メモリは、上記共通の表現による優先順位を上記各オペレーティングシステムにおける優先順位に変換するための優先順位逆変換テーブルを有し、
前記プロセッサは、複数の上記プロセス又はスレッドについて、指定された上記共通の表現による優先順位より前記優先順位逆変換テーブルに基づいて、該オペレーティングシステムにおける新たな優先順位を決定し、該オペレーティングシステムに対して該プロセス又はスレッドに該新たな優先順位を割り当てるように依頼することを特徴とする計算機。 - 請求項２の計算機において、前記プロセッサは、プロセス又はスレッドのプログラムに記述された所定の処理を実行する場合に、該プロセス又はスレッドにおける前記共通の表現による優先順位を上昇させ、前記優先順位逆変換テーブルに基づいて該オペレーティングシステムにおける新たな優先順位を決定し、該オペレーティングシステムに対して該プロセス又はスレッドの優先順位を変更するように依頼するとともに、該プロセス又はスレッドが該指定された処理を終了した場合に、該プロセス又はスレッドにおける前記共通の表現による優先順位を下降させ、前記優先順位逆変換テーブルに基づいて該オペレーティングシステムにおける新たな優先順位を決定し、該オペレーティングシステムに対して該プロセス又はスレッドの優先順位を変更するように依頼することを特徴とする計算機。
- 複数の前記プロセス又はスレッドを実行すると共に、内部のスケジューラ処理にて決定される、次に実行されるべきプロセス又はスレッドの優先順位を下記優先順位変換処理手段に通知する複数のオペレーティングシステムと、
前記各オペレーティングシステムで定義されているプロセス又はスレッドの優先順位を共通の優先順位に変換するための優先順位変換テーブルに基づいて、前記各オペレーティングシステムから通知された優先順位を上記共通の優先順位に変換する優先順位変換処理手段と、
前記優先順位変換処理手段によって得られた共通の優先順位を比較し、該共通の優先順位においてより高い優先順位を有するプロセス又はスレッドが属するオペレーティングシ ステムを選択し実行する優先順位比較処理手段と、を計算機に実行させるためのプログラムを記憶した計算機が読み取り可能な情報記憶媒体。 - 複数のオペレーティングシステムを選択的に実行するオペレーティングシステム実行方法であって、
優先順位変換処理によって、それぞれの前記オペレーティングシステムで定義されているプロセス又はスレッドの優先順位を共通の優先順位に変換するための優先順位変換テーブルに基づき、前記各オペレーティングシステム内部のスケジューラ処理において、該オペレーティングシステムがそれぞれの前記プロセス又はスレッドに割り当てられた優先順位に基づいて、次に実行すべきプロセス又はスレッドを決定する際に、前記各オペレーティングシステムから通知された、前記プロセス又はスレッドの優先順位を前記共通の優先順位に変換し優先順位比較処理によって、各オペレーティングシステムから通知された、前記プロセス又はスレッドの優先順位をもとに前記優先順位変換処理が変換した前記プロセス又はスレッドの共通の優先順位を比較して、より高い共通の優先順位を有するプロセス又はスレッドが属するオペレーティングシステムを決定し、該オペレーティングシステムを実行することを特徴とするオペレーティングシステム実行方法。 - 請求項５のオペレーティングシステム実行方法において、
前記優先順位変換処理は、前記各オペレーティングシステム内部のスケジューラ処理にて決定される、次に実行されるべきプロセス又はスレッドの優先順位を上記共通の優先順位に変換するにあたり、前記各オペレーティングシステムで定義されているプロセス又はスレッドの優先順位を、それぞれ、前記共通の表現において互いに異なる優先順位となるように変換することを特徴とするオペレーティングシステム実行方法。 - 請求項５又は６にオペレーティングシステム実行方法において、
前記優先順位変換処理は、前記各上記オペレーティングシステム内部のスケジューラ処理にて決定される、次に実行されるべきプロセス又はスレッドの優先順位を上記共通の優先順位に変換するほかに、オペレーティングシステムがプロセス又はスレッドを実行している以外の状態として、少なくとも、割込み処理中の状態、オペレーティングシステム自体の機能を実行中の状態、実行すべき処理が存在しない状態という三つの状態を前記共通の優先順位に変換することを特徴とするオペレーティングシステム実行方法。 - 複数のプロセスまたはスレッドを該複数のプロセス又はスレッドに割り当てられた優先順位にしたがって実行する複数個のオペレーティングシステムと、該複数個のオペレーティングシステムを切替える手段とを有する計算機システムにおいて、
前記複数個のオペレーティングシステムは、各オペレーティングシステムでそれぞれ定義されているプロセスまたはスレッドの優先順位を前記複数のオペレーティングシステム間に共通の表現による優先順位に変換するための優先順位変換テーブルに基づいて、各オペレーティングシステムでそれぞれ内部のスケジューラ処理にて決定される、次に実行されるべきプロセス又はスレッドの優先順位を前記共通の表現による優先順位に変換する優先順位変換手段と、
前記優先順位変換手段から得られた、各オペレーティングシステムでそれぞれ内部のスケジューラ処理にて決定される、次に実行されるべきプロセス又はスレッドの共通の優先順位を前記オペレーティングシステムを切替える手段に通知する優先順位通知手段とを有し、
該オペレーティングシステムを切替える手段は、前記各オペレーティングシステムから通知された前記プロセス又はスレッドの共通の優先順位を比較して、該共通の表現においてより高い優先順位を有するプロセス又はスレッドが属するオペレーティングシステムを決定し、該オペレーティングシステムに切り替えて実行する優先順位比較手段を備えたことを特徴とする計算機システム。
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04103299A JP4072271B2 (ja) | 1999-02-19 | 1999-02-19 | 複数のオペレーティングシステムを実行する計算機 |
| DE60043032T DE60043032D1 (de) | 1999-02-19 | 2000-02-14 | Mehrere Betriebssyteme ausführender Rechner |
| EP00301110A EP1031924B1 (en) | 1999-02-19 | 2000-02-14 | Computer executing multiple operating system |
| AT00301110T ATE444523T1 (de) | 1999-02-19 | 2000-02-14 | Mehrere betriebssyteme ausführender rechner |
| CN00102345A CN1264078A (zh) | 1999-02-19 | 2000-02-18 | 执行多个操作***的计算机 |
| KR1020000007733A KR100759280B1 (ko) | 1999-02-19 | 2000-02-18 | 복수의 오퍼레이팅 시스템을 실행하는 계산기 |
| TW089102909A TW490638B (en) | 1999-02-19 | 2000-02-19 | Computer for executing plural operating systems |
| US11/025,966 US7810096B2 (en) | 1999-02-19 | 2005-01-03 | Computer executing multiple operating systems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04103299A JP4072271B2 (ja) | 1999-02-19 | 1999-02-19 | 複数のオペレーティングシステムを実行する計算機 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000242512A JP2000242512A (ja) | 2000-09-08 |
| JP4072271B2 true JP4072271B2 (ja) | 2008-04-09 |
Family
ID=12597071
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP04103299A Expired - Fee Related JP4072271B2 (ja) | 1999-02-19 | 1999-02-19 | 複数のオペレーティングシステムを実行する計算機 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7810096B2 (ja) |
| EP (1) | EP1031924B1 (ja) |
| JP (1) | JP4072271B2 (ja) |
| KR (1) | KR100759280B1 (ja) |
| CN (1) | CN1264078A (ja) |
| AT (1) | ATE444523T1 (ja) |
| DE (1) | DE60043032D1 (ja) |
| TW (1) | TW490638B (ja) |
Families Citing this family (84)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001256067A (ja) * | 2000-03-08 | 2001-09-21 | Mitsubishi Electric Corp | プロセッサ省電力制御方法、記憶媒体、およびプロセッサ省電力制御装置 |
| GB2369464B (en) * | 2000-11-27 | 2005-01-05 | Advanced Risc Mach Ltd | A data processing apparatus and method for saving return state |
| CN100356349C (zh) * | 2001-04-27 | 2007-12-19 | 邵通 | 一种实现计算设备状态转换的装置及方法 |
| CN100356350C (zh) * | 2001-04-27 | 2007-12-19 | 邵通 | 实现计算设备状态转换装置安全操作的装置和方法 |
| JP2003067201A (ja) | 2001-08-30 | 2003-03-07 | Hitachi Ltd | コントローラとオペレーティングシステム |
| US7069442B2 (en) | 2002-03-29 | 2006-06-27 | Intel Corporation | System and method for execution of a secured environment initialization instruction |
| KR20040012540A (ko) * | 2002-07-31 | 2004-02-11 | 마쯔시다덴기산교 가부시키가이샤 | 정보처리단말 및 정보처리방법 |
| US7496494B2 (en) | 2002-09-17 | 2009-02-24 | International Business Machines Corporation | Method and system for multiprocessor emulation on a multiprocessor host system |
| GB2396712B (en) * | 2002-11-18 | 2005-12-07 | Advanced Risc Mach Ltd | Handling multiple interrupts in a data processing system utilising multiple operating systems |
| GB2395313B (en) * | 2002-11-18 | 2005-11-23 | Advanced Risc Mach Ltd | Task following between multiple operating systems |
| GB0226874D0 (en) | 2002-11-18 | 2002-12-24 | Advanced Risc Mach Ltd | Switching between secure and non-secure processing modes |
| JP3953449B2 (ja) * | 2003-08-26 | 2007-08-08 | 富士通株式会社 | タスク管理プログラムおよびタスク制御装置 |
| JP4112511B2 (ja) | 2004-02-17 | 2008-07-02 | 富士通株式会社 | タスク管理プログラムおよびタスク管理装置 |
| US8707317B2 (en) * | 2004-04-30 | 2014-04-22 | Microsoft Corporation | Reserving a fixed amount of hardware resources of a multimedia console for system application and controlling the unreserved resources by the multimedia application |
| US7716669B2 (en) * | 2004-04-30 | 2010-05-11 | Microsoft Corporation | Concurrent system applications in a multimedia console |
| US8561076B1 (en) * | 2004-06-30 | 2013-10-15 | Emc Corporation | Prioritization and queuing of media requests |
| US8271976B2 (en) * | 2004-06-30 | 2012-09-18 | Microsoft Corporation | Systems and methods for initializing multiple virtual processors within a single virtual machine |
| US20060010446A1 (en) * | 2004-07-06 | 2006-01-12 | Desai Rajiv S | Method and system for concurrent execution of multiple kernels |
| KR20070083569A (ko) | 2004-08-18 | 2007-08-24 | 쟈루나 에스에이 | 운영체제 |
| US7840962B2 (en) * | 2004-09-30 | 2010-11-23 | Intel Corporation | System and method for controlling switching between VMM and VM using enabling value of VMM timer indicator and VMM timer value having a specified time |
| CN100535862C (zh) * | 2004-11-30 | 2009-09-02 | 皇家飞利浦电子股份有限公司 | 优先化任务之间的有效切换 |
| US8274518B2 (en) | 2004-12-30 | 2012-09-25 | Microsoft Corporation | Systems and methods for virtualizing graphics subsystems |
| WO2006069538A1 (fr) * | 2004-12-31 | 2006-07-06 | Juhang Zhong | Systeme de traitement de donnees avec pluralite de sous-systemes et procede correspondant |
| US7437546B2 (en) * | 2005-08-03 | 2008-10-14 | Intel Corporation | Multiple, cooperating operating systems (OS) platform system and method |
| US7719132B2 (en) | 2005-09-28 | 2010-05-18 | L3 Communications Corporation | Ruggedized mobile computing device |
| US20070104340A1 (en) * | 2005-09-28 | 2007-05-10 | Knowles Electronics, Llc | System and Method for Manufacturing a Transducer Module |
| US8104033B2 (en) * | 2005-09-30 | 2012-01-24 | Computer Associates Think, Inc. | Managing virtual machines based on business priorty |
| JP5109250B2 (ja) * | 2005-11-08 | 2012-12-26 | 横河電機株式会社 | 分散システム |
| KR100731983B1 (ko) * | 2005-12-29 | 2007-06-25 | 전자부품연구원 | 저전력 무선 디바이스 프로세서용 하드와이어드 스케줄러및 스케줄링 방법 |
| CN101359312B (zh) * | 2006-01-17 | 2010-06-09 | 株式会社Ntt都科摩 | 输入输出控制*** |
| JP4342576B2 (ja) * | 2006-07-25 | 2009-10-14 | 株式会社エヌ・ティ・ティ・ドコモ | 複数オペレーティングシステム切替制御装置及びコンピュータシステム |
| EP1892625B1 (en) * | 2006-08-09 | 2018-07-11 | Red Bend Software | Finer grained operating system scheduling |
| US7689820B2 (en) * | 2006-09-27 | 2010-03-30 | L3 Communications Corporation | Rapid-boot computing device with dual operating systems |
| US8819483B2 (en) | 2006-09-27 | 2014-08-26 | L-3 Communications Corporation | Computing device with redundant, dissimilar operating systems |
| JP4785142B2 (ja) * | 2007-01-31 | 2011-10-05 | ルネサスエレクトロニクス株式会社 | データ処理装置 |
| WO2008152790A1 (ja) | 2007-06-12 | 2008-12-18 | Panasonic Corporation | マルチプロセッサ制御装置、マルチプロセッサ制御方法及びマルチプロセッサ制御回路 |
| US8627327B2 (en) * | 2007-10-24 | 2014-01-07 | International Business Machines Corporation | Thread classification suspension |
| JP5053109B2 (ja) * | 2008-01-23 | 2012-10-17 | 株式会社日立製作所 | 制御装置 |
| CN101499021A (zh) * | 2008-01-31 | 2009-08-05 | 国际商业机器公司 | 在多个虚拟机上动态分配资源的方法和装置 |
| US8468533B2 (en) | 2008-04-28 | 2013-06-18 | Panasonic Corporation | Virtual machine control device, method, and program wherein a switching task used to switch to the highest priority virtual machines is the highest priority task in the current virtual machine and the virtual machine that is the switching target |
| JP2009294712A (ja) * | 2008-06-02 | 2009-12-17 | Panasonic Corp | 優先度制御装置及び優先度制御方法 |
| WO2009157178A1 (ja) * | 2008-06-24 | 2009-12-30 | パナソニック株式会社 | 仮想計算機制御装置、仮想計算機制御プログラム及び仮想計算機制御回路 |
| US8635621B2 (en) * | 2008-08-22 | 2014-01-21 | International Business Machines Corporation | Method and apparatus to implement software to hardware thread priority |
| US8424007B1 (en) * | 2008-09-30 | 2013-04-16 | Symantec Corporation | Prioritizing tasks from virtual machines |
| US9086913B2 (en) * | 2008-12-31 | 2015-07-21 | Intel Corporation | Processor extensions for execution of secure embedded containers |
| JP4897851B2 (ja) * | 2009-05-14 | 2012-03-14 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピュータ・システム及びコンピュータ・システムの制御方法 |
| US8874167B2 (en) * | 2009-11-17 | 2014-10-28 | Broadcom Corporation | Method and system for multi-standby operation for a multi-SIM multi-standby communication device |
| CN102667725B (zh) | 2010-01-13 | 2015-09-16 | 马维尔以色列(M.I.S.L.)有限公司 | 用于媒体处理的硬件虚拟化 |
| US20110219373A1 (en) * | 2010-03-02 | 2011-09-08 | Electronics And Telecommunications Research Institute | Virtual machine management apparatus and virtualization method for virtualization-supporting terminal platform |
| US8341643B2 (en) * | 2010-03-29 | 2012-12-25 | International Business Machines Corporation | Protecting shared resources using shared memory and sockets |
| JP5770721B2 (ja) * | 2010-05-24 | 2015-08-26 | パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 情報処理システム |
| CN102597972B (zh) | 2010-05-24 | 2016-06-08 | 松下电器（美国）知识产权公司 | 虚拟计算机***、区域管理方法 |
| JP5323103B2 (ja) * | 2010-09-03 | 2013-10-23 | 三菱電機株式会社 | グラフィカルユーザインタフェース装置 |
| RU2540830C2 (ru) * | 2010-09-28 | 2015-02-10 | Сименс Акциенгезелльшафт | Адаптивное дистанционное обслуживание подвижных составов |
| US8407710B2 (en) * | 2010-10-14 | 2013-03-26 | International Business Machines Corporation | Systems and methods for dynamically scanning a plurality of active ports for priority schedule of work |
| CN102770846B (zh) * | 2010-12-21 | 2016-08-31 | 松下电器（美国）知识产权公司 | 虚拟计算机***控制装置及虚拟计算机***控制方法 |
| WO2012102002A1 (ja) | 2011-01-24 | 2012-08-02 | パナソニック株式会社 | 仮想計算機システム、仮想計算機制御方法、仮想計算機制御プログラム、記録媒体、及び集積回路 |
| JP2012185541A (ja) * | 2011-03-03 | 2012-09-27 | Denso Corp | 車載装置、スケジューリングプログラム、及びスケジューリング方法 |
| JP5648544B2 (ja) | 2011-03-15 | 2015-01-07 | 富士通株式会社 | スケジューリングプログラム、および情報処理装置 |
| JP5852103B2 (ja) | 2011-04-27 | 2016-02-03 | パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 仮想計算機システム、仮想計算機制御方法、仮想計算機制御プログラム、及び半導体集積回路 |
| US8924885B2 (en) | 2011-05-27 | 2014-12-30 | Microsoft Corporation | Desktop as immersive application |
| US9843665B2 (en) | 2011-05-27 | 2017-12-12 | Microsoft Technology Licensing, Llc | Display of immersive and desktop shells |
| US10417018B2 (en) | 2011-05-27 | 2019-09-17 | Microsoft Technology Licensing, Llc | Navigation of immersive and desktop shells |
| KR101801359B1 (ko) * | 2011-07-28 | 2017-11-24 | 엘지전자 주식회사 | 이동 단말기 |
| TWI496083B (zh) * | 2011-08-30 | 2015-08-11 | Compal Electronics Inc | 雙作業系統的操作方法、可攜式電子裝置以及對接擴充系統 |
| TWI497419B (zh) | 2011-10-20 | 2015-08-21 | Via Tech Inc | 電腦裝置及其中斷任務分配方法 |
| JP5729266B2 (ja) * | 2011-11-15 | 2015-06-03 | 富士通株式会社 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
| JPWO2013132648A1 (ja) * | 2012-03-09 | 2015-07-30 | パイオニア株式会社 | 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム |
| WO2013132648A1 (ja) * | 2012-03-09 | 2013-09-12 | パイオニア株式会社 | 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム |
| WO2013159289A1 (en) * | 2012-04-25 | 2013-10-31 | Hewlett-Packard Development Company | Switching of operating systems |
| US9575760B2 (en) * | 2013-05-17 | 2017-02-21 | Nvidia Corporation | Techniques for sharing priorities between streams of work and dynamic parallelism |
| US9830178B2 (en) | 2014-03-06 | 2017-11-28 | Intel Corporation | Dynamic reassignment for multi-operating system devices |
| US9606833B2 (en) * | 2014-04-09 | 2017-03-28 | Samsung Electronics Co., Ltd | Method and apparatus for providing a preemptive task scheduling scheme in a real time operating system |
| US10394602B2 (en) * | 2014-05-29 | 2019-08-27 | Blackberry Limited | System and method for coordinating process and memory management across domains |
| US20160055031A1 (en) * | 2014-11-13 | 2016-02-25 | Mediatek Inc. | Dual-System Architecture With Fast Recover And Switching Of Operating System |
| CN104506563B (zh) * | 2015-01-20 | 2018-09-07 | 宇龙计算机通信科技(深圳)有限公司 | 进程的访问控制方法、访问控制***和终端 |
| EP3062225B1 (en) * | 2015-02-24 | 2019-07-03 | Huawei Technologies Co., Ltd. | Multi-operating system device, notification device and methods thereof |
| JP6110969B2 (ja) * | 2016-02-24 | 2017-04-05 | パイオニア株式会社 | 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム |
| JP6615726B2 (ja) * | 2016-09-16 | 2019-12-04 | 株式会社東芝 | 情報処理装置、情報処理方法及びプログラム |
| CN106547628B (zh) * | 2016-11-29 | 2020-05-01 | 北京元心科技有限公司 | 多***的资源释放方法及装置 |
| JP7010014B2 (ja) * | 2018-01-18 | 2022-01-26 | 株式会社デンソー | スケジューリング装置 |
| US10725941B2 (en) | 2018-06-30 | 2020-07-28 | Western Digital Technologies, Inc. | Multi-device storage system with hosted services on peer storage devices |
| US10877810B2 (en) * | 2018-09-29 | 2020-12-29 | Western Digital Technologies, Inc. | Object storage system with metadata operation priority processing |
| CN115080158A (zh) * | 2021-03-12 | 2022-09-20 | Oppo广东移动通信有限公司 | 界面显示方法、装置、终端设备及计算机可读存储介质 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4481583A (en) * | 1981-10-30 | 1984-11-06 | At&T Bell Laboratories | Method for distributing resources in a time-shared system |
| US5392409A (en) * | 1984-01-18 | 1995-02-21 | Hitachi, Ltd. | I/O execution method for a virtual machine system and system therefor |
| JPS62231339A (ja) * | 1986-03-31 | 1987-10-09 | Fuji Electric Co Ltd | ２つのオペレ−テイングシステムの並行動作方法 |
| EP0427067A3 (en) * | 1989-11-08 | 1991-08-14 | Siemens Aktiengesellschaft | Method for the alternating operation of a computer with several operating systems |
| JPH04367037A (ja) * | 1991-06-13 | 1992-12-18 | Mitsubishi Electric Corp | 計算機システム |
| JPH05108380A (ja) * | 1991-10-21 | 1993-04-30 | Mitsubishi Electric Corp | データ処理システム |
| JPH0799501B2 (ja) * | 1991-11-18 | 1995-10-25 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 複数アプリケーションの同時実行装置 |
| JPH05197577A (ja) * | 1992-01-20 | 1993-08-06 | Nec Corp | 仮想計算機システムにおける仮想計算機実行プライオリティ制御方式 |
| US5333319A (en) * | 1992-03-02 | 1994-07-26 | International Business Machines Corporation | Virtual storage data processor with enhanced dispatching priority allocation of CPU resources |
| JPH064310A (ja) | 1992-06-24 | 1994-01-14 | Nec Software Ltd | 複数オペレーティングシステム切換え方式 |
| US5483647A (en) * | 1992-12-17 | 1996-01-09 | Bull Hn Information Systems Inc. | System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user |
| JP3349547B2 (ja) * | 1993-05-10 | 2002-11-25 | 株式会社日立製作所 | スケジューリングシステム |
| JP3658420B2 (ja) * | 1994-04-14 | 2005-06-08 | 株式会社日立製作所 | 分散処理システム |
| CA2173695A1 (en) * | 1995-04-14 | 1996-10-15 | Panagiotis Kougiouris | Method and system for providing interoperability among processes written to execute on different operating systems |
| US6678712B1 (en) * | 1996-01-19 | 2004-01-13 | International Business Machines Corporation | Method and system for executing a program under one of a plurality of mutually exclusive operating environments |
| US5826081A (en) * | 1996-05-06 | 1998-10-20 | Sun Microsystems, Inc. | Real time thread dispatcher for multiprocessor applications |
| WO1998012635A1 (en) * | 1996-09-17 | 1998-03-26 | Radisys Corporation | Method and apparatus for encapsulating a protected-mode operating system within a real-time, protected-mode operating system |
| US6658447B2 (en) * | 1997-07-08 | 2003-12-02 | Intel Corporation | Priority based simultaneous multi-threading |
| FI108478B (fi) * | 1998-01-21 | 2002-01-31 | Nokia Corp | Sulautettu jõrjestelmõ |
| US6157989A (en) * | 1998-06-03 | 2000-12-05 | Motorola, Inc. | Dynamic bus arbitration priority and task switching based on shared memory fullness in a multi-processor system |
| JP3659062B2 (ja) * | 1999-05-21 | 2005-06-15 | 株式会社日立製作所 | 計算機システム |
| US6715016B1 (en) * | 2000-06-01 | 2004-03-30 | Hitachi, Ltd. | Multiple operating system control method |
| US6381524B1 (en) * | 2000-06-20 | 2002-04-30 | Hitachi, Ltd. | Vehicle travel control apparatus |
-
1999
- 1999-02-19 JP JP04103299A patent/JP4072271B2/ja not_active Expired - Fee Related
-
2000
- 2000-02-14 EP EP00301110A patent/EP1031924B1/en not_active Expired - Lifetime
- 2000-02-14 DE DE60043032T patent/DE60043032D1/de not_active Expired - Lifetime
- 2000-02-14 AT AT00301110T patent/ATE444523T1/de not_active IP Right Cessation
- 2000-02-18 CN CN00102345A patent/CN1264078A/zh active Pending
- 2000-02-18 KR KR1020000007733A patent/KR100759280B1/ko not_active IP Right Cessation
- 2000-02-19 TW TW089102909A patent/TW490638B/zh not_active IP Right Cessation
-
2005
- 2005-01-03 US US11/025,966 patent/US7810096B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000242512A (ja) | 2000-09-08 |
| EP1031924B1 (en) | 2009-09-30 |
| TW490638B (en) | 2002-06-11 |
| US7810096B2 (en) | 2010-10-05 |
| DE60043032D1 (de) | 2009-11-12 |
| CN1264078A (zh) | 2000-08-23 |
| KR20000076691A (ko) | 2000-12-26 |
| KR100759280B1 (ko) | 2007-09-17 |
| EP1031924A2 (en) | 2000-08-30 |
| EP1031924A3 (en) | 2003-10-15 |
| ATE444523T1 (de) | 2009-10-15 |
| US20050149933A1 (en) | 2005-07-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4072271B2 (ja) | 複数のオペレーティングシステムを実行する計算機 | |
| JP3659062B2 (ja) | 計算機システム | |
| CN109997112B (zh) | 数据处理 | |
| US7493436B2 (en) | Interrupt handling using simultaneous multi-threading | |
| JP5367816B2 (ja) | オペレーションの保護モードスケジューリング | |
| US20160085601A1 (en) | Transparent user mode scheduling on traditional threading systems | |
| JP2006515690A (ja) | 複数のプロセッサを有するデータ処理システムと、複数のプロセッサを有するデータ処理システムのためのタスクスケジューラと、タスクスケジューリングの対応する方法 | |
| KR20020087388A (ko) | 연산처리시스템 및 연산처리 제어방법, 업무관리시스템 및업무관리방법과 기억매체 | |
| US9063918B2 (en) | Determining a virtual interrupt source number from a physical interrupt source number | |
| CN109815007A (zh) | 基于云监控的线程控制方法、装置、电子设备及存储介质 | |
| WO2009150815A1 (ja) | マルチプロセッサシステム | |
| CN112306669A (zh) | 一种基于多核***的任务处理方法及装置 | |
| US20130125131A1 (en) | Multi-core processor system, thread control method, and computer product | |
| EP1811375B1 (en) | Processor | |
| US20080134187A1 (en) | Hardware scheduled smp architectures | |
| JPH06243112A (ja) | マルチプロセッサ装置 | |
| US8719499B2 (en) | Cache-line based notification | |
| JP7346649B2 (ja) | 同期制御システムおよび同期制御方法 | |
| US20030014558A1 (en) | Batch interrupts handling device, virtual shared memory and multiple concurrent processing device | |
| US8359602B2 (en) | Method and system for task switching with inline execution | |
| JPH10334055A (ja) | マルチプロセッサ・システム | |
| JP3349547B2 (ja) | スケジューリングシステム | |
| JPH09319653A (ja) | 情報処理装置、情報処理システム及びその制御方法 | |
| KR100676671B1 (ko) | 유저 쓰레드 관리 장치 및 그 방법 | |
| JP2001229038A (ja) | マルチオペレーテング計算機システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040427 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050222 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050425 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050707 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20051228 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060427 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071022 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071221 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080121 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120125 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130125 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |