(57)【要約】      （修正有）【課題】優先度に基づき実行スケジュールが制御されるプロセス間の通信を早期に完了できる情報処理装置を提供する。【解決手段】各プロセスの実行スケジュールを各プロセスの優先度に基づき制御する情報処理装置であって、任意の送信側プロセスから受信側プロセスに対するデータの送信要求とデータを受け付ける送信要求受け付け手段と、前記送信要求受け付け手段から前記受信側プロセスの優先度の変更要求を取得し、前記送信側プロセスの優先度の方が前記受信側プロセスの優先度よりも高い場合、前記プロセス情報記憶部に記憶されている前記受信側プロセスの優先度を元の値よりも高い値に変更する優先度変更手段と、前記送信側プロセスが送信要求したデータに対する受信要求を前記受信側プロセスから受け付け、前記受信側プロセスにデータを受け渡す受信要求受け付け手段と、を有する。【選択図】図２
2015056109.tif 000002
【特許請求の範囲】
【請求項１】
各プロセスの実行スケジュールを各プロセスの優先度に基づき制御する情報処理装置であって、
各プロセスのプロセス識別情報に、優先度が対応づけられたプロセス情報記憶部と、
任意の送信側プロセスから受信側プロセスに対するデータの送信要求とデータを受け付ける送信要求受け付け手段と、
前記送信要求受け付け手段から前記受信側プロセスの優先度の変更要求を取得し、前記送信側プロセスの優先度の方が前記受信側プロセスの優先度よりも高い場合、前記プロセス情報記憶部に記憶されている前記受信側プロセスの優先度を元の値よりも高い値に変更する優先度変更手段と、
前記送信側プロセスが送信要求したデータに対する受信要求を、前記優先度変更手段により優先度が変更された前記受信側プロセスから受け付け、前記受信側プロセスにデータを受け渡す受信要求受け付け手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記送信要求受け付け手段から、前記受信側プロセスの優先度を元の値に戻す優先度復帰要求を受け付ける復帰要求受け付け手段を有し、
前記復帰要求受け付け手段は、前記プロセス情報記憶部に記憶されている前記受信側プロセスの優先度を、前記プロセス情報記憶部に退避されていた変更前の元の優先度に戻す、
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記送信要求受け付け手段は、データの送信要求を受け付けた際、データと共に送信される通信種別が送信要求に対する応答か否かを判定し、
送信要求に対する応答の場合は、前記復帰要求受け付け手段に対し前記受信側プロセスの優先度を元の値に戻させ、
送信要求に対する応答でない場合は、前記優先度変更手段に対し前記受信側プロセスの優先度を元の値よりも高い値に変更させる、
ことを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記優先度変更手段は、優先度の変更要求と共に前記送信側プロセスの優先度を取得し、前記受信側プロセスの優先度を前記送信側プロセスと同じ優先度に変更する、
ことを特徴とする請求項１〜３いずれか１項記載の情報処理装置。
【請求項５】
前記送信要求受け付け手段がデータの送信要求を受け付けるよりも先に、前記受信要求受け付け手段がデータの受信要求を受け付けた場合、
前記受信要求受け付け手段から、前記受信側プロセスの休眠状態への遷移要求を受け付ける休眠要求受け付け手段と、
実行可能状態のプロセスが優先度順に登録された実行可能状態プロセスキューから、最も優先度の高いプロセスを実行状態に遷移させる実行状態遷移手段と、
を有することを特徴とする請求項１〜４いずれか１項記載の情報処理装置。
【請求項６】
前記休眠要求受け付け手段は、前記受信要求受け付け手段から休眠状態への遷移要求を受け付けた際に、前記受信要求受け付け手段が受信要求したデータのメモリアドレスに基づくキーを生成し、前記キーに対応づけて前記受信側プロセスを休眠プロセステーブルに対し登録しておき、
前記送信要求受け付け手段がデータの送信要求を受け付けた場合、データのメモリアドレスに基づくキーを生成して前記休眠プロセステーブルから該キーに対応づけられた前記受信側プロセスを特定し、該受信側プロセスを休眠状態から実行可能状態に遷移させる実行可能状態遷移手段、を有し、
前記実行状態遷移手段は、実行可能状態のプロセスが優先度順に登録された実行可能状態プロセスキューから、最も優先度の高いプロセスを実行状態に遷移させる、
ことを特徴とする請求項５記載の情報処理装置。
【請求項７】
前記送信要求受け付け手段がデータの送信要求を受け付ける前に、
前記送信要求受け付け手段が取得した前記送信側プロセスの識別情報を、前記受信要求受け付け手段が前記受信側プロセスに受け渡し、
前記送信要求受け付け手段が取得した前記受信側プロセスの識別情報を、前記受信要求受け付け手段が前記送信側プロセスに受け渡すことで通信路を確立する、
ことを特徴とする請求項１〜６いずれか１項記載の情報処理装置。
【請求項８】
各プロセスの実行スケジュールを各プロセスの優先度に基づき制御する情報処理装置に、
任意の送信側プロセスから受信側プロセスに対するデータの送信要求とデータを受け付ける送信要求受け付けステップと、
前記送信要求受け付け手段から前記受信側プロセスの優先度の変更要求を取得し、前記送信側プロセスの優先度の方が前記受信側プロセスの優先度よりも高い場合、各プロセスの優先度が登録されたプロセス情報記憶部に記憶されている前記受信側プロセスの優先度を元の値よりも高い値に変更する優先度変更ステップと、
前記送信側プロセスが送信要求したデータに対する受信要求を前記受信側プロセスから受け付け、前記受信側プロセスにデータを受け渡す受信要求受け付けステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、各プロセスの実行スケジュールを各プロセスの優先度に基づき制御する情報処理装置に関する。
【背景技術】
【０００２】
ＰＣ（Personal Computer）やスマートフォンなどの汎用型の情報処理装置で動作するソフトウェアと対比して、装置に予め組み込まれ装置に特有の機能を実現するソフトウェアは組み込みソフトウェアと呼ばれることがある。組み込みソフトウェアの規模は装置によって様々だが、機能の高度化・複雑化に伴い大規模化する傾向がある。このため、組み込みソフトウェアにおいても複数のプロセスが連動して行う処理が増えている。プロセスの定義はＯＳ（Operating System）などによって異なるが、例えばＯＳがＣＰＵを割り当てるソフトウェアの実行単位である。
【０００３】
複数プロセスが連動するための手段としてよく知られているのは、「プロセス間通信」である。プロセス間通信は主に一方のプロセスが相手方に対して送信を行い、その応答を受け取ること（双方向通信）で完了する。よって、送信開始から応答までの処理を効率的に行うことで、プロセス間通信に必要な時間が短くなり、処理の速度を早めることができる。
【０００４】
図１は、プロセス間通信の概略を示すシーケンス図の一例である。
S1：送信側プロセスはＯＳのwriteインタフェースに対し送信を行う。
S2：受信側プロセスはＯＳのreadインタフェースに対し受信を行う。
S3：受信側プロセスはＯＳのwriteインタフェースに対し応答を送信する。
S4：送信側プロセスはＯＳのreadインタフェースに対し応答の受信を行う。
【０００５】
このような通信を早期に終わらせるためには、送信側プロセスがデータを送信した直後に受信側がすぐに受信して必要な処理を行い、応答を返信することが理想である。
【０００６】
しかし、一般的なＯＳは、プロセスの状態と優先度に基づき複数のプロセスの実行順を管理する。これは、組み込み用のリアルタイムＯＳだけでなくUnix（登録商標）のような汎用ＯＳでも同様である。すなわち、ＯＳは、実行可能状態のプロセスのうち優先度が一番高いものにＣＰＵの実行権を与えて、実行状態にする。
【０００７】
プロセス間通信とプロセスの優先度の関係を考えると、受信側プロセスの優先度が比較的高い場合は、送信側プロセスの送信後、短時間に受信側プロセスが受信処理から応答までの処理を行うことができる。これに対し、受信側プロセスの優先度が比較的低い場合は、送信側プロセスの優先度が高いにもかかわらず、送信側プロセスが応答を受け取るまで待機しなければならない。図１の例では、送信側プロセスの優先度（５０）よりも受信側プロセスの方が優先度（２０）が低いので、優先度が高いはずの送信側プロセスが、優先度の低い受信側プロセスからの応答を待つ必要が生じる。すなわち、通信が完了するまでに時間がかかり、優先度が高いはずの送信側の処理が遅延する傾向が生じるという矛盾が生じてしまう。
【０００８】
このような不都合については、ＯＳなどが受信側プロセスの優先度を高くすることが考えられる（例えば、特許文献１参照。）。特許文献１には、優先度を使用した分散処理システムにおいて、プロセス間通信を実施する際に受信側プロセスの優先度を送信側プロセスの優先度に応じた値にする分散処理装置が開示されている。具体的には、プロセス間通信のメッセージ送出時、ＯＳがメッセージに送信側プロセスの優先度を付与し、これを受け取ったＯＳが受信側プロセスの優先度をメッセージに付与した優先度に応じた値にする。このような仕組みによれば、受信側プロセスの優先度が送信側プロセスに応じて高くなるので、送信側プロセスの優先度が高い場合に、送信側プロセスが応答を受け取るまでの待機時間を短くできる。このような優先度の割り当て方法を、以下「優先度一律割り当て方式」と称する。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来の「優先度一律割り当て方式」は、「送信側プロセスの優先度＜受信側プロセスの優先度」の場合にも、一律に送信側プロセスの優先度が受信側プロセスに適用されてしまうことで、受信側プロセスの優先度が本来持つ優先度よりも低下してしまう場合があった。このため、他の優先度の高いプロセスに受信処理が阻害され、送信から応答の受信までの通信処理が遅延するケースが発生するという問題があった。
【００１０】
本発明は、上記課題に鑑み、優先度に基づき実行スケジュールが制御されるプロセス間の通信を早期に完了できる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、各プロセスの実行スケジュールを各プロセスの優先度に基づき制御する情報処理装置であって、各プロセスのプロセス識別情報に、優先度が対応づけられたプロセス情報記憶部と、任意の送信側プロセスから受信側プロセスに対するデータの送信要求とデータを受け付ける送信要求受け付け手段と、前記送信要求受け付け手段から前記受信側プロセスの優先度の変更要求を取得し、前記送信側プロセスの優先度の方が前記受信側プロセスの優先度よりも高い場合、前記プロセス情報記憶部に記憶されている前記受信側プロセスの優先度を元の値よりも高い値に変更する優先度変更手段と、前記送信側プロセスが送信要求したデータに対する受信要求を前記受信側プロセスから受け付け、前記受信側プロセスにデータを受け渡す受信要求受け付け手段と、を有することを特徴とする。
【発明の効果】
【００１２】
優先度に基づき実行スケジュールが制御されるプロセス間の通信を早期に完了できる情報処理装置を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】プロセス間通信の概略を示すシーケンス図の一例である。
【図２】本実施形態の情報処理装置の概略的な特徴を説明する図の一例である。
【図３】画像形成装置のハードウェア構成図の一例である。
【図４】画像形成装置の構成図の一例である。
【図５】汎用ＯＳのうち「プロセス制御部」の機能を説明する図の一例である。
【図６】汎用ＯＳのうち「プロセス間通信制御部」の機能を説明する図の一例である。
【図７】データフォーマット、プロセス構造体のフォーマット、ファイル構造体フォーマットを模式的に説明する図の一例である。
【図８】実行可能状態プロセスキュー、休眠状態プロセスハッシュの構成図の一例である。
【図９】送信側プロセスと受信側プロセスが通信する手順を示すシーケンス図の一例である。
【図１０】writeインタフェースの処理フローを示す図の一例である。
【図１１】tmpファイルシステムのwriteインタフェースの処理フローを示す図の一例である。
【図１２】readインタフェースの処理フローを示す図の一例である。
【図１３】tmpファイルシステムのreadインタフェースの処理フローを示す図の一例である。
【図１４】sleepインタフェースの処理フローの一例を示す図である。
【図１５】wakeupインタフェースの処理フローの一例を示す図である。
【図１６】inheritpriインタフェースの処理フローの一例を示す図である。
【図１７】uninheritpriインタフェースの処理フローの一例を示す図である。
【図１８】switchインタフェースの処理フローの一例を示す図である。
【発明を実施するための形態】
【００１４】
図２は、本実施形態の情報処理装置の概略的な特徴を説明する図の一例である。本実施形態の情報処理装置は、「送信側プロセスの優先度と受信側プロセスの優先度の比較を行い、受信側プロセスの優先度のほうが低い場合に限り、送信側プロセスの優先度に応じた値を一時的に受信側プロセスの優先度に設定する。」ことを特徴の１つとしている。
【００１５】
送信側プロセスの優先度を"５０"、受信側プロセスの優先度を"２０"とする。
S1：送信側プロセスはＯＳのwriteインタフェースに対し送信を行う。
S2：ＯＳは送信側プロセスと受信側プロセスの優先度を比較する。送信側プロセスの優先度（５０）＞受信側プロセスの優先度（２０）なので、受信側プロセスの優先度を２０から５０に一時的に変更する。
S3：受信側プロセスはＯＳのreadインタフェースに対し受信を行う。受信側プロセスの優先度が高くなるので実行状態になりやすくなり、受信処理を早期に行える。
S4：受信側プロセスはＯＳのwriteインタフェースに対し応答を送信する。受信側プロセスは応答の返信が終了したら、ＯＳは受信側プロセスの優先度を元に戻す。これにより、優先度をそのままにするよりもシステムへ与える影響を少なくすることができる。
S5：送信側プロセスはＯＳのreadインタフェースに対し応答の受信を行う。
【００１６】
このように、本実施形態では、「送信側プロセスの優先度＞受信側プロセスの優先度」の場合にのみ、受信側プロセスの優先度が送信側プロセスの優先度と同じ値に設定されるので、優先度が高い送信側プロセスが早期に応答を受信できる。「送信側プロセスの優先度≦受信側プロセスの優先度」の場合には、受信側プロセスの優先度は変更されないので、受信側プロセスの優先度が低下して応答が遅れることもない。
【００１７】
また、各プロセスの優先度の高低は、開発者などがシステム設計的な視点から割り当てるため、自由に変更するとプロセス間の優先関係が崩れてしまう。すなわち、あるプロセスに低い優先度を割り当てるのは他に優先すべきプロセスがあるためであるが、「送信側プロセスの優先度＞受信側プロセスの優先度」の場合に優先度を変更したままでは優先すべきプロセスが優先されなくなるおそれがある。
【００１８】
従来は優先度を戻さないため、プロセス間通信が高頻度に発生すると、システムに存在する各プロセスの優先度が設計上のものと異なったままになり、システムのバランスが崩れ、リアルタイム性が保証されなくなったり、目的の制御ができなくなるおそれがあった。本実施形態では、受信処理の完了後、ＯＳが受信側プロセスの優先度を変更前の値に戻すので、システムに与える影響を抑制することができる。
【００１９】
〔システム構成例〕
図３は、画像形成装置のハードウェア構成図の一例である。画像形成装置１００は組み込みシステムを搭載した情報処理装置の一例である。画像形成装置はコントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２を有する。
【００２０】
コントローラ２０１は、ＣＰＵ２１１と、ＡＳＩＣ（Application Specific Integrated Circuit）２１２と、ＮＢ（ノースブリッジ）２２１と、ＳＢ（サウスブリッジ）２２２と、ＭＥＭ−Ｐ（システムメモリ）２３１と、ＭＥＭ−Ｃ（ローカルメモリ）２３２と、ＨＤＤ（ハードディスクドライブ）２３３と、メモリカードスロット２５１と、ＮＩＣ（ネットワークインタフェースコントローラ）２４１と、ＵＳＢデバイス２４２と、ＩＥＥＥ１３９４デバイス２４３と、セントロニクスデバイス２４４を有している。
【００２１】
ＣＰＵ２１１は、種々の情報処理を実行するためのＩＣであり、アプリケーションやＯＳなど汎用ＯＳによりプロセス単位で並列的に実行する。ＡＳＩＣ２１２は、画像処理用のＩＣである。ＮＢ２２１は、ＣＰＵ２１１とＡＳＩＣ２１２を接続するためのブリッジである。ＳＢ２２２は、ＮＢ２２１と周辺機器等を接続するためのブリッジである。ＡＳＩＣ２１２とＮＢ２２１は、ＡＧＰ（Accelerated Graphics Port）を介して接続されている。
【００２２】
ＭＥＭ−Ｐ２３１は、ＮＢ２２１に接続されたメモリである。ＭＥＭ−Ｃ２３２は、ＡＳＩＣ２１２に接続されたメモリである。ＨＤＤ２３３は、ＡＳＩＣ２１２に接続されたストレージであり、画像データ蓄積・文書データ蓄積・プログラム蓄積・フォントデータ蓄積・フォームデータ蓄積等を行うために使用される。メモリカードスロット２５１は、ＳＢ２２２に接続されたスロットであり、メモリカード２６１をセット（挿入）するために使用される。
【００２３】
ＮＩＣ２４１は、ネットワーク等を介してＭＡＣアドレス等を使用したデータ通信を行うためのコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格に準拠したシリアルポートを提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格に準拠したシリアルポートを提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様に準拠したパラレルポートを提供するためのデバイスである。ＮＩＣ２４１と、ＵＳＢデバイス２４２と、ＩＥＥＥ１３９４デバイス２４３と、セントロニクスデバイス２４４は、ＰＣＩ（Peripheral  Component  Interconnect）バスを介してＮＢ２２１とＳＢ２２２に接続されている。
【００２４】
メモリカードスロット２５１は、ＳＢ２２２に接続されて使用されるスロットであり、メモリカード２６１をセット（挿入）するためのスロットである。
【００２５】
オペレーションパネル２０２は、オペレータが画像形成装置１００に入力を行うためのハードウェア（操作部）であると共に、オペレータが画像形成装置１００から出力を得るためのハードウェア（表示部）である。オペレーションパネル２０２は、ＡＳＩＣ２１２に接続されている。ＦＣＵ２０３と、撮像部１２１と、印刷部１２２は、ＰＣＩ（Peripheral  Component  Interconnect）バスを介してＡＳＩＣ２１２に接続されている。
【００２６】
図４は、画像形成装置の構成図の一例である。画像形成装置１００は画像イメージを紙に転写する役割を果たす「エンジン側」と、画像処理を行ったりユーザインタフェースを提供する「コントローラ側」に分かれている。エンジン側とコントロール側はPCIやPCI−Expressなどの通信インタフェースで通信可能に接続されている。エンジン側とコントローラ側はそれぞれＣＰＵやＡＳＩＣ、ＦＰＧＡ（Field Programmable Gate Array）などの演算装置を有しており、それぞれＯＳとプログラムを実行する。
【００２７】
エンジン側は、例えばエンジンファームウェア１１やリアルタイムＯＳ１２を実行する。コントローラー側は例えば汎用ＯＳ３０やコントロールサービス２９及びアプリケーションを実行する。
【００２８】
エンジン側で動作するＯＳはリアルタイムＯＳ１２、コントローラ側で動作するＯＳは汎用ＯＳ３０とするが、これらは一例でありエンジン側とコントローラ側で動作するＯＳを制限するものではない。リアルタイムＯＳ１２には例えばＩＴＲＯＮ（登録商標）、FreeRTOS、ＴＯＰＰＥＲＳ、ＷｉｎｄｏｗｓＣＥ（登録商標）などがある。汎用ＯＳ３０には例えば、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｏｒｏｉｄ（登録商標）などがある。
【００２９】
汎用ＯＳ３０は、プロセス制御部３１、プロセス間通信制御部３２、及び、いくつかのドライバを有している。
【００３０】
通信ドライバ３３は、例えばPCI−Expressの通信規格に基づいて、リアルタイムＯＳ１２と通信する。リアルタイムＯＳ１２も同様の通信ドライバ１３を有している。ＳＤカードドライバ３４は、メモリカードスロット２５１を制御して、ＳＤカードにデータを読み書きする。ＳＤカードドライバ３４は、ＳＤカードが装着されたことを検出してＳＤカード監視常駐ＭＯＤ（モジュール）２３に通知する。ＵＳＢメモリドライバ３５は、ＵＳＢデバイス２４２を制御して、ＵＳＢメモリ５３にデータを読み書きする。ネットワークドライバ３６は、ネットワークＩ／Ｆ５４（ＮＩＣ２４１と同等の機能を提供する）を制御して、ネットワークに対しデータを送受信する。ネットワークドライバ３６は、ネットワーク管理ＭＯＤ２４からデータの送信要求を取得してネットワークＩ／Ｆ５４に設定し、また、ネットワークＩ／Ｆ５４にて受信されたデータをネットワーク管理ＭＯＤ２４に通知する。パネルドライバ３７は、パネル管理ＭＯＤ２５の制御によりオペレーションパネル２０２の表示内容を制御したり、オペレーションパネル２０２に対するユーザ操作を受け付ける。パネル管理ＭＯＤ２５は機器管理ＭＯＤ２６の指示によりオペレーションパネル２０２に表示する内容を決定し、パネルドライバ３７に指示する。ＨＤＤドライバ３８はＨＤＤ５６に対しデータを読み書きする。Ｉ２Ｃバスドライバ３９は、Ｉ２Ｃ通信規格に基づいて基板内基板間のシリアルデータ通信を行う。
【００３１】
プロセス制御部３１は、各プロセスが実行される順序を制御することで各プロセスの実行スケジュール制御し、また、ＣＰＵなどのリソースをプロセスに割り当てる。プロセス間通信制御部３２は、プロセスにwriteインタフェースやreadインタフェースを提供することで、プロセス同士が通信するプロセス間通信を可能とする。これらの詳細は後述する。
【００３２】
ＳＲＭ（System Resource Manager）２１は、コントロールサービス２９からの獲得要求を調停する。また、コントロールサービス２９はアプリケーションからの処理要求を解釈してハードウェア資源の獲得要求を発生させる。コントロールサービス２９は、複数のサービスモジュールから形成され、機器管理ＭＯＤ２６と、パネル管理ＭＯＤ２５と、ネットワーク管理ＭＯＤ２４と、ＳＤカード管理常駐ＭＯＤ２３と、画像管理ＭＯＤ２２とを有する。
【００３３】
コントロールサービス２９又はＳＲＭ２１は、あらかじめ定義された関数によりアプリケーションから処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を介して処理要求を受信する。
【００３４】
アプリケーションは、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ４１と、コピー用アプリケーションであるコピーアプリ４２と、ファクシミリ用アプリケーションであるファックスアプリ４３と、スキャナ用アプリケーションであるスキャナアプリ４４と、ネットワークファイル用アプリケーションであるネットファイルアプリ４５と、工程検査用アプリケーションである工程検査アプリ４６と、を有している。これらのアプリは一例であり、汎用ＯＳ上でプロセスとして動作するアプリであればよい。
【００３５】
汎用ＯＳ上で動作するアプリ、コントロールサービス２９、又は、ＳＲＭ２１は全て汎用ＯＳ３０のプロセス間通信制御部３２を用いて通信を行うプロセスである。なお、プロセスとは、例えばＯＳがＣＰＵを割り当てるソフトウェアの実行単位であるが、スレッド又はタスクなどと呼ばれていてもよい。
〔プロセス制御部、プロセス間通信制御部〕
図５は汎用ＯＳのうち、「プロセス制御部」の機能を、図６は「プロセス間通信制御部」の機能をそれぞれ説明する図の一例である。プロセス制御部３１は、実行すべきプロセスを選択したり、プロセスの状態遷移を行う。プロセス制御部３１は、主としてスケジューラ３１３の機能をＯＳの他の機能に対して提供する。
【００３６】
まず、プロセスの状態について説明する。プロセスの状態には大きく分けて以下3つがある。
「実行状態」・・・・・・・・・プロセスがＣＰＵの実行権を得て、ＣＰＵにより実際に実行されている状態。この状態のプロセスのプロセス構造体（プロセス構造体については図７にて説明する）は「curproc（カレントプロセス）」という場所に設定される。
「実行可能状態」・・・・・動作する準備ができており、ＣＰＵの実行権を得られさえすれば、いつでも実行可能な状態。この状態の時、プロセス構造体は「実行可能状態プロセスキュー」３１１という場所に登録される。
「休眠状態」・・・・・・・・・特定のイベントを待っている状態。イベントが完了するまでは実行可能状態にはならない。イベントには様々なものがあり、例えば、プロセス間通信、データの受信、ユーザ操作などがある。この状態の時、プロセス構造体は「休眠状態プロセスハッシュ」３１２という場所に登録される。
【００３７】
実行可能状態プロセスキュー３１１は、実行可能状態のプロセスのプロセス構造体が優先度毎に順番に登録されたキューである。プロセス構造体については後述するが、プロセス構造体にはプロセスの属性値が登録されている。
【００３８】
実行可能状態プロセスキュー３１１はプロセスの優先度毎にキューを形成している。図では１つのキューを四角で表し、丸がプロセスを表している。丸内の数字は、プロセスを一意に識別するためのプロセスＩＤである。例えば、最も優先度が高いキューにはプロセスＩＤ＝１のプロセスが登録されており、２番目に優先度が高いキューにはプロセスＩＤ＝１５と７のプロセスが登録されている。
【００３９】
また、最も優先度が低いプロセスとして、アイドルプロセスというプロセスが存在する。態になる。アイドルプロセスは、システム内に（実行可能状態プロセスキュー３１１に）他に実行可能状態のプロセスが登録されていない場合に動作するプロセスである。例えば、メンテナンスやシステムチェックを行うなどの特殊なプロセスである。
【００４０】
休眠状態プロセスハッシュ３１２は、休眠(又は待ち)状態のプロセスのデータが登録されたテーブルである。休眠状態プロセスハッシュ３１２は特許請求の範囲の休眠プロセステーブルの一例である。休眠状態プロセスハッシュ３１２の四角は、休眠要因を表す数値から作成されたインデックス（後述するハッシュキー）である。つまり、四角は休眠要因を示しており、同じ休眠要因のプロセスが順番に登録されている。
【００４１】
スケジューラ３１３は、「実行可能状態プロセスキュー」から一番高い優先度を持ったプロセスを一つ選んで、プロセスの状態を「実行状態」に遷移する。このためのＯＳのインタフェースがswitchインタフェース３１４である。また、プロセスを休眠状態に移行するためのＯＳのインタフェースが、sleepインタフェース３１８である。また、プロセスの休眠状態を解除するためのインタフェースが、wakeupインタフェース３１７である。また、inheritインタフェース３１６とuninheritインタフェース３１５は優先度を操作するためのインタフェースである。inheritインタフェース３１６は特許請求の範囲の優先度変更手段の一例である。uninheritインタフェース３１５は特許請求の範囲の復帰要求受け付け手段の一例である。
各プロセスは「プロセス構造体」というデータ構造を用いて管理されている。そして、上記のプロセスの３つの状態の遷移は、スケジューラ３１３のsleepインタフェース（特許請求の範囲の休眠要求受け付け手段の一例である）、wakeupインタフェース、及び、switchインタフェースを通して行われる。例えば、プロセスがイベント発生まで待機する際、sleepインタフェースが呼び出される（これにより休眠状態になる）。送信が行われた場合（イベントが発生した場合、wakeupインタフェースが呼び出され、休眠状態のプロセスは実行可能状態に遷移される。また、実行可能状態のプロセスを実行状態にするためswitchインタフェースが呼び出される。各インタフェースの詳細な処理フローは後述する。
【００４２】
スケジューラ３１３はＯＳ内に閉じており、ユーザプロセス（例えば、コントロールサービス２９やアプリケーション）からは直接アクセスすることができない。
【００４３】
続いて、プロセス間通信制御部３２について説明する。プロセス間通信制御部３２は２つのプロセス間で相互に通信する手段を提供するもので、送信を行うwriteインタフェース３２２（特許請求の範囲の送信要求受け付け手段の一例である）、受信を行うreadインタフェース３２３（特許請求の範囲の受信要求受け付け手段の一例である）を有する。
【００４４】
また、プロセス間通信を確立するのに必要な接続系Ｉ／Ｆ（socketインタフェース、listenインタフェース、accept インタフェース、bindインタフェース、connectインタフェース）３２１も有している。接続系Ｉ／Ｆ３２１には「サーバ向け」と「クライアント向け」のものがあるが、以下では特に区別せずに説明する。プロセスはこれらの接続系Ｉ／Ｆ３２１で通信を確立することによって、通信に使われるファイルとそれを管理するファイル構造体を作り、これらに紐付いた「ファイルディスクリプタ」を取得する。ファイルディスクリプタは、プロセスがアクセスするファイルを特定するための識別情報であり、実体はファイル構造体の位置を示すインデックスである。
【００４５】
ファイル構造体は、ファイルシステムに依存しないファイルの設定を保持している。プロセスは、ファイルディスクリプタの数値をインデックスとして該当ファイル構造体を特定する。
【００４６】
各プロセスは、汎用ＯＳ３０がファイルシステム上に作成した「tmpファイルシステム」３２４というＲＡＭ上に存在するファイル経由でプロセス間通信を行う。プロセス側はファイルが出来たことを意識する必要はなく、接続系Ｉ／Ｆ３２１で接続確立時に得られた「ファイルディスクリプタ」をwriteインタフェース又はreadインタフェースに渡すだけで通信できる。すなわち、プロセスがwriteインタフェースの呼び出し時にファイルディスクリプタとして例えばfileAを指摘すると、プロセス間通信制御部３２はtmpファイルシステム３２４のfileAの実体に通信対象のデータを書き込む。通信対象のプロセスがreadインタフェースの呼び出し時にファイルディスクリプタとしてfileAを指摘すると、プロセス間通信制御部３２はtmpファイルシステム３２４のfileAの実体から通信対象のデータを読み出す。
【００４７】
〔データフォーマットなど〕
図７（ａ）は、送受信されるデータのデータフォーマットを模式的に説明する図の一例である。データフォーマットには、送信元プロセスＩＤ、通信種別、及び、メッセージが含まれる。送信元プロセスＩＤには、送信元のプロセスのプロセスＩＤが格納される。後述するプロセスＩＤの交換時はプロセスＩＤが不明なのでプロセスは"０"を設定する。通信種別には、通信の種別として「プロセスＩＤ交換」、「通常」又は「応答」などの識別情報が格納される。メッセージには、送受信されるデータが格納される。
【００４８】
図７（ｂ）はプロセス構造体のフォーマットを模式的に説明する図の一例である。「プロセス構造体」は、汎用ＯＳ３０のプロセス制御部３１がプロセスを管理するために使うデータである。１つのプロセスごとに１つ生成される。プロセス構造体は特許請求の範囲のプロセス情報記憶部の一例である。
【００４９】
プロセス構造体には、プロセスＩＤ、プロセス優先度、プロセス優先度退避領域、フラグ、sleep時待ちメモリアドレス、ＣＰＵレジスタ値等が含まれる。
・プロセスＩＤはプロセスを一意に識別するための識別情報である。
・プロセス優先度はプロセスの優先度である。実行可能状態にあるプロセスのうち、この数値が最も大きいプロセスがＣＰＵの使用権を得て、実行状態になれる。
・プロセス優先度退避領域は、プロセスの優先度が変更された場合に元の優先度が退避されるための領域である。
・フラグは、プロセスの状態を示すためのビットマップである。ビットには、優先度が変更されたことを示す「優先度継承」などがある。
・sleep時待ちメモリアドレスは、sleep時に「何」に対して待ちになっているのかを表すアドレス値である。例えば、プロセス間通信に使用されるファイルに対応したファイル構造体のアドレスが格納される。
・ＣＰＵレジスタ値は、実行状態だった時のＣＰＵレジスタの値が格納される。再度、実行状態になる場合に、ＯＳがこの値をＣＰＵに再設定することで前回の実行状態を復元することができる。
【００５０】
図７（ｃ）は、ファイル構造体フォーマットを模式的に説明する図の一例である。ファイル構造体は、ファイルを管理するための構造体である。ファイル構造体は、ファイルシステム内のファイル１つ毎に１つ生成される。ファイル構造体はファイルの管理にももちろん使われるが、通信データの受信待ち又は受信待ちのプロセスをwakeupする際にも使用される。
【００５１】
ファイル構造体フォーマットには、vnodeパラメータが含まれる。vnodeパラメータは、該当ファイルがどのファイルシステムに存在しているのかなどを表すパラメータ群である。本実施形態ではこれを使うことで、writeインタフェース３２２又はreadインタフェース３２３が、tmpファイルシステム３２４のwriteインタフェース又はtmpファイルシステム３２４のreadインタフェースを呼び出すことができる（不図示）。tmpファイルシステム３２４のwriteインタフェースは、writeインタフェース３２２から呼び出されるインタフェースであり、プロセスは意識する必要がない。tmpファイルシステム３２４のreadインタフェースは、readインタフェース３２３から呼び出されるインタフェースであり、プロセスは意識する必要がない。
【００５２】
〔実行可能状態プロセスキューのデータ構造/休眠状態プロセスハッシュのデータ構造〕
図８（ａ）は、実行可能状態プロセスキュー３１１の構成図の一例を示す。実行可能状態プロセスキュー３１１は上記のとおりキューの配列で構成されている。これは、優先度の値の上限は通常128や256程度の数であること、優先度をそのままインデックスとしてアクセスできたほうが都合が良いということもあり、本実施形態では配列構造を採用している。例えば、優先度が0〜63の64段階の場合、実行可能状態プロセスキュー３１１の段数も64となる。
【００５３】
丸はプロセス構造体を示す。なお、該当する優先度に値がない場合、値はＮＵＬＬになる。同一優先度のプロセスが複数存在する場合、キューの先頭のプロセスから先に実行状態になる。
【００５４】
図８（ｂ）は、休眠状態プロセスハッシュ３１２の構成図の一例を示す。四角は、sleep時待ちメモリアドレスをキーとするハッシュテーブルである。ハッシュテーブルの１つの四角には、待ちの対象となっているイベントに対応するsleep時待ちメモリアドレスから作成されたハッシュキーである。すなわち、１つの四角（ハッシュキー）にはsleep時待ちメモリアドレスのファイルへの書き込みを待っているプロセスのプロセス構造体が紐づけられている。具体的にはプロセス構造体のリスト（キュー）の先頭と末尾を指すポインタが紐づけられている。
【００５５】
休眠状態プロセスハッシュ３１２は、待ちイベントを示す数値（本実施形態では主にファイルなので、何らかのデータのメモリ上のアドレス)を扱う。待ちイベントの数は、相当数（かなり大きい数）である。「理論的には」アドレスの取りうる数だけイベント数が存在することになる。例えば32bit環境の場合であれば2の32乗個のイベントの数がある。
【００５６】
そのため、待ちイベントの値自体をインデックスとする固定長の配列を用意するのは現実的でない。そこで、本実施形態ではハッシュというデータ構造を用いた。すなわち、固定長の配列という点では実行可能状態プロセスキュー３１１と同じであるが、待ちイベントを示す数値を直接インデックスにするのでなく、その値のハッシュ値をインデックスにするところが異なっている。例えば、休眠状態プロセスハッシュ３１２のテーブル個数は256個とする。
【００５７】
〔プロセス間通信の概要〕
図９は、送信側プロセスと受信側プロセスが通信する手順を示すシーケンス図の一例である。送信側がクライアント、受信側がサーバとして動作する。プロセス間通信は、大きく３つのステップに区分できる。
１．二者間での通信確立を行う接続フェーズ
２．通信を行う二者間で互いを識別するプロセスＩＤを返すプロセスＩＤ交換
３．任意の数のプロセス間通信
＜接続フェーズ＞
S1：まず、受信側プロセス（サーバ）はＯＳが用意している接続系Ｉ／Ｆ３２１を使って通信路の確立をＯＳに要求する。これにより、受信側プロセスの接続を受け入れるための準備を行う。
S2：プロセス間通信制御部３２は、tmpファイルシステム３２４にファイルを作成し、通信路を確立する。また、ファイルを特定可能なファイルディスクリプタが決定される。
S3：プロセス間通信制御部３２は、ファイルディスクリプタを受信側プロセスに通知する。
S4：その後、送信側プロセスはＯＳが用意している接続系Ｉ／Ｆ３２１を使ってＯＳに対し、受信側プロセスへの接続を要求する。
S5：プロセス間通信制御部３２は受信側プロセスに通知したファイルディスクリプタを送信側プロセスに通知する。
【００５８】
＜プロセスＩＤ交換＞
接続確立後、受信側プロセスと送信側プロセスは、まず最初にお互いの「プロセスＩＤ」を交換する。プロセスＩＤはＯＳ上で動作するプロセスを一意に識別することのできる値である。
S6：送信側プロセスはwriteインタフェースを使って送信側プロセスのプロセスＩＤをＯＳに通知する。
S7：受信側プロセスはreadインタフェースを使って送信側プロセスのプロセスＩＤを受信する。
S8：受信側プロセスはwriteインタフェースを使って受信側プロセスのプロセスＩＤをＯＳに通知する。
S9：送信側プロセスはreadインタフェースを使って受信側プロセスのプロセスＩＤを受信する。
【００５９】
プロセスＩＤにより通信の相手方を特定することができるので、以降の通信データに相手方のプロセスＩＤを付与することで、ＯＳに「どのプロセスの優先度を操作したら良いのか」を認識させることができる。
＜プロセス間通信＞
以後、プロセス間で双方向通信が行われる。プロセス間通信には２パターンある。１パターン目は、図９の双方向通信１のように送信側が先に送信を行い、ついで受信側が受信処理を行うケースである。この場合、受信側は待つことなく通信データの引取を行うことができる。そして、受信処理を行った後、送信側に返信を行う。
S10：送信側プロセスはwriteインタフェースを呼び出して送信する。送信時、ファイルディスクリプタ、送信されるデータの保存場所（送信データバッファ、送信データバッファのサイズ）が指示される。
S11：受信側プロセスはreadインタフェースを呼び出して受信する。受信時、ファイルディスクリプタ、受信したデータの保存場所（受信データバッファ、受信データバッファのサイズ）が指示される。
S12：受信側プロセスはwriteインタフェースを使って返信を送信する。
S13：送信側プロセスはreadインタフェースを使って受信する。
【００６０】
２パターン目は、図９の双方向通信２のように受信側が受信処理を先に行い、その後、送信側が送信を行うケースである。この場合、受信側プロセスが受信処理を行った時点でデータは送信されておらず、従ってデータが送信されるまで受信側プロセスは休眠状態になる。休眠状態にするため、プロセス間通信制御部（例えばreadインタフェース）はsleepインタフェースを呼び出す。通信データが送信されたら、プロセス間通信制御部（例えばwriteインタフェース）はwakeupインタフェースを呼び出して受信側プロセスを実行可能状態に遷移させる。これによって、受信側と送信側のいずれが先に動くのかに関わらず、送受信が行える。
S14：受信側プロセスはreadインタフェースを使って受信する。受信時、ファイルディスクリプタ、受信したデータの保存場所（受信データバッファ、受信データバッファのサイズ）が指示される。
S15：データがまだ送信されていないので、readインタフェースはsleepインタフェースを呼び出して受信側プロセスを休眠状態にする。また、readインタフェースは、switchインタフェースを呼び出して最も優先度が高いプロセスを実行状態に遷移させる。
S16：送信側プロセスはwriteインタフェースを使って送信する。送信時、ファイルディスクリプタ、送信されるデータの保存場所（送信データバッファ、送信データバッファのサイズ）が指示される。
【００６１】
writeインタフェースは、特定の通信を待っているプロセスがあるので、wakeUpインタフェースを呼び出して休眠状態の受信側プロセスを実行可能状態に遷移させる。
S17：受信側プロセスはwriteインタフェースを使って返信を送信する。
S18：送信側プロセスは、readインタフェースを使って受信する。
【００６２】
なお、双方向通信１，２のいずれのケースも受信側プロセスの優先度操作のタイミングは、「送信側のデータ送出完了時点（S10、S16）」である。優先度操作の処理手順については後述する。
【００６３】
〔writeインタフェースの処理フロー〕
図１０は、writeインタフェースの処理フローを示す図の一例である。
プロセスから呼び出されたwriteインタフェースは、引数として、プロセスからファイルディスクリプタ、送信データバッファ、及び、送信データのバッファサイズを受け取る。
【００６４】
writeインタフェースは、ファイルディスクリプタの値に対応したファイル構造体を取得する（Ｓ１０）。これは、通信に用いるファイルがどこのファイルシステムに所属するのかを調べるためである。
【００６５】
ファイル構造体が取得できない場合（Ｓ２０のＮｏ）、戻り値に「異常」をセットして処理は終了する（Ｓ３０）。
【００６６】
ファイル構造体が取得できた場合（Ｓ２０のＹｅｓ）、writeインタフェースはファイル構造体内のvnode情報を使って対応するファイルシステムのwriteインタフェースを呼び出す（Ｓ４０）。具体的には、tmpファイルシステム３２４のwriteインタフェースが呼ばれる。ファイルのデータ配置などはファイルシステムによって異なるが、ファイル構造体内の「vnode情報」を用いることでファイルシステムを特定できる。そして、該当するファイルのファイルシステムごとに用意されたＯＳ内部インタフェースを呼び出すことで、具体的なファイルアクセスを行うことができる。
【００６７】
次いで、writeインタフェースは、戻り値に「正常」をセットして処理を終了する（Ｓ５０）。
【００６８】
このように、「tmpファイルシステム」上に、通信に用いるファイルが作られるので、tmpファイルシステム向けのwriteインタフェースをvnode情報により呼び出すことで通信できる。
【００６９】
図１１は、tmpファイルシステム３２４のwriteインタフェースの処理フローを示す図の一例である。図１０のステップＳ４０の処理について説明する。tmpファイルシステム３２４のwriteインタフェースは、引数として以下の３つの情報を取得して、処理を行う。
・ファイル構造体
・送信データバッファ
・送信データバッファのサイズ
また、処理内容は主に以下の３つである。
・送信データをファイルに書き込む
・受信側プロセスの優先度操作
・相手側への切り替え処理
tmpファイルシステム３２４のwriteインタフェースは、ファイル構造体に対応したファイルにデータを書き込むことで、データを「送信」する（Ｓ４１）。
【００７０】
次に、この送信が応答のためのものか否かを判定する（Ｓ４２）。これは、送受信データフォーマットの通信種別により判定される。
【００７１】
応答でない場合（Ｓ４２のＮｏ）、tmpファイルシステム３２４のwriteインタフェースはinheritインタフェースを呼び出して、受信側プロセスの優先度を上げる（Ｓ４３）。すなわち、応答のためのものでなければ通信開始を意味するので、「送信側プロセスの優先度＞受信側プロセスの優先度」の場合に限り、受信側となるプロセスの優先度を送信側プロセスの優先度と同一の値にする。  
応答の場合（Ｓ４２のＹｅｓ）、受信処理の完了を意味するので、受信側プロセスの優先度を元に戻すため、tmpファイルシステム３２４のwriteインタフェースはuninheritインタフェースを呼び出して、受信側プロセスの優先度を元に戻す（Ｓ４４）。したがって、応答か否かを判定することで確実に受信側プロセスの優先度を元に戻すことができる。
【００７２】
tmpファイルシステム３２４のwriteインタフェースは、通信データ待ちのプロセスに対して、通信データが来たことを通知する（Ｓ４５）。すなわち、tmpファイルシステム３２４のwriteインタフェースはwakeupインタフェースを呼び出して受信側プロセスを起こす。これにより休眠状態の受信側プロセスは実行可能状態になる。
【００７３】
ついで、tmpファイルシステム３２４のwriteインタフェースは、switchインタフェースを使ってプロセスの再スケジューリングを行う（Ｓ４６）。これにより、いち早く受信側に処理を切り替えることが可能になる。
【００７４】
〔readインタフェースの処理フロー〕
図１２は、readインタフェースの処理フローを示す図の一例である。プロセスから呼び出されたreadインタフェースは、引数として、プロセスからファイルディスクリプタ、受信データバッファ、及び、受信データのバッファサイズを受け取る。
【００７５】
処理手順はwriteインタフェースとほぼ同様であり、ファイル構造体を取得し、通信に使うファイルがtmpファイルシステム３２４にあることを判別する。そして、tmpファイルシステム３２４のreadインタフェースを呼び出す。
【００７６】
readインタフェースは、ファイルディスクリプタの値に対応したファイル構造体を取得する（Ｓ１１０）。これは、通信に用いるファイルがどこのファイルシステムに所属するのかを調べるためである。
【００７７】
ファイル構造体が取得できない場合（Ｓ１２０のＮｏ）、戻り値に「異常」をセットして処理は終了する（Ｓ１３０）。
【００７８】
ファイル構造体が取得できた場合（Ｓ１２０のＹｅｓ）、readインタフェースはファイル構造体内のvnode情報を使って対応するファイルシステムのreadインタフェースを呼び出す（Ｓ１４０）。具体的には、tmpファイルシステム３２４のreadインタフェースが呼ばれる。ファイルのデータ配置などはファイルシステムによって異なるが、ファイル構造体内の「vnode情報」を用いることで、tmpファイルシステム３２４のreadインタフェースを特定できる。該当するファイルのファイルシステムごとに用意されたＯＳ内部のインタフェースを呼び出すことで、具体的なファイルアクセスを行うことができる。
【００７９】
readインタフェースは、戻り値に「正常」をセットして処理を終了する（Ｓ１５０）。
【００８０】
図１３は、tmpファイルシステム３２４のreadインタフェースの処理フローを示す図の一例である。図１２のステップＳ１４０の処理について説明する。
tmpファイルシステム３２４のreadインタフェースは、引数として以下の３つの情報を取得して、処理を行う。
・ファイル構造体
・受信データバッファ
・受信データバッファのサイズ
また、処理内容は主に以下の２つである。
・受信すべきデータがない場合はsleepインタフェースを呼び出して受信側プロセスを休眠状態に設定する
・受信データの引き取り
まず、tmpファイルシステム３２４のreadインタフェースは、受信データが送信されているか否かを判定する（Ｓ１４１）。これはファイル構造体にて特定されるファイルのサイズが"０"か否かで判別できる。
【００８１】
受信データが来ていない場合（Ｓ１４１のＹｅｓ）、tmpファイルシステム３２４のreadインタフェースは送信データが送信されるまで待機する（Ｓ１４２）。具体的には、「sleepインタフェース」を呼び出して受信側プロセスを休眠状態にする。また、sleepインタフェースの呼び出し時、ファイル構造体のアドレスをプロセス構造体のsleep時待ちメモリアドレスに設定することで、受信側プロセスが送信を待っているファイルを特定可能にする。
【００８２】
受信データが送信されていた場合（Ｓ１４１のＮｏ）、tmpファイルシステム３２４のreadインタフェースは、ファイル構造体のvnode情報によりtmpファイルを特定し、tmpファイルから受信データバッファにデータをコピーする（Ｓ１４３）。これにより、送信側プロセスからデータを受信できる。
【００８３】
〔スケジューラインタフェース〕
以下では、writeインタフェース及びreadインタフェースで用いるスケジューラ３１３のインタフェースについて説明する。
【００８４】
・ sleepインタフェース
sleepインタフェースは、指示されたプロセスを休眠状態するためのインタフェースである。sleepインタフェースは、引数として、メッセージが書き込まれるtmpファイルのファイル構造体のアドレス（sleep時待ちメモリアドレス）を受け取る。
【００８５】
図１４はsleepインタフェースの処理フローの一例を示す図である。
sleepインタフェースは、readインタフェースなどから受け取ったsleep時待ちメモリアドレスからハッシュのキーを作成する（Ｓ１１０１）。例えば、アドレス値のbit15〜8の8bitを用いてキーを作成すれば、256通りのキーのいずれかが生成できる。
【００８６】
sleep時待ちメモリアドレスを使わなくても、sleep/wakeupのペア間でイベントを一意に識別できる値であればよい。しかし、一意に識別できる値を別途作成するためのアルゴリズムを別途実装するのは煩雑なため、待ち対象のイベントに関係したデータ構造のメモリ上のアドレスを使うことが汎用ＯＳ内のsleepインタフェースでは一般的である。
【００８７】
sleepインタフェースは、呼び出された受信側プロセスのプロセス構造体を、休眠状態プロセスハッシュ３１２の該当するハッシュキーの末尾に登録する（Ｓ１１０２）。これにより、受信側プロセスを休眠状態に遷移できる。
【００８８】
この後、休眠したプロセスは、データが送信されるとwakeupインタフェースにより実行可能状態になり、さらにswitchインタフェースを用いて実行状態に遷移される（Ｓ１１０３）。
【００８９】
・wakeupインタフェース
wakeupインタフェースは引数で渡されたsleep時待ちメモリアドレスが、プロセス構造体に登録されたプロセスを全て実行可能状態にする。wakeupインタフェースは、引数としてsleep時待ちメモリアドレスを受け取る。
【００９０】
図１５は、wakeupインタフェースの処理フローの一例を示す図である。
wakeupインタフェースは、writeインタフェースなどから受け取ったsleep時待ちメモリアドレスからハッシュのキーを生成する（Ｓ１３０１）。
【００９１】
以降、休眠状態プロセスハッシュ３１２のハッシュのキーに登録されているプロセス構造体の末尾まで繰り返し処理する。
【００９２】
wakeupインタフェースは、生成したハッシュのキーに対応するプロセス構造体を１つ取り出す（Ｓ１３０２）。
【００９３】
wakeupインタフェースは、プロセス構造体内の「sleep時待ちメモリアドレス」と受け取った（引数の）「sleep時待ちメモリアドレス」が等しいか否かを判定する（Ｓ１３０３）。これはwakeupのイベント通知の対象となるイベントで待っているプロセスを探すためである。
【００９４】
２つの「sleep時待ちメモリアドレス」が等しくない場合（Ｓ１３０３のＮｏ）、wakeupインタフェースは、次のプロセス構造体を１つ取り出す（Ｓ１３０５）。
【００９５】
２つの「sleep時待ちメモリアドレス」が等しい場合（Ｓ１３０３のＹｅｓ）、wakeupインタフェースは、プロセス構造体を休眠状態プロセスハッシュ３１２から抜き、該当プロセスのプロセス優先度に対応した実行可能状態プロセスキュー３１１の要素の末尾に登録する（Ｓ１３０４）。これにより、プロセスの状態が休眠状態から実行可能状態に遷移される。
【００９６】
・inheritpriインタフェース
inheritpriインタフェースは指定されたプロセスの優先度を指定された優先度に設定する。ただし、変更は指定された優先度が元の優先度よりも高い場合に限られる。inheritpriインタフェースは、引数として、優先度変更対象プロセスのプロセスＩＤ、及び、優先度を受け取る。
【００９７】
図１６は、inheritpriインタフェースの処理フローの一例を示す図である。本実施形態において、inheritpriインタフェースはwriteインタフェースから呼ばれる。writeインタフェースでは「受信側プロセスのプロセスＩＤ」と「自分自身の優先度(=送信側プロセスの優先度)」をinheritpriに渡す。
【００９８】
inheritpriインタフェースは、引数で渡されたプロセスＩＤに対応したプロセス構造体を取得する（Ｓ１４０１）。
【００９９】
次に、inheritpriインタフェースは、プロセス構造体内の「プロセス優先度」が引数で渡された優先度より高いか否かを判定する（Ｓ１４０２）。
【０１００】
プロセス構造体内の「プロセス優先度」が引数で渡された優先度より高い場合（Ｓ１４０２のＹｅｓ）、優先度を変更すると送信側プロセスより優先度が下がってしまうので、優先度を変更しない。
【０１０１】
プロセス構造体内の「プロセス優先度」が引数で渡された優先度より高くない場合（Ｓ１４０２のＮｏ）、inheritpriインタフェースは、プロセス構造体内の現「プロセス優先度」をプロセス構造体内の「プロセス優先度退避領域」に退避する（Ｓ１４０３）。これにより、後で優先度値を戻すことができる。
【０１０２】
次に、inheritpriインタフェースは、プロセス構造体内の「プロセス優先度」を引数で渡された優先度に変更する（Ｓ１４０４）。
【０１０３】
inheritpriインタフェースは、プロセス構造体内の「フラグ」の「優先度承継」ビットをＯＮに設定する（Ｓ１４０５）。以上のように、受信側プロセスの優先度＜送信側プロセスの優先度の場合にのみ、受信側プロセスの優先度を変更できる。
【０１０４】
なお、変更後の優先度は引数の優先度（送信側プロセスの優先度）である必要はなく、プロセス構造体内の「プロセス優先度」より高ければよい。しかし、送信側プロセスと受信側プロセスの優先度が同じであれば、送信側プロセスが送信したデータを遅延なく受信できると考えられる。したがって、送信側プロセスと受信側プロセスの優先度は、完全に一致しなくてもよいものの同程度（例えば、８０％〜１２０％）とする。しかしながら、変更後の優先度は、プロセス構造体内の「プロセス優先度」より１つ大きいだけでもよいし、送信側プロセスの優先度より大きくてもよい。
【０１０５】
・uninheritpriインタフェース
uninheritpriインタフェースは指定されたプロセスの優先度がinheritpriインタフェースにより変更されている場合、優先度を変更前の値に戻すインタフェースである。uninheritpriインタフェースは、引数として優先度を戻したいプロセスのプロセスＩＤを受け取る。uninheritpriインタフェースは、writeインタフェースから呼ばれる。
【０１０６】
図１７は、uninheritpriインタフェースの処理フローの一例を示す図である。
uninheritpriインタフェースは、引数で渡されたプロセスＩＤに対応したプロセス構造体を取得する（Ｓ１５０１）。
【０１０７】
プロセス構造体内の「フラグ」の「優先度継承」ビットがＯＮか否かを判定する（Ｓ１５０２）。
【０１０８】
プロセス構造体内の「フラグ」の「優先度継承」ビットがＯＮでない場合（Ｓ１５０２のＮｏ）、inheritpriインタフェースにより優先度が変更されていないので、何もしない。
【０１０９】
プロセス構造体内の「フラグ」の「優先度継承」ビットがＯＮの場合（Ｓ１５０２のＹｅｓ）、uninheritpriインタフェースは、プロセス構造体内の「プロセス優先度退避領域」に保存してあった優先度を、プロセス構造体内の「プロセス優先度」に設定する（Ｓ１５０３）。
【０１１０】
uninheritpriインタフェースは、プロセス構造体内の「フラグ」の「優先度継承」ビットをOFFに設定する（Ｓ１５０４）。
【０１１１】
・switchインタフェース
switchインタフェースは、実行可能状態プロセスキュー３１１の中を探索し、優先度が一番高い実行可能状態のプロセスを実行状態にする。引数はない。switchインタフェースは、例えばreadインタフェース又はwriteインタフェースから呼ばれる。
【０１１２】
図１８は、switchインタフェースの処理フローの一例を示す図である。
switchインタフェースは、実行可能状態プロセスキュー３１１の優先度が高い順に、プロセスがあるか否かを判定する（Ｓ１６０１）。
【０１１３】
プロセスがある場合（Ｓ１６０１のＮｏ）、switchインタフェースはキューの先頭のプロセス構造体を抜き出す（Ｓ１６０２）。優先度の高い順に検索しているので、一番最初に見つかったプロセスが一番優先度が高い。
【０１１４】
switchインタフェースは、プロセス構造体内のＣＰＵレジスタ値に保存されている値をＣＰＵに再設定する（Ｓ１６０３）。
【０１１５】
ついで、curproc（カレントプロセス）の値をプロセス構造体の値とする（Ｓ１６０４）。これにより、優先度が一番高い実行可能状態のプロセスが実行される（実行状態になる）。これにより、休眠状態のプロセスが実行可能状態となり、早期に処理を進めることができる。
【０１１６】
最も優先度が低いプロセスまで検索してもプロセスがない場合（Ｓ１６０１のＹｅｓ）、switchインタフェースはアイドルプロセスのプロセス構造体内のＣＰＵレジスタ値に保存されている値をＣＰＵに再設定する（Ｓ１６０５）。すなわち、実行可能状態プロセスキュー３１１には1つも実行可能状態なプロセスがないため、アイドルプロセスを実行する。
【０１１７】
switchインタフェースは、curproc（カレントプロセス）の値をアイドルプロセスのプロセス構造体の値とする（Ｓ１６０６）。これにより、アイドルプロセスが実行される。
【０１１８】
以上説明したように、本実施形態の情報処理装置は、「送信側プロセスの優先度＞受信側プロセスの優先度」の場合にのみ、受信側プロセスの優先度が送信側プロセスの優先度と同じ値に設定されるので、優先度が高い送信側プロセスが早期に応答を受信できる。プロセス間通信後は、受信側プロセスの優先度を元に戻すので、システムへの影響を抑制できる。
【符号の説明】
【０１１９】
３１    プロセス制御部
３２    プロセス間通信制御部
１００  画像形成装置
３１１  実行可能状態プロセスキュー
３１２  休眠状態プロセスハッシュ
３２２  writeインタフェース
３２３  readインタフェース
【先行技術文献】
【特許文献】
【０１２０】
【特許文献１】特開平06−301655号公報
【図１】
2015056109.tif 000003
【図２】
2015056109.tif 000004
【図３】
2015056109.tif 000005
【図４】
2015056109.tif 000006
【図５】
2015056109.tif 000007
【図６】
2015056109.tif 000008
【図７】
2015056109.tif 000009
【図８】
2015056109.tif 000010
【図９】
2015056109.tif 000011
【図１０】
2015056109.tif 000012
【図１１】
2015056109.tif 000013
【図１２】
2015056109.tif 000014
【図１３】
2015056109.tif 000015
【図１４】
2015056109.tif 000016
【図１５】
2015056109.tif 000017
【図１６】
2015056109.tif 000018
【図１７】
2015056109.tif 000019
【図１８】
2015056109.tif 000020