JP4962026B2

JP4962026B2 - プロセス管理機能をもつユーザレベルプロセス制御装置、その方法及びそのプログラム

Info

Publication number: JP4962026B2
Application number: JP2007021403A
Authority: JP
Inventors: 一久石坂
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2007-01-31
Filing date: 2007-01-31
Publication date: 2012-06-27
Anticipated expiration: 2027-01-31
Also published as: JP2008186383A

Description

本発明は、ＯＳ（オペレーティングシステム）がプロセスを管理する計算機における、プロセス管理機能をもつユーザレベルプロセス制御装置、方法及びそのプログラムに関し、特にオペレーティングシステムを修正することなく、ユーザレベルの制御プロセスが、ユーザレベルの被制御プロセスを制御するユーザレベルのプロセス管理機能をもつユーザレベルプロセス制御装置、その方法及びそのプログラムに関する。

従来、複数のプログラムが動作する計算システムでは、プログラムはプロセスまたはスレッド（以下、単プロセスと記載した場合は、プロセスまたはスレッドを指すものとする）と呼ばれる実行単位で表される。当該複数のプログラムが動作する計算システムでは、適切にプロセスの動作を制御することが求められている。

例えば、リアルタイム処理を行っているプロセスがある場合、当該プロセスが優先的にＣＰＵを利用するように制御することで、リアルタイムに処理を行うべきとの制約を満たすことができるようになる。また、他にもプロセス制御の方法としては各プロセスに対してのメモリ使用量の制御や利用可能なネットワーク帯域の制御などを行うことが挙げられる。

一般に、上記のような複数のプロセスが動く計算システムでは、ＯＳ（オペレーティングシステム）がプロセスを制御する。そのため、利用しているＯＳが持っているプロセス制御機能が、計算システム上で動作させるプロセス集合に対して必要なプロセス制御を行うことができない場合は充分に必要な性能を得ることができない。

例えば、ＯＳのプロセス制御機能のひとつである、プロセスのＣＰＵへの割り当てを決定するスケジューラが、特別なプロセス管理を行わず、全てのプロセスを均等にＣＰＵへ割り当てるという制御を行う場合は、リアルタイム処理を行っているプロセスに十分なＣＰＵ利用時間を与えることができないという問題が生じる。

そのような場合の解決手段として、まずＯＳそのものを変更する方法が考えられる。そして具体的には、（１）要求性能を満たすようなプロセス制御が可能な、別のＯＳを用いる方法と、（２）現在利用しているＯＳを修正して機能拡張する方法、が考えられる。

ここで、上記（１）の例の実現のためにはリアルタイム処理に適したリアルタイムＯＳを導入することが挙げられる。しかし、一般にＯＳが異なる場合は、プログラムの互換性はないため、ＯＳを変更して使用を継続するためにはプログラムを変更後のＯＳに対応できるように修正しなければならないという問題がある。

一方、（２）の方法については、ＯＳの修正には専用の知識が必要であるという問題がある。更にそれに加えて、商用ＯＳなどはソースコードの入手が不可能である場合が多い。

また、たとえソースコードの入手が可能であってもＯＳの修正を行った場合は、メーカサポートの対象外になるなどのサポート体制の問題などで、やはり変更を行うこと自体が困難である。

このようにＯＳの変更が困難な場合の解決手段として、ユーザレベルプロセス制御がある。ユーザレベルプロセス制御では、ＯＳ上で動作するユーザレベルのプロセスが制御プロセスとなり、その他のプロセスに対して制御を行う。この場合にはＯＳの変更は必要ない。

この場合、一般にＯＳはプロセス毎に属性を設定し、その属性に従ってプロセス制御を行う。また、ＯＳはプロセスの属性をユーザレベルから変更するためのＡＰＩを提供している。したがって、ユーザレベルの制御プロセスは、そのＡＰＩを用いて被制御プロセスの属性を変更することによって、プロセス制御を行う。

特許文献１では、上述のようなプロセスの属性情報を用いてプロセス制御を行う技術について開示されている。

一方、特許文献２では、ユーザレベルのプロセス制御に関する技術が開示されている。同文献では、なかでもユーザレベルの制御プロセスによって、被制御プロセスのＣＰＵへのスケジューリングを制御するユーザレベルプロセススケジューラについて述べられている。

特許文献２では、制御プロセスであるユーザレベルプロセススケジューラが、制御対象として登録されている複数の被制御プロセスに対して、そのプロセスの属性である優先度や実行可能／停止状態を変更する。ここで、例として当該ＯＳのプロセススケジューラが、ＣＰＵを最高優先度のプロセスに対し優先的に割り当てるという動作をする場合を考える。

このようなＣＰＵを特定の被制御プロセスに対し優先的に割り当てたいときは、そのプロセスの優先度を最高にし、それ以外の被制御プロセスの優先度を下げることによって、ＯＳのプロセススケジューラが、当該最高優先度のプロセスをＣＰＵに割り当てるように制御する。
特開平１０−０２１０９９号公報特開平９−５４６９９号公報

上記のような、従来のユーザレベルプロセス制御の第一の問題点は、被制御プロセスが新たに子プロセスを生成した場合に、制御プロセスが当該生成された子プロセスを制御できないことである。

その理由は、制御プロセスは被制御プロセスが子プロセスを生成したことを知る機能を有していないためである。すなわち、プロセスの生成はＯＳが行い、生成されたプロセスのＩＤは親プロセスに直接通知される。つまり、ＯＳや親プロセス以外のプロセスとは無関係に子プロセスの生成が行われる。

よって、制御プロセスは、被制御プロセスと親子関係がない以上、子プロセスが生成されたことを知る機能を持つような特別な場合をのぞき、子プロセスが生成されたことを知ることができない。そのため、制御プロセスは当該新たに生成された子プロセスに対してプロセス制御を行うための属性変更ができない。

そのため、プログラムが親プロセスとその子孫のプロセスからなる複数のプロセスから構成される場合であっても、制御プロセスは親プロセスしか制御できないことになる。したがって、制御プロセスは、プログラムの一部しか制御をすることができず、そのプログラムが全体として十分な性能で動くように制御できないという問題がある。

この点、特許文献２で述べられている上記問題点の従来の解決例では、生成された子プロセスを制御対象に加えるためには、子プロセス自身が制御プロセスに対し被制御プロセスとしての加入要求を行うという解決手段がとられている。よって、当該方式を採用するためには、子プロセスとなるプログラムが制御プロセスに対し被制御プロセスとしての加入要求を行うように、予めプログラムを変更する必要がある。

もっとも、当該プログラム変更に際しては、制御プロセスのソースコードが必ずしも入手可能でないことや、たとえ、ソースコードが入手できたとしても、変更には相応のコストを要する。よって、当該従来例のように被制御プロセスを変更することなく、子プロセスの生成を知ることが課題であるといえる。

次に、第二の問題点は制御プロセスが、被制御プロセスの消滅を知ることができないために、制御対象から当該消滅した被制御プロセスを除外できないことである。その理由は上記のように、制御プロセスが、被制御プロセスの消滅を知る機能を持たないためである。

このため、被制御プロセスがすでに消滅した場合であっても、制御プロセスは存在しない被制御プロセスに対しても制御を行い続けることとなり、システム全体の性能が劣化するという問題がある。

以上より、本発明は、被制御プロセスによる子プロセスの生成及び被制御プロセスの消滅を、制御プロセスが知ることを第一の目的とする。更に、プロセス制御の対象とする必要がある全てのプロセスに対して、制御プロセスが属性変更を行うことができるユーザレベルプロセス制御機構を提供することを第二の目的とする。

本発明の第１の観点によれば、ユーザレベルの制御プロセスによりプロセス制御を行うユーザレベルプロセス制御装置が行うユーザレベルプロセス制御方法において、前記ユーザレベルプロセス制御装置は、第１のシステムコールに応じて子プロセスの生成を行う生成機能と、第２のシステムコールに応じて被制御プロセスを消滅させる消滅機能とを備えたＯＳと、ダイナミックリンカと、前記生成機能の実行を前記第１のシステムコールの発行により前記ＯＳに依頼するための第１の関数と、前記消滅機能の実行を前記第２のシステムコールの発行により前記ＯＳに依頼するための第２の関数とを有するシステムライブラリと、前記第１の関数と同名の関数であって、且つ、前記生成機能の実行を前記第１の関数を呼び出すことによって依頼する機能及び前記生成を前記制御プロセスに通知する生成通知機能を備えた第３の関数と、前記第２の関数と同名の関数であって、且つ、前記消滅機能の実行を前記第２の関数を呼び出すことによって依頼する機能及び前記消滅を前記制御プロセスに通知する消滅通知機能を備えた第４の関数とを有するカスタムライブラリと、を有し、前記制御プロセスの実行時に、前記ダイナミックリンカにより、前記システムライブラリと前記カスタムライブラリとを前記被制御プロセスにリンクすると共に、関数を検索する順番の上位として前記カスタムライブラリを指定する、ことを特徴とする、ユーザレベルプロセス制御方法が提供される。
また、本発明の第２の観点によれば、ユーザレベルの制御プロセスによりプロセス制御を行うユーザレベルプロセス制御装置が行うユーザレベルプロセス制御方法において、前記ユーザレベルプロセス制御装置は、第１のシステムコールに応じて子プロセスの生成を行う生成機能と、第２のシステムコールに応じて被制御プロセスを消滅させる消滅機能とを備えたＯＳと、ダイナミックリンカと、前記生成機能の実行を前記第１のシステムコールの発行により前記ＯＳに依頼するための第１の関数と、前記消滅機能の実行を前記第２のシステムコールの発行により前記ＯＳに依頼するための第２の関数とを有するシステムライブラリと、前記第１の関数と同名の関数であって、且つ、前記生成機能の実行を、前記第１のシステムコールを発行することによって直接前記ＯＳに依頼する機能及び前記生成を前記制御プロセスに通知する生成通知機能を備えた第３の関数と、前記第２の関数と同名の関数であって、且つ、前記消滅機能の実行を、前記第２のシステムコールを発行することによって直接前記ＯＳに依頼する機能及び前記消滅を前記制御プロセスに通知する消滅通知機能を備えた第４の関数とを有するカスタムライブラリと、を有し、前記制御プロセスの実行時に、前記ダイナミックリンカにより、前記システムライブラリと前記カスタムライブラリとを前記被制御プロセスにリンクすると共に、関数を検索する順番の上位として前記カスタムライブラリを指定する、ことを特徴とする、ユーザレベルプロセス制御方法が提供される。
更に、本発明の第３の観点によれば、上記本発明の第１の観点又は上記本発明の第２の観点により提供される前記ダイナミックリンカ、前記システムライブラリ及び前記カスタムライブラリを含むプログラムが提供される。

本発明によれば、ユーザレベルプロセス制御システムにおいて、制御プロセスが制御対象とする必要のあるプロセスを正確に把握することにより、プロセスが子プロセスを生成したり、プロセスが消滅したりする場合にも、プロセスを適切に制御することが可能になる。

発明を実施するための最良の形態について図面を参照して詳細に説明する。
まず、本発明の概略を、図１を用いて説明する。制御プロセス１１０はプロセス管理機能部１１１を備え、制御プロセスのプロセス管理機能は、被制御プロセス１２０による子プロセス生成時と被制御プロセスの消滅時に通知を受け取ることを特徴とする。

制御プロセスのプロセス管理機能部１１１は、子プロセス生成の通知２１０を受けると、子プロセスを被制御プロセス表１１２に追加し、被制御プロセス表を正確な状態に更新する。

また、プロセス管理機能部１１１は、被制御プロセスの消滅の通知２２０を受けると、被制御プロセス表１１２から当該プロセスを削除する。これにより不要なプロセスを被制御プロセス表から除外し、被制御プロセス表を正確な状態に更新する。

上記より、被制御プロセスが生成または消滅する場合も、被制御プロセス表が正確な状態に保たれているため、制御プロセスの属性変更機能１１２は、必要な全てのプロセスに対して、ＯＳ１３０のプロセステーブル１３１に記録されている属性を変更することができる。

ＯＳ１３０のプロセス制御機能部１３２は、プロセステーブル中の属性を参照してプロセス制御を行う。

図２は本発明の実施形態の基本的構成を示す図面である。当該実施の形態は、制御プロセス１１０、被制御プロセス１２０、ＯＳ１３０、プロセス生成検出部３１０、プロセス消滅検出部３２０を備える。制御プロセス１１０は、プロセスの属性変更機能部１１２と被制御プロセス表１１３及びプロセス管理機能部１１１を備える。

本実施の形態は、制御プロセス１１０のプロセス管理機能部１１１が、ユーザレベルのプロセス生成検出部３１０とプロセス消滅検出部３２０を利用することを特徴とする。

まず、ＯＳ１３０は、プロセスの情報を保持するプロセステーブル１３１と、プロセス制御機能部１３２を有する。ＯＳ１３０のプロセス制御機能部１３２はプロセステーブル１３１に記録されているプロセスの属性にしたがって、プロセス制御を行う。

次に、制御プロセス１１０の属性変更機能部１１２は、ＯＳ１３０の提供するＡＰＩを用いてプロセステーブル１３１に記録されている被制御プロセス１２０の属性を変更する。制御プロセス１１０の被制御プロセス表１１３は、制御プロセスが制御対象としているプロセスを記録する。

また、新たに子プロセス生成があった場合には、検出制御プロセス１１０のプロセス管理機能部１１１は、プロセス生成検出部３１０を利用して、被制御プロセス１２０の子プロセス生成を検出し、検出された子プロセスを被制御プロセス表１１３に追加する。更に、被制御プロセスの消滅があった場合には、制御プロセス１１０のプロセス管理機能部１１１は、プロセス消滅検出部３２０を利用し、被制御プロセス１２０の消滅を検出し、被制御プロセス表１１３から削除する。

プロセス生成検出部３１０は、ユーザレベルにあり、プロセスの子プロセス生成を検出し、生成を監視している制御プロセス１１０に通知する機能を有する。プロセス消滅検出部３２０はユーザレベルにあり、上記生成の場合と同様に、プロセスの消滅を検出し、消滅を監視している制御プロセス１１０に通知する機能を有する。

次に、本実施の形態の動作に付いて図３乃至図５を用いて詳細に説明する。なお、説明では便宜のために簡略化し、被制御プロセスとしてひとつのプロセスのみを表示している。

図３は、制御プロセス１１０が被制御プロセスＡ１２０に対して制御を行う動作を示している。

ここで、動作としては以下の通りである。まず、制御プロセスが、プロセスＡ１２０に対して制御を行うためにプロセステーブル１３１中のプロセスＡ１２０の属性の変更を示している（Ｓ１０）。次にＯＳ１３０のプロセス制御機能部１３２がプロセステーブル１３１に記録されているプロセスＡ１２０の属性を読み出すことを表している（Ｓ１１）。更に、ＯＳ１３０のプロセス制御機能部１３２が、属性にしたがって、プロセスＡ１２０を制御することを表している（Ｓ１２）。

図４は、制御プロセスがユーザレベルのプロセス生成検出部３１０を利用して、被制御プロセスＡ１２０による子プロセスＢ１２２の生成を検出する場合の動作を示している。まず、プロセスＡ１２０が子プロセスＢ１２２を作成する（Ｓ２０）。それにつきプロセス生成検出部３１０がプロセスＢ１２２の生成の検出する（Ｓ２１）。

そして、プロセス生成検出部３１０は制御プロセス１１０へ子プロセスの生成を通知する（Ｓ２２）。次に、通知を受けた制御プロセス１１０のプロセス管理機能部１１１は、今回新たに生成されたプロセスＢ１２２を被制御プロセス表１１３に登録する（Ｓ２３）。

この際、制御プロセス１１０の属性変更機能部１１２は、プロセスＢ１２２が制御対象であることを把握し、ＯＳ１３０のプロセステーブル１３１の属性を変更する（Ｓ２４）。

図５は、制御プロセス１１０がユーザレベルのプロセス消滅検出部３２０を利用して、被制御プロセスＢ１２２の消滅を検出する動作を示している。まず、プロセス消滅検出部３２０がプロセスＢ１２２の消滅を検出する（Ｓ３０）。次に、プロセス消滅検出部３２０が制御プロセス１１０にプロセスＢ１２２の消滅を通知する（Ｓ３１）。制御プロセス１１０のプロセス管理機能部１１１は、被制御プロセス表１１３からプロセスＢ１２２を削除する（Ｓ３２）。
［実施形態］
次に、具体的な実施形態を用いて、本発明を実施するための最良の形態の動作について説明する。本発明の第１の実施形態の構成を図６に示す。なお、ここで以下に述べる実施形態は、本発明の第１の実施形態に対応するものであるが、図６では制御プロセスの属性変更機能は省略してある。

本実施形態は、被制御プロセス１２０による子プロセスの生成の際や被制御プロセスの終了の際に呼び出されるライブラリ関数がダイナミックリンクされている場合に用いられるものである。

また、本実施形態は、ユーザレベルのプロセス生成検出部及びプロセス消滅検出部として、ダイナミックリンカ及び当該ダイナミックリンカに備えられるダイナミックリンクライブラリを利用することを特徴とするものである。

プロセスが子プロセスを生成する場合やプロセスの終了を行う場合は、ＯＳにそれらの処理を依頼するためのシステムコールを行う。この点、一般的にはプロセスが直接システムコールを行うのではなく、システムライブラリ中の専用の関数を呼び出して、当該ライブラリ関数内でシステムコールが実行される。

したがって、子プロセス生成やプロセス終了時に呼び出されるライブラリ関数が、制御プロセスへの通知機能を持つ場合であれば、子プロセスの生成やプロセスの終了を検出して、更にそれを制御プロセスへ通知をするということまでもが可能となる。

ライブラリ関数がダイナミックリンクされている場合は、ダイナミックリンカがプロセスの実行時にリンクを解決する。図６のシステムライブラリ４２０は、システムにもともと備わっているライブラリを示している。ここで、当該システムライブラリ４２０中の関数は、制御プロセスへの通知機能を持っていない。

一方、図６のカスタムライブラリ４３０は、システムライブラリ４２０の関数と同じ関数名ではあるが、プロセス生成や消滅といった本来の機能に加えて、制御プロセスへの通知機能を持つ関数をも含むライブラリである。

ダイナミックリンカ４１０によって、被制御プロセス１２０から呼び出されるライブラリ関数として、システムライブラリ４２０中の関数ではなく、カスタムライブラリ４３０中の関数がリンクされる。つまり、システムライブラリ４２０中の関数ではなく、カスタムライブラリ４３０中の関数が呼ばれることとなる。

これにより、カスタムライブラリ４３０中の関数が子プロセス生成や被制御プロセスの消滅の検出を行い、さらに、当該生成や消滅の事実を、制御プロセス１１０へ通知することとなる。

ここで、ダイナミックリンカ４１０によってリンクされる関数を、システムライブラリ４２０中の関数でなく、カスタムライブラリ４３０中の関数とする当該置き換え作業は、ダイナミックリンカ４１０が、ライブラリ関数を検索する順番の上位として、カスタムライブラリ４３０を指定することによって行うことができる。

また、Ｌｉｎｕｘ（登録商標）で広く利用されているＧｎｕ（Gnu is Not Unix（登録商標））のダイナミックリンカの場合では、当該置き換え作業は、環境変数を用いて被制御プロセスのみに置き換えを適用することが可能である。

さらに、ダイナミックリンカの設定ファイルを変更することで、ダイナミックリンクされている全プロセスに対して置き換えをすることも可能である。

なお、前記子プロセス生成や被制御プロセスの消滅の検出を行った際の、カスタムライブラリ４３０中の関数から制御プロセス１１０への通知には、ＯＳが提供するプロセス間通信機能が利用できる。

次に、図７を用いて被制御プロセス１２０が子プロセスを生成する場合の動作について説明する。まず、被制御プロセス１２０が子プロセス生成関数ｆｏｒｋを呼び出す(Ｓ４０)。次に、ダイナミックリンカ４１０がカスタムライブラリ４３０中のｆｏｒｋ関数を呼び出す(Ｓ４１)。

カスタムライブラリ４３０中のｆｏｒｋ関数は、システムライブラリ４２０中のｆｏｒｋ関数を呼び出す(Ｓ４２)。

システムライブラリ４２０中のｆｏｒｋ関数がシステムコールを発行することで、ＯＳ１３０が子プロセスの生成を行う(Ｓ４３)
カスタムライブラリ４３０中のｆｏｒｋ関数は、生成された子プロセスのプロセスＩＤを取得し、プロセス間通信を用いて制御プロセス１１０のプロセス管理機能部１１１に通知する(Ｓ４４)。そして、制御プロセス１１０は、子プロセスを被制御プロセス表１１３に追加する(Ｓ４５)。

上記（Ｓ４０）〜（Ｓ４５）の手順により制御プロセス１１０は、新たにプロセスの生成があったことを把握することができ、以後は当該新たに生成されたプロセスを制御の対象として被制御プロセス表に追加することが可能となる。

次に、被制御プロセス１２０が消滅する場合の動作を説明する。
まず、被制御プロセスがプロセス終了関数ｅｘｉｔを呼び出す(Ｓ４０)。

次に、ダイナミックリンカ４１がカスタムライブラリ４３０中のｅｘｉｔ関数を呼び出す(Ｓ４１)。続いて、カスタムライブラリ４３０中のｅｘｉｔ関数は、システムライブラリ４２０中のｅｘｉｔ関数を呼び出す(Ｓ４２)。

システムライブラリ４２０中のｅｘｉｔ関数がシステムコールを発行することで、ＯＳ１３０が被制御プロセスの消滅処理を行うことにより当該被制御プロセスが消滅する(Ｓ４３)。

カスタムライブラリ４３０中のｅｘｉｔ関数は、プロセス間通信を用いて制御プロセス１１０のプロセス管理機能部１１１に、前記被制御プロセスの消滅があったことを通知する(Ｓ４４)。

制御プロセス１１０は、通知された前記消滅したプロセスを被制御プロセス表１１３から削除する(Ｓ４５)。

以上の手順により制御プロセス１１０は、新たにプロセスの消滅があったことを把握することができる。

なお、実施形態１の別形態として、カスタムライブラリが直接システムコールを行うことによりＯＳ１３０を呼び出して、プロセスの生成や、プロセスの消滅をＯＳに実行させる構成をとるのも良い。また、実施形態１のさらなる別形態として、カスタムライブラリ４３０を使わず、システムライブラリ４２０中の関数に制御プロセスへの通知機能を持たせても良い。

上記第１の実施形態は、カスタムライブラリ４３０の作成を行うことと、環境変数の設定やダイナミックリンカの設定ファイルの変更を行うのみで実現できるため、被制御プロセスの自体の修正やＯＳに特別な機能の追加をするなどといった作業が不要であるという効果がある。

また、ダイナミックリンクされている如何なる関数にも適用できるため、ｆｏｒｋやｅｘｉｔ以外の関数や呼び出しであっても検出をして、制御プロセスに通知を行うことができるという効果もある。

次に、本発明の実施形態の変形例に付いて図８を参照して説明する。本実施の形態は、ＯＳ１３０がプロセス生成検出部３１０とプロセス消滅検出部３２０を有し、制御プロセス１１０がそれらを利用することを特徴とする。なお、本実施の形態の動作は、上記に示した実施の形態と同様である。

次に、本発明のさらなる変形例を実施するための形態に付いて図９を参照して説明する。図９に示す実施の形態では、制御プロセス１１０自身がプロセス生成検出部３１０とプロセス消滅検出部３２０を有することを特徴とする。本実施の形態の動作も、上記に示した実施の形態と同様である。

なお、図２、図８及び図９に示す実施の形態は、それぞれユーザレベル、ＯＳ内、制御プロセス内の何れかの部分の、同じ部分にプロセス生成検出部３１０とプロセス消滅検出部３２０が存在している。

この点、本発明の更に異なる実施の形態として、プロセス生成検出部３１０とプロセス消滅検出部３２０のそれぞれが異なる場所に存在しても良い。

以上に加え、本発明の異なる実施の形態として、被制御プロセス１１０のプロセス管理機能部１１１が、プロセス生成通知またはプロセス消滅通知のいずれかのみを利用する構成をとっても良い。

また、本発明の他の実施の形態として、制御プロセス１１０のプロセス管理機能部１１１が、複数のプロセス生成検出部３１０を利用する構成をとっても良い。さらに、本発明の異なる実施の形態として、制御プロセス１１０のプロセス管理機能部１１１が、複数のプロセス消滅検出部３２０を利用する構成をとっても良い。

加えて、本発明の異なる実施の形態として、複数の制御プロセス１１０が存在する構成をとっても良い。また、本発明の実施の形態として、制御プロセスのプロセス管理機能が、プロセスの生成と消滅以外のプロセスの状態変化（例えばスリープ）を検出し、ユーザレベルプロセス制御に利用する構成をとっても良い。

次に、本発明の第２の実施形態を図１０を用いて示す。第２の実施形態は、上述した本発明の第１の実施の形態に対応するものである。

本実施形態は、ユーザレベルのプロセス生成検出部及び消滅検出部として、スタティックリンクライブラリを用いることを特徴とする。基本構成として、第１の実施形態と同様に、システムライブラリ４２０中のプロセス生成や消滅の関数と同名の関数を持つカスタムライブラリ４３０を用いる点は同様である。

第１の実施形態との相違点は、被制御プロセスが子プロセスを生成する際や被制御プロセスが消滅する際に、システムライブラリ４２０の関数ではなく、カスタムライブラリ４３０中の関数を呼び出すことを、カスタムライブラリ４３０を被制御プロセス１２０にスタティックリンクすることによって実現している点である。

なお、図１０では、カスタムライブラリ４３０、システムライブラリ４２０の両方がスタティックリンクされる構成が図示されているが、本実施形態の別形態としてカスタムライブラリ４３０のみをスタティックリンクする構成をとっても良い。本実施形態の動作も実施形態１の動作と同様である。当該第２の実施形態の利点は、被制御プロセスがスタティックリンクを用いている構成の場合にも本発明を利用できるという点である。

次に、本発明の第３の実施形態の構成を図１１に示す。第３の実施形態も、本発明の第１の実施の形態に対応するものである。本実施形態は、プロセス生成の検出または、プロセス消滅の検出を行うにあたって、ＯＳ１３０のプロセストレース機能１３４を用いることを特徴とする。

ここで、ＯＳ１３０のプロセストレース機能１３４は、トレース対象のプロセスがシステムコールを行った際に、トレース対象プロセスをいったん停止させ、監視しているプロセスに通知を行う機能を提供する。例えば、Ｌｉｎｕｘ（登録商標）はこのようなプロセストレース機能を備えている。

本実施形態では、まず制御プロセス１１０のプロセス管理機能部１１１が、プロセスのトレースを行うことを指示するシステムコール（例えばＬｉｎｕｘ（登録商標）のｐｔｒＡＣeシステムコール）を呼び出して、制御プロセス１１０が被制御プロセス１２０をトレースすることができるように、ＯＳ１３０に指示を出す

このときに、プロセス生成に関わるシステムコール（例えばｆｏｒｋやＣｌｏｎｅ）や消滅に関わるシステムコール（例えばｅｘｉｔ）をトレースするように設定する。

その後、制御プロセス１１０はｗａｉｔシステムコールを実行して、ＯＳ１３０のプロセストレース機能１３４から通知がくるのを待つ。

続いて、図１２を用いて被制御プロセスが子プロセスを作成する場合の動作手順を示す。手順としては、以下の手順となる。被制御プロセス１２０が子プロセスの生成のためのシステムコールを発行する（Ｓ５０）。

予めなされていた設定にしたがって、ＯＳ１３０のプロセストレース機能が呼ばれる（Ｓ５１）。

次にＯＳ１３０のプロセストレース機能１３４は、被制御プロセス１２０を停止する（Ｓ５２）。さらに、ＯＳ１３０のプロセストレース機能１３４は、制御プロセス１１０に被制御プロセス１２０から前記子プロセスの生成のためのシステムコールの発行があった旨の通知を行う（Ｓ５３）。制御プロセス１１０は、前記通知を受け取るとｗａｉｔシステムコールから復帰し、被制御プロセス表１１３に当該新たに生成された子プロセスを追加する（Ｓ５４）。

制御プロセス１１０は、被制御プロセス１２０の再開ためのシステムコールを実行する（Ｓ５５）。

その後、ＯＳ１３０が被制御プロセス１２０を再開させる（Ｓ５６）。

また、上記構成のもとで被制御プロセス１２０が消滅する場合の動作は、以下の手順となる。

被制御プロセス１２０が子プロセスの消滅のためのシステムコールを発行する（Ｓ５０）。予めなされていた設定にしたがって、ＯＳ１３０のプロセストレース機能が呼ばれる（Ｓ５１）。

ＯＳ１３０のプロセストレース機能１３４は、被制御プロセス１２０を停止する（Ｓ５２）。ＯＳ１３０のプロセストレース機能１３４は、制御プロセス１１０に被制御プロセス１２０が前記子プロセスの消滅のためのシステムコールの発行があった旨の通知を行う（Ｓ５３）。制御プロセス１１０は、前記通知を受け取るとｗａｉｔシステムコールから復帰し、被制御プロセス表１１３より、当該消滅される子プロセスを削除する（Ｓ５４）。

その後、ＯＳ１３０が被制御プロセス１２０を再開させる（Ｓ５６）、との手順となる。

第３の実施形態は、前記した実施形態１または２と異なり、被制御プロセスのリンクの方式によらずに用いることができるという効果がある。更に、通知のためのカスタムライブラリを作成する必要がないという効果もある。また、ＯＳのトレース機能は、被制御プロセスを一度停止してから制御プロセスに通知を行うため、制御プロセスへの通知が行われる前に被制御プロセスが動作を開始してしまうということがないという効果もある。

次に、本発明の第４の実施形態の構成を図１３に示す。第４の実施形態は、本発明の第３の実施の形態に対応するものである。本実施形態では、制御プロセスが、ＯＳ１３０のプロセステーブルを検索するプロセステーブル検索機能１１４を持つことで、制御プロセス１１０自身が、プロセス生成検出機能及びプロセス消滅検出機能を備えていることを特徴とする。

プロセステーブル検索機能１１４は、ＯＳ１３０の提供するＡＰＩを用いて、ＯＳ１３０のプロセステーブル１３１にアクセスして、存在するプロセスに関する情報を調べる機能を持つ。プロセステーブル１３１にアクセスするためのＡＰＩとしては、例としてＬｉｎｕｘ（登録商標）の持つｐｒｏＣファイルシステムが挙げられる。

次に、図１４を用いて、被制御プロセスが子プロセスの生成を行った際の、第４の実施形態の動作について説明する。

まず、被制御プロセス１２０が子プロセス生成のためのシステムコールをＯＳ１３０に対して実行する（Ｓ６０）。ＯＳ１３０は当該システムコールを受けて、子プロセスを生成し、プロセステーブル１３１に、新しいプロセスのＩＤ及びそのプロセスの親プロセスのＩＤを追加する（Ｓ６１）。

制御プロセス１１０のプロセス管理機能部１１１が、プロセステーブル検索機能１１４を呼び出し、現在の被制御プロセス１２０を親プロセスとする新しいプロセスが存在するかを検索する（Ｓ６２）。

次に、制御プロセス１１０のプロセステーブル検索機能１１４は、プロセステーブル１３１にアクセスして、現在の被制御プロセス１２０を親プロセスとする前記新しい子プロセスを検索して発見する（Ｓ６３）。

その後、制御プロセス１１０のプロセス管理機能部１１１は、プロセステーブル検索機能１１４の検索結果を受け取り、子プロセスが生成されたことを検出する（Ｓ６４）。

そして、プロセス管理機能部１１１は、前記新しい子プロセスを新たな制御対象として、被制御プロセス表１１３に登録する（Ｓ６５）。

上記の手順に従うことにより、被制御プロセスが子プロセスの生成を行ったことを制御プロセス１１０は、把握できる。

また、同様の手順をとることにより子プロセスの生成があった場合のみならず、プロセスの消滅があった場合も、被制御プロセスが当該プロセス消滅の事実を把握できる。

以上説明した、当該第４の実施形態は、上記のようにプロセステーブルを利用することにより、ダイナミックリンカに通知機能を付加することが困難な場合や、プログラムのスタティックリンク時にカスタムライブラリをリンクすることが不可能な場合、ＯＳがプロセストレース機能を備えていない場合といった、実施形態１乃至３のいずれも実施できない場合であっても本発明を利用できるという効果がある。

次に、本発明を実行した場合の実行結果の具体例ついて図１５を用いて説明する。なお、本発明は、制御プロセスが、被制御プロセスを親プロセスとする子プロセスの管理機能を持つことを特徴とし、制御プロセスが行うプロセス制御の具体的な内容には無関係であるが、本発明の効果をわかり易く示すために、本実施形態ではプロセスのＣＰＵへ割り当て制御（ユーザレベルプロセススケジュリング）に用いて説明する。

本具体例では、ユーザレベルプロセススケジューリングのための属性変更手段として、シグナルによるプロセスの実行/停止状態属性の変更が利用される。本具体例では、被制御プロセスとして三つのプロセスがあるものとする。

プロセスＡ５１０は音楽再生を行うリアルタイム処理プロセスで、周期的な動作している。この周期動作が乱れると音飛びが発生しユーザに不快感を与えてしまう。つまり、リアルタイムに処理することが要求されるプロセスである。

次に、プロセスＢ５２０は電子メール表示プロセスで、音楽再生中に電子メールを受信し電子メール表示プログラムを起動した場合を想定している。電子メール表示プロセスは多少動作が遅れてもユーザに影響を与えない非リアルタイム処理プロセスである。

一方、プロセスＣ５３０はプロセスＢ５２０が生成した子プロセスで、メールに添付された画像を表示するプロセスである。これも非リアルタイム処理プロセスである。

ここで、当該図１５は、図の凸部分がＣＰＵを利用していることを示しており、図の左から右に向かって時間が進むことを表している。なお、この図は、それぞれのプロセスが理想的な動作をした場合についての、それぞれのプロセスのＣＰＵ利用を示している。また、制御プロセスの実行時間は短いため図では省略している。

図１５（ａ)は個々のプロセスが単独で動いた場合のＣＰＵ利用を示している、また、図１５（ｂ）はユーザレベルプロセス制御を行わないで三つのプロセスを同時に動かした場合である。ＯＳのプロセススケジューラは、上記のようなプロセス毎の特徴を知らないため、必ずしも望ましいスケジューリングが行われるとは限らない。

この例ではＯＳのプロセススケジューリングによりプロセスＢ５２０、Ｃ５３０が優先してＣＰＵを利用している場合を示している。この場合、前記の様にリアルタイム処理プロセスであるか否かなどのプロセス毎の特徴は考慮されていないため、プロセスＡ５１の周期動作が乱れ、音飛びが発生している状態となる。

このような不適切な状態を避けるためには、各プロセスが適切にＣＰＵを利用するように制御する必要がある。

図１５（ｃ）はプロセス管理機能を持たないユーザレベルプロセス制御を用いた場合である。したがって、親プロセスであるプロセスＢのみに対してＣＰＵ利用時間制御が行われている。

本実施形態では、プロセスＡ５１０の実行タイミングに合わせて、制御プロセスからプロセスＢ５２０にシグナルを送り実行停止状態に変えることにより、プロセスＡ５１０の実行を妨げないように制御し、音飛びを防ぐことができる。しかし、子プロセスであるプロセスＣ５３０はユーザレベルプロセス制御機構の管理下にないため、プロセスＣ５３に対してはＣＰＵ利用時間制御が行われず、プロセスＡ５１０の動作を妨げることとなる。よって、完全にはプロセスＡ５１０の実行タイミングに合わせたプロセス制御を行うことはできないため、結果として完全に音飛びを防止することはできない。

さらに、図１５（ｄ）はプロセス管理機能をも備えたユーザレベルプロセス制御機構の場合のＣＰＵ利用を示している。（ｄ）ではプロセスＣ５３０もＣＰＵ利用時間を制御されている。このためリアルタイム処理プロセスであるプロセスＡ５１０は優先的にＣＰＵが割り当てられ、正常に周期動作している。これにより、上記の音飛びの問題は防止されている。

このように、プロセス管理機能を備えたユーザレベルプロセス制御を用いることによって、ＯＳや個々のプロセスを改造することなく、被制御プロセスが子プロセスを生成した場合も、リアルタイム性を維持するようにプロセス制御が行われることが可能となる。

なお、上記では、ユーザレベルプロセス制御の実現手段を属性及び属性変更として述べているが、これは、あくまでユーザレベルプロセス制御の実現手段の一例である。よって、当然のことながら前記実現手段にとらわれず、ＯＳがプロセス制御に利用し、ユーザレベルから変更可能な他の手段を用いても良い。よって上記で言う属性及び属性変更はその他のユーザレベルプロセス制御の実現手段をも総称しているものとする。

本発明は、複数のアプリケションプログラムがＯＳの管理下で動くコンピュータシステムで、各アプリケションプログラムを適切に動作させる用途に利用できる。

本発明の概要を説明するための図面である。本発明の第１の実施の形態の構成を説明するための図面である。本発明の第１の実施の形態におけるプロセス制御の動作を説明するための図面である。本発明の第１の実施の形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。本発明の第１の実施の形態における、被制御プロセスの消滅時の動作を説明するための図面である。本発明の第１の実施形態の構成を説明するための図面である。本発明の第１の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。本発明の第１の実施形態の変形例の構成を説明するための図面である。本発明の第１の実施形態の変形例の構成を説明するための図面である。本発明の第２の実施形態の構成を説明するための図面である。本発明の第３の実施形態の構成を説明するための図面である。本発明の第３の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。本発明の第４の実施形態の構成を説明するための図面である。本発明の第４の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。本発明を実行した場合の実行結果について、具体的な効果を説明するための図面である。

符号の説明

１１０制御プロセス
１１１プロセス管理機能部
１１２属性変更機能部
１１３被制御プロセス表
１１４プロセステーブル検索機能
１２０被制御プロセス
１２１被制御プロセスＡ
１２２被制御プロセスＢ
１３０オペレーティングシステム
１３１プロセステーブル
１３２プロセス制御機能
１３３プロセス生成/消滅機能
１３４プロセストレース機能
２１０プロセス生成通知
２２０プロセス消滅通知
３１０プロセス生成検出部
３２０プロセス終了検出部
４１０ダイナミックリンカ
４２０システムライブラリ
４３０カスタムライブラリ
５１０プロセスＡ
５２０プロセスＢ
５３０プロセスＣ

Claims

ユーザレベルの制御プロセスによりプロセス制御を行うユーザレベルプロセス制御装置が行うユーザレベルプロセス制御方法において、
前記ユーザレベルプロセス制御装置は、
第１のシステムコールに応じて子プロセスの生成を行う生成機能と、第２のシステムコールに応じて被制御プロセスを消滅させる消滅機能とを備えたＯＳと、
ダイナミックリンカと、
前記生成機能の実行を前記第１のシステムコールの発行により前記ＯＳに依頼するための第１の関数と、前記消滅機能の実行を前記第２のシステムコールの発行により前記ＯＳに依頼するための第２の関数とを有するシステムライブラリと、
前記第１の関数と同名の関数であって、且つ、前記生成機能の実行を前記第１の関数を呼び出すことによって依頼する機能及び前記生成を前記制御プロセスに通知する生成通知機能を備えた第３の関数と、前記第２の関数と同名の関数であって、且つ、前記消滅機能の実行を前記第２の関数を呼び出すことによって依頼する機能及び前記消滅を前記制御プロセスに通知する消滅通知機能を備えた第４の関数とを有するカスタムライブラリと、
を有し、
前記制御プロセスの実行時に、前記ダイナミックリンカにより、前記システムライブラリと前記カスタムライブラリとを前記被制御プロセスにリンクすると共に、関数を検索する順番の上位として前記カスタムライブラリを指定する、
ことを特徴とする、ユーザレベルプロセス制御方法。
ユーザレベルの制御プロセスによりプロセス制御を行うユーザレベルプロセス制御装置が行うユーザレベルプロセス制御方法において、
前記ユーザレベルプロセス制御装置は、
第１のシステムコールに応じて子プロセスの生成を行う生成機能と、第２のシステムコールに応じて被制御プロセスを消滅させる消滅機能とを備えたＯＳと、
ダイナミックリンカと、
前記生成機能の実行を前記第１のシステムコールの発行により前記ＯＳに依頼するための第１の関数と、前記消滅機能の実行を前記第２のシステムコールの発行により前記ＯＳに依頼するための第２の関数とを有するシステムライブラリと、
前記第１の関数と同名の関数であって、且つ、前記生成機能の実行を、前記第１のシステムコールを発行することによって直接前記ＯＳに依頼する機能及び前記生成を前記制御プロセスに通知する生成通知機能を備えた第３の関数と、前記第２の関数と同名の関数であって、且つ、前記消滅機能の実行を、前記第２のシステムコールを発行することによって直接前記ＯＳに依頼する機能及び前記消滅を前記制御プロセスに通知する消滅通知機能を備えた第４の関数とを有するカスタムライブラリと、
を有し、
前記制御プロセスの実行時に、前記ダイナミックリンカにより、前記システムライブラリと前記カスタムライブラリとを前記被制御プロセスにリンクすると共に、関数を検索する順番の上位として前記カスタムライブラリを指定する、
ことを特徴とする、ユーザレベルプロセス制御方法。
請求項１又は２に記載の前記ダイナミックリンカ、前記システムライブラリ及び前記カスタムライブラリを含むプログラム。