(57)【要約】【課題】オペレーティングシステムを修正することなく、ユーザレベルの制御プロセスが被制御プロセスの属性を変更することによってプロセス制御を行うユーザレベルプロセス制御において、被制御プロセスが生成や消滅する場合に、制御プロセスが被制御プロセス表を正しく保ちプロセス制御を行うこと。【解決手段】制御プロセス１１０がプロセス管理機能１１３を備える。被制御プロセス１２０が子プロセスを生成した時に、プロセス管理機能はプロセス生成通知２１０を受け取る。通知を受け取ったプロセス管理機構は被制御プロセス表１１２に追加する。また被制御プロセスが消滅する時は、プロセス管理機能はプロセス消滅通知２２０を受け取る。通知を受け取ったプロセス管理機能は被制御プロセス表から該当プロセスを削除する。【選択図】図１
2008186383.tif 000002
【特許請求の範囲】
【請求項１】
ユーザレベルの制御プロセスがプロセス制御を行うユーザレベルプロセス制御装置であって、
子プロセスの生成を行う手段と、
プロセス制御の対象である被制御プロセスを消滅させる手段と、
プロセスの状態変更を検出する手段と、
当該状態変更を把握するプロセス状態把握手段と、
を備えることを特徴とするユーザレベルプロセス制御装置。
【請求項２】
請求項１に記載のユーザレベルプロセス制御装置であって、
前記プロセス状態把握手段において検出する状態変更は、子プロセスの生成または前記プロセス制御の対象である被制御プロセスの消滅を指すことを特徴とするユーザレベルプロセス制御装置。
【請求項３】
請求項１又は２に記載のユーザレベルプロセス制御装置であって、
前記プロセスの状態変更を検出した場合は、当該変更のあったプロセスの属性を設定する手段を更に備えることを特徴とするユーザレベルプロセス制御装置。
【請求項４】
請求項１乃至３の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記生成を検出した子プロセスを新たに被制御プロセスとする手段を更に備えることを特徴とするユーザレベルプロセス制御装置。
【請求項５】
請求項１乃至４の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセスの状態変更を検出する手段は、ＯＳの備えるプロセストレース機能に基づいて行われることを特徴とするユーザレベルプロセス制御装置。
【請求項６】
請求項１乃至４の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセスの状態変更を検出する手段は、ＯＳの備えるプロセステーブルに保持されている情報に基づいて行われることを特徴とするユーザレベルプロセス制御装置。
【請求項７】
請求項１乃至４の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセスの状態変更を検出する手段は、リンカに基づいて行われることを特徴とするユーザレベルプロセス制御装置。
【請求項８】
請求項１乃至７の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記制御プロセスの検出した消滅した被制御プロセスは、以後のユーザレベルの制御プロセスによる制御対象から除外することを特徴とするユーザレベルプロセス制御装置。
【請求項９】
請求項１乃至８の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセス状態把握手段は、ユーザレベルのプロセス生成または消滅検出部が行うことを特徴とするユーザレベルプロセス制御装置。
【請求項１０】
請求項１乃至８の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセス状態把握手段は、ＯＳが備えるプロセス生成または消滅検出部が行うことを特徴とするユーザレベルプロセス制御装置。
【請求項１１】
請求項１乃至８の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセス状態把握手段は、制御プロセスのもつプロセス生成または消滅検出部プロセス生成検出部が行うことを特徴とするユーザレベルプロセス制御装置。
【請求項１２】
請求項１乃至１１の何れか１項に記載のユーザレベルプロセス制御装置であって、
前記プロセス状態把握手段により把握したプロセス情報及びプロセス状態に基づきプロセスの実行を管理する手段を更に備えたことを特徴とするユーザレベルプロセス制御装置。
【請求項１３】
ユーザレベルの制御プロセスがプロセス制御を行うユーザレベルプロセス制御方法であって、
子プロセスの生成を行うステップと、
前記プロセス制御の対象である被制御プロセスを消滅させるステップと、
プロセスの状態変更を検出するステップと、
当該状態変更を把握するプロセス状態把握ステップと、
を備えることを特徴とするユーザレベルプロセス制御方法。
【請求項１４】
請求項１３に記載のユーザレベルプロセス制御方法であって、
前記プロセス状態把握ステップにおいて検出する状態変更は、子プロセスの生成または前記プロセス制御の対象である被制御プロセスの消滅を指すことを特徴とするユーザレベルプロセス制御方法。
【請求項１５】
請求項１３又は１４に記載のユーザレベルプロセス制御方法であって、
前記プロセスの状態変更を検出した場合は、当該変更のあったプロセスの属性を設定するステップを更に備えることを特徴とするユーザレベルプロセス制御方法。
【請求項１６】
請求項１３乃至１５の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記生成を検出した子プロセスを新たに被制御プロセスとするステップを更に備えることを特徴とするユーザレベルプロセス制御方法。
【請求項１７】
請求項１３乃至１６の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセスの状態変更を検出する手段は、ＯＳの備えるプロセストレース機能に基づいて行われることを特徴とするユーザレベルプロセス制御方法。
【請求項１８】
請求項１３乃至１６の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセスの状態変更を検出する手段は、ＯＳの備えるプロセステーブルに保持されている情報に基づいて行われることを特徴とするユーザレベルプロセス制御方法。
【請求項１９】
請求項１３乃至１６の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセスの状態変更を検出する手段は、リンカに基づいて行われることを特徴とするユーザレベルプロセス制御方法。
【請求項２０】
請求項１３乃至１９の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記制御プロセスの検出した消滅被制御プロセスは、以後のユーザレベルの制御プロセスによる制御対象から除外することを特徴とするユーザレベルプロセス制御方法。
【請求項２１】
請求項１３乃至２０の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセス状態把握ステップは、ユーザレベルのプロセス生成または消滅検出部が行うことを特徴とするユーザレベルプロセス制御方法。
【請求項２２】
請求項１３乃至２０の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセス状態把握ステップは、ＯＳが備えるプロセス生成または消滅検出部が行うことを特徴とするユーザレベルプロセス制御方法。
【請求項２３】
請求項１３乃至２０の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセス状態把握ステップは、制御プロセスのもつプロセス生成または消滅検出部プロセス生成検出部が行うことを特徴とするユーザレベルプロセス制御方法。
【請求項２４】
請求項１３乃至２３の何れか１項に記載のユーザレベルプロセス制御方法であって、
前記プロセス状態把握ステップにより把握したプロセス情報及びプロセス状態に基づきプロセスの実行を管理するステップを更に備えたことを特徴とするユーザレベルプロセス制御方法。
【請求項２５】
コンピュータに、請求項１３乃至２４の何れか１項に記載のプロセス制御方法を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳ（オペレーティングシステム）がプロセスを管理する計算機における、プロセス管理機能をもつユーザレベルプロセス制御装置、方法及びそのプログラムに関し、特にオペレーティングシステムを修正することなく、ユーザレベルの制御プロセスが、ユーザレベルの被制御プロセスを制御するユーザレベルのプロセス管理機能をもつユーザレベルプロセス制御装置、その方法及びそのプログラムに関する。
【背景技術】
【０００２】
従来、複数のプログラムが動作する計算システムでは、プログラムはプロセスまたはスレッド（以下、単プロセスと記載した場合は、プロセスまたはスレッドを指すものとする）と呼ばれる実行単位で表される。当該複数のプログラムが動作する計算システムでは、適切にプロセスの動作を制御することが求められている。
【０００３】
例えば、リアルタイム処理を行っているプロセスがある場合、当該プロセスが優先的にＣＰＵを利用するように制御することで、リアルタイムに処理を行うべきとの制約を満たすことができるようになる。また、他にもプロセス制御の方法としては各プロセスに対してのメモリ使用量の制御や利用可能なネットワーク帯域の制御などを行うことが挙げられる。
【０００４】
一般に、上記のような複数のプロセスが動く計算システムでは、ＯＳ（オペレーティングシステム）がプロセスを制御する。そのため、利用しているＯＳが持っているプロセス制御機能が、計算システム上で動作させるプロセス集合に対して必要なプロセス制御を行うことができない場合は充分に必要な性能を得ることができない。
【０００５】
例えば、ＯＳのプロセス制御機能のひとつである、プロセスのＣＰＵへの割り当てを決定するスケジューラが、特別なプロセス管理を行わず、全てのプロセスを均等にＣＰＵへ割り当てるという制御を行う場合は、リアルタイム処理を行っているプロセスに十分なＣＰＵ利用時間を与えることができないという問題が生じる。
【０００６】
そのような場合の解決手段として、まずＯＳそのものを変更する方法が考えられる。そして具体的には、（１）要求性能を満たすようなプロセス制御が可能な、別のＯＳを用いる方法と、（２）現在利用しているＯＳを修正して機能拡張する方法、が考えられる。
【０００７】
ここで、上記（１）の例の実現のためにはリアルタイム処理に適したリアルタイムＯＳを導入することが挙げられる。しかし、一般にＯＳが異なる場合は、プログラムの互換性はないため、ＯＳを変更して使用を継続するためにはプログラムを変更後のＯＳに対応できるように修正しなければならないという問題がある。
【０００８】
一方、（２）の方法については、ＯＳの修正には専用の知識が必要であるという問題がある。更にそれに加えて、商用ＯＳなどはソースコードの入手が不可能である場合が多い。
【０００９】
また、たとえソースコードの入手が可能であってもＯＳの修正を行った場合は、メーカサポートの対象外になるなどのサポート体制の問題などで、やはり変更を行うこと自体が困難である。
【００１０】
このようにＯＳの変更が困難な場合の解決手段として、ユーザレベルプロセス制御がある。ユーザレベルプロセス制御では、ＯＳ上で動作するユーザレベルのプロセスが制御プロセスとなり、その他のプロセスに対して制御を行う。この場合にはＯＳの変更は必要ない。
【００１１】
この場合、一般にＯＳはプロセス毎に属性を設定し、その属性に従ってプロセス制御を行う。また、ＯＳはプロセスの属性をユーザレベルから変更するためのＡＰＩを提供している。したがって、ユーザレベルの制御プロセスは、そのＡＰＩを用いて被制御プロセスの属性を変更することによって、プロセス制御を行う。
【００１２】
特許文献１では、上述のようなプロセスの属性情報を用いてプロセス制御を行う技術について開示されている。
【００１３】
一方、特許文献２では、ユーザレベルのプロセス制御に関する技術が開示されている。同文献では、なかでもユーザレベルの制御プロセスによって、被制御プロセスのＣＰＵへのスケジューリングを制御するユーザレベルプロセススケジューラについて述べられている。
【００１４】
特許文献２では、制御プロセスであるユーザレベルプロセススケジューラが、制御対象として登録されている複数の被制御プロセスに対して、そのプロセスの属性である優先度や実行可能／停止状態を変更する。ここで、例として当該ＯＳのプロセススケジューラが、ＣＰＵを最高優先度のプロセスに対し優先的に割り当てるという動作をする場合を考える。
【００１５】
このようなＣＰＵを特定の被制御プロセスに対し優先的に割り当てたいときは、そのプロセスの優先度を最高にし、それ以外の被制御プロセスの優先度を下げることによって、ＯＳのプロセススケジューラが、当該最高優先度のプロセスをＣＰＵに割り当てるように制御する。
【特許文献１】特開平１０−０２１０９９号公報
【特許文献２】特開平９−５４６９９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上記のような、従来のユーザレベルプロセス制御の第一の問題点は、被制御プロセスが新たに子プロセスを生成した場合に、制御プロセスが当該生成された子プロセスを制御できないことである。
【００１７】
その理由は、制御プロセスは被制御プロセスが子プロセスを生成したことを知る機能を有していないためである。すなわち、プロセスの生成はＯＳが行い、生成されたプロセスのＩＤは親プロセスに直接通知される。つまり、ＯＳや親プロセス以外のプロセスとは無関係に子プロセスの生成が行われる。
【００１８】
よって、制御プロセスは、被制御プロセスと親子関係がない以上、子プロセスが生成されたことを知る機能を持つような特別な場合をのぞき、子プロセスが生成されたことを知ることができない。そのため、制御プロセスは当該新たに生成された子プロセスに対してプロセス制御を行うための属性変更ができない。
【００１９】
そのため、プログラムが親プロセスとその子孫のプロセスからなる複数のプロセスから構成される場合であっても、制御プロセスは親プロセスしか制御できないことになる。したがって、制御プロセスは、プログラムの一部しか制御をすることができず、そのプログラムが全体として十分な性能で動くように制御できないという問題がある。
【００２０】
この点、特許文献２で述べられている上記問題点の従来の解決例では、生成された子プロセスを制御対象に加えるためには、子プロセス自身が制御プロセスに対し被制御プロセスとしての加入要求を行うという解決手段がとられている。よって、当該方式を採用するためには、子プロセスとなるプログラムが制御プロセスに対し被制御プロセスとしての加入要求を行うように、予めプログラムを変更する必要がある。
【００２１】
もっとも、当該プログラム変更に際しては、制御プロセスのソースコードが必ずしも入手可能でないことや、たとえ、ソースコードが入手できたとしても、変更には相応のコストを要する。よって、当該従来例のように被制御プロセスを変更することなく、子プロセスの生成を知ることが課題であるといえる。
【００２２】
次に、第二の問題点は制御プロセスが、被制御プロセスの消滅を知ることができないために、制御対象から当該消滅した被制御プロセスを除外できないことである。その理由は上記のように、制御プロセスが、被制御プロセスの消滅を知る機能を持たないためである。
【００２３】
このため、被制御プロセスがすでに消滅した場合であっても、制御プロセスは存在しない被制御プロセスに対しても制御を行い続けることとなり、システム全体の性能が劣化するという問題がある。
【００２４】
以上より、本発明は、被制御プロセスによる子プロセスの生成及び被制御プロセスの消滅を、制御プロセスが知ることを第一の目的とする。更に、プロセス制御の対象とする必要がある全てのプロセスに対して、制御プロセスが属性変更を行うことができるユーザレベルプロセス制御機構を提供することを第二の目的とする。
【課題を解決するための手段】
【００２５】
本発明によれば、ユーザレベルの制御プロセスがプロセス制御を行うユーザレベルプロセス制御装置であって、子プロセスの生成を行う手段と、プロセス制御の対象である被制御プロセスを消滅させる手段と、プロセスの状態変更を検出する手段と、当該状態変更を把握するプロセス状態把握手段とを備えることを特徴とするユーザレベルプロセス制御装置、方法及びプログラムが提供される。
【００２６】
上記の場合において、前記プロセス状態把握手段により把握したプロセス情報及びプロセス状態に基づきプロセスの実行を管理する手段を更に備えることを特徴とするようにしてもよい。
【発明の効果】
【００２７】
本発明によれば、ユーザレベルプロセス制御システムにおいて、制御プロセスが制御対象とする必要のあるプロセスを正確に把握することにより、プロセスが子プロセスを生成したり、プロセスが消滅したりする場合にも、プロセスを適切に制御することが可能になる。
【発明を実施するための最良の形態】
【００２８】
発明を実施するための最良の形態について図面を参照して詳細に説明する。
まず、本発明の概略を、図１を用いて説明する。制御プロセス１１０はプロセス管理機能部１１１を備え、制御プロセスのプロセス管理機能は、被制御プロセス１２０による子プロセス生成時と被制御プロセスの消滅時に通知を受け取ることを特徴とする。
【００２９】
制御プロセスのプロセス管理機能部１１１は、子プロセス生成の通知２１０を受けると、子プロセスを被制御プロセス表１１２に追加し、被制御プロセス表を正確な状態に更新する。
【００３０】
また、プロセス管理機能部１１１は、被制御プロセスの消滅の通知２２０を受けると、被制御プロセス表１１２から当該プロセスを削除する。これにより不要なプロセスを被制御プロセス表から除外し、被制御プロセス表を正確な状態に更新する。
【００３１】
上記より、被制御プロセスが生成または消滅する場合も、被制御プロセス表が正確な状態に保たれているため、制御プロセスの属性変更機能１１２は、必要な全てのプロセスに対して、ＯＳ１３０のプロセステーブル１３１に記録されている属性を変更することができる。
【００３２】
ＯＳ１３０のプロセス制御機能部１３２は、プロセステーブル中の属性を参照してプロセス制御を行う。
【００３３】
図２は本発明の実施形態の基本的構成を示す図面である。当該実施の形態は、制御プロセス１１０、被制御プロセス１２０、ＯＳ１３０、プロセス生成検出部３１０、プロセス消滅検出部３２０を備える。制御プロセス１１０は、プロセスの属性変更機能部１１２と被制御プロセス表１１３及びプロセス管理機能部１１１を備える。
【００３４】
本実施の形態は、制御プロセス１１０のプロセス管理機能部１１１が、ユーザレベルのプロセス生成検出部３１０とプロセス消滅検出部３２０を利用することを特徴とする。
【００３５】
まず、ＯＳ１３０は、プロセスの情報を保持するプロセステーブル１３１と、プロセス制御機能部１３２を有する。ＯＳ１３０のプロセス制御機能部１３２はプロセステーブル１３１に記録されているプロセスの属性にしたがって、プロセス制御を行う。
【００３６】
次に、制御プロセス１１０の属性変更機能部１１２は、ＯＳ１３０の提供するＡＰＩを用いてプロセステーブル１３１に記録されている被制御プロセス１２０の属性を変更する。制御プロセス１１０の被制御プロセス表１１３は、制御プロセスが制御対象としているプロセスを記録する。
【００３７】
また、新たに子プロセス生成があった場合には、検出制御プロセス１１０のプロセス管理機能部１１１は、プロセス生成検出部３１０を利用して、被制御プロセス１２０の子プロセス生成を検出し、検出された子プロセスを被制御プロセス表１１３に追加する。更に、被制御プロセスの消滅があった場合には、制御プロセス１１０のプロセス管理機能部１１１は、プロセス消滅検出部３２０を利用し、被制御プロセス１２０の消滅を検出し、被制御プロセス表１１３から削除する。
【００３８】
プロセス生成検出部３１０は、ユーザレベルにあり、プロセスの子プロセス生成を検出し、生成を監視している制御プロセス１１０に通知する機能を有する。プロセス消滅検出部３２０はユーザレベルにあり、上記生成の場合と同様に、プロセスの消滅を検出し、消滅を監視している制御プロセス１１０に通知する機能を有する。
【００３９】
次に、本実施の形態の動作に付いて図３乃至図５を用いて詳細に説明する。なお、説明では便宜のために簡略化し、被制御プロセスとしてひとつのプロセスのみを表示している。
【００４０】
図３は、制御プロセス１１０が被制御プロセスＡ１２０に対して制御を行う動作を示している。
【００４１】
ここで、動作としては以下の通りである。まず、制御プロセスが、プロセスＡ１２０に対して制御を行うためにプロセステーブル１３１中のプロセスＡ１２０の属性の変更を示している（Ｓ１０）。次にＯＳ１３０のプロセス制御機能部１３２がプロセステーブル１３１に記録されているプロセスＡ１２０の属性を読み出すことを表している（Ｓ１１）。更に、ＯＳ１３０のプロセス制御機能部１３２が、属性にしたがって、プロセスＡ１２０を制御することを表している（Ｓ１２）。
【００４２】
図４は、制御プロセスがユーザレベルのプロセス生成検出部３１０を利用して、被制御プロセスＡ１２０による子プロセスＢ１２２の生成を検出する場合の動作を示している。まず、プロセスＡ１２０が子プロセスＢ１２２を作成する（Ｓ２０）。それにつきプロセス生成検出部３１０がプロセスＢ１２２の生成の検出する（Ｓ２１）。
【００４３】
そして、プロセス生成検出部３１０は制御プロセス１１０へ子プロセスの生成を通知する（Ｓ２２）。次に、通知を受けた制御プロセス１１０のプロセス管理機能部１１１は、今回新たに生成されたプロセスＢ１２２を被制御プロセス表１１３に登録する（Ｓ２３）。
【００４４】
この際、制御プロセス１１０の属性変更機能部１１２は、プロセスＢ１２２が制御対象であることを把握し、ＯＳ１３０のプロセステーブル１３１の属性を変更する（Ｓ２４）。
【００４５】
図５は、制御プロセス１１０がユーザレベルのプロセス消滅検出部３２０を利用して、被制御プロセスＢ１２２の消滅を検出する動作を示している。まず、プロセス消滅検出部３２０がプロセスＢ１２２の消滅を検出する（Ｓ３０）。次に、プロセス消滅検出部３２０が制御プロセス１１０にプロセスＢ１２２の消滅を通知する（Ｓ３１）。制御プロセス１１０のプロセス管理機能部１１１は、被制御プロセス表１１３からプロセスＢ１２２を削除する（Ｓ３２）。
［実施形態］
次に、具体的な実施形態を用いて、本発明を実施するための最良の形態の動作について説明する。本発明の第１の実施形態の構成を図６に示す。なお、ここで以下に述べる実施形態は、本発明の第１の実施形態に対応するものであるが、図６では制御プロセスの属性変更機能は省略してある。
【００４６】
本実施形態は、被制御プロセス１２０による子プロセスの生成の際や被制御プロセスの終了の際に呼び出されるライブラリ関数がダイナミックリンクされている場合に用いられるものである。
【００４７】
また、本実施形態は、ユーザレベルのプロセス生成検出部及びプロセス消滅検出部として、ダイナミックリンカ及び当該ダイナミックリンカに備えられるダイナミックリンクライブラリを利用することを特徴とするものである。
【００４８】
プロセスが子プロセスを生成する場合やプロセスの終了を行う場合は、ＯＳにそれらの処理を依頼するためのシステムコールを行う。この点、一般的にはプロセスが直接システムコールを行うのではなく、システムライブラリ中の専用の関数を呼び出して、当該ライブラリ関数内でシステムコールが実行される。
【００４９】
したがって、子プロセス生成やプロセス終了時に呼び出されるライブラリ関数が、制御プロセスへの通知機能を持つ場合であれば、子プロセスの生成やプロセスの終了を検出して、更にそれを制御プロセスへ通知をするということまでもが可能となる。
【００５０】
ライブラリ関数がダイナミックリンクされている場合は、ダイナミックリンカがプロセスの実行時にリンクを解決する。図６のシステムライブラリ４２０は、システムにもともと備わっているライブラリを示している。ここで、当該システムライブラリ４２０中の関数は、制御プロセスへの通知機能を持っていない。
【００５１】
一方、図６のカスタムライブラリ４３０は、システムライブラリ４２０の関数と同じ関数名ではあるが、プロセス生成や消滅といった本来の機能に加えて、制御プロセスへの通知機能を持つ関数をも含むライブラリである。
【００５２】
ダイナミックリンカ４１０によって、被制御プロセス１２０から呼び出されるライブラリ関数として、システムライブラリ４２０中の関数ではなく、カスタムライブラリ４３０中の関数がリンクされる。つまり、システムライブラリ４２０中の関数ではなく、カスタムライブラリ４３０中の関数が呼ばれることとなる。
【００５３】
これにより、カスタムライブラリ４３０中の関数が子プロセス生成や被制御プロセスの消滅の検出を行い、さらに、当該生成や消滅の事実を、制御プロセス１１０へ通知することとなる。
【００５４】
ここで、ダイナミックリンカ４１０によってリンクされる関数を、システムライブラリ４２０中の関数でなく、カスタムライブラリ４３０中の関数とする当該置き換え作業は、ダイナミックリンカ４１０が、ライブラリ関数を検索する順番の上位として、カスタムライブラリ４３０を指定することによって行うことができる。
【００５５】
また、Ｌｉｎｕｘで広く利用されているＧｎｕ（Gnu is Not Unix（登録商標））のダイナミックリンカの場合では、当該置き換え作業は、環境変数を用いて被制御プロセスのみに置き換えを適用することが可能である。
【００５６】
さらに、ダイナミックリンカの設定ファイルを変更することで、ダイナミックリンクされている全プロセスに対して置き換えをすることも可能である。
【００５７】
なお、前記子プロセス生成や被制御プロセスの消滅の検出を行った際の、カスタムライブラリ４３０中の関数から制御プロセス１１０への通知には、ＯＳが提供するプロセス間通信機能が利用できる。
【００５８】
次に、図７を用いて被制御プロセス１２０が子プロセスを生成する場合の動作について説明する。まず、被制御プロセス１２０が子プロセス生成関数ｆｏｒｋを呼び出す(Ｓ４０)。次に、ダイナミックリンカ４１０がカスタムライブラリ４３０中のｆｏｒｋ関数を呼び出す(Ｓ４１)。
【００５９】
カスタムライブラリ４３０中のｆｏｒｋ関数は、システムライブラリ４２０中のｆｏｒｋ関数を呼び出す(Ｓ４２)。
【００６０】
システムライブラリ４２０中のｆｏｒｋ関数がシステムコールを発行することで、ＯＳ１３０が子プロセスの生成を行う(Ｓ４３)
カスタムライブラリ４３０中のｆｏｒｋ関数は、生成された子プロセスのプロセスＩＤを取得し、プロセス間通信を用いて制御プロセス１１０のプロセス管理機能部１１１に通知する(Ｓ４４)。そして、制御プロセス１１０は、子プロセスを被制御プロセス表１１３に追加する(Ｓ４５)。
【００６１】
上記（Ｓ４０）〜（Ｓ４５）の手順により制御プロセス１１０は、新たにプロセスの生成があったことを把握することができ、以後は当該新たに生成されたプロセスを制御の対象として被制御プロセス表に追加することが可能となる。
【００６２】
次に、被制御プロセス１２０が消滅する場合の動作を説明する。
まず、被制御プロセスがプロセス終了関数ｅｘｉｔを呼び出す(Ｓ４０)。
【００６３】
次に、ダイナミックリンカ４１がカスタムライブラリ４３０中のｅｘｉｔ関数を呼び出す(Ｓ４１)。続いて、カスタムライブラリ４３０中のｅｘｉｔ関数は、システムライブラリ４２０中のｅｘｉｔ関数を呼び出す(Ｓ４２)。
【００６４】
システムライブラリ４２０中のｅｘｉｔ関数がシステムコールを発行することで、ＯＳ１３０が被制御プロセスの消滅処理を行うことにより当該被制御プロセスが消滅する(Ｓ４３)。
【００６５】
カスタムライブラリ４３０中のｅｘｉｔ関数は、プロセス間通信を用いて制御プロセス１１０のプロセス管理機能部１１１に、前記被制御プロセスの消滅があったことを通知する(Ｓ４４)。
【００６６】
制御プロセス１１０は、通知された前記消滅したプロセスを被制御プロセス表１１３から削除する(Ｓ４５)。
【００６７】
以上の手順により制御プロセス１１０は、新たにプロセスの消滅があったことを把握することができる。
【００６８】
なお、実施形態１の別形態として、カスタムライブラリが直接システムコールを行うことによりＯＳ１３０を呼び出して、プロセスの生成や、プロセスの消滅をＯＳに実行させる構成をとるのも良い。また、実施形態１のさらなる別形態として、カスタムライブラリ４３０を使わず、システムライブラリ４２０中の関数に制御プロセスへの通知機能を持たせても良い。
【００６９】
上記第１の実施形態は、カスタムライブラリ４３０の作成を行うことと、環境変数の設定やダイナミックリンカの設定ファイルの変更を行うのみで実現できるため、被制御プロセスの自体の修正やＯＳに特別な機能の追加をするなどといった作業が不要であるという効果がある。
【００７０】
また、ダイナミックリンクされている如何なる関数にも適用できるため、ｆｏｒｋやｅｘｉｔ以外の関数や呼び出しであっても検出をして、制御プロセスに通知を行うことができるという効果もある。
【００７１】
次に、本発明の実施形態の変形例に付いて図８を参照して説明する。本実施の形態は、ＯＳ１３０がプロセス生成検出部３１０とプロセス消滅検出部３２０を有し、制御プロセス１１０がそれらを利用することを特徴とする。なお、本実施の形態の動作は、上記に示した実施の形態と同様である。
【００７２】
次に、本発明のさらなる変形例を実施するための形態に付いて図９を参照して説明する。図９に示す実施の形態では、制御プロセス１１０自身がプロセス生成検出部３１０とプロセス消滅検出部３２０を有することを特徴とする。本実施の形態の動作も、上記に示した実施の形態と同様である。
【００７３】
なお、図２、図８及び図９に示す実施の形態は、それぞれユーザレベル、ＯＳ内、制御プロセス内の何れかの部分の、同じ部分にプロセス生成検出部３１０とプロセス消滅検出部３２０が存在している。
【００７４】
この点、本発明の更に異なる実施の形態として、プロセス生成検出部３１０とプロセス消滅検出部３２０のそれぞれが異なる場所に存在しても良い。
【００７５】
以上に加え、本発明の異なる実施の形態として、被制御プロセス１１０のプロセス管理機能部１１１が、プロセス生成通知またはプロセス消滅通知のいずれかのみを利用する構成をとっても良い。
【００７６】
また、本発明の他の実施の形態として、制御プロセス１１０のプロセス管理機能部１１１が、複数のプロセス生成検出部３１０を利用する構成をとっても良い。さらに、本発明の異なる実施の形態として、制御プロセス１１０のプロセス管理機能部１１１が、複数のプロセス消滅検出部３２０を利用する構成をとっても良い。
【００７７】
加えて、本発明の異なる実施の形態として、複数の制御プロセス１１０が存在する構成をとっても良い。また、本発明の実施の形態として、制御プロセスのプロセス管理機能が、プロセスの生成と消滅以外のプロセスの状態変化（例えばスリープ）を検出し、ユーザレベルプロセス制御に利用する構成をとっても良い。
【００７８】
次に、本発明の第２の実施形態を図１０を用いて示す。第２の実施形態は、上述した本発明の第１の実施の形態に対応するものである。
【００７９】
本実施形態は、ユーザレベルのプロセス生成検出部及び消滅検出部として、スタティックリンクライブラリを用いることを特徴とする。基本構成として、第１の実施形態と同様に、システムライブラリ４２０中のプロセス生成や消滅の関数と同名の関数を持つカスタムライブラリ４３０を用いる点は同様である。
【００８０】
第１の実施形態との相違点は、被制御プロセスが子プロセスを生成する際や被制御プロセスが消滅する際に、システムライブラリ４２０の関数ではなく、カスタムライブラリ４３０中の関数を呼び出すことを、カスタムライブラリ４３０を被制御プロセス１２０にスタティックリンクすることによって実現している点である。
【００８１】
なお、図１０では、カスタムライブラリ４３０、システムライブラリ４２０の両方がスタティックリンクされる構成が図示されているが、本実施形態の別形態としてカスタムライブラリ４３０のみをスタティックリンクする構成をとっても良い。本実施形態の動作も実施形態１の動作と同様である。当該第２の実施形態の利点は、被制御プロセスがスタティックリンクを用いている構成の場合にも本発明を利用できるという点である。
【００８２】
次に、本発明の第３の実施形態の構成を図１１に示す。第３の実施形態も、本発明の第１の実施の形態に対応するものである。本実施形態は、プロセス生成の検出または、プロセス消滅の検出を行うにあたって、ＯＳ１３０のプロセストレース機能１３４を用いることを特徴とする。
【００８３】
ここで、ＯＳ１３０のプロセストレース機能１３４は、トレース対象のプロセスがシステムコールを行った際に、トレース対象プロセスをいったん停止させ、監視しているプロセスに通知を行う機能を提供する。例えば、Ｌｉｎｕｘはこのようなプロセストレース機能を備えている。
【００８４】
本実施形態では、まず制御プロセス１１０のプロセス管理機能部１１１が、プロセスのトレースを行うことを指示するシステムコール（例えばＬｉｎｕｘのｐｔｒＡＣeシステムコール）を呼び出して、制御プロセス１１０が被制御プロセス１２０をトレースすることができるように、ＯＳ１３０に指示を出す。
【００８５】
このときに、プロセス生成に関わるシステムコール（例えばｆｏｒｋやＣｌｏｎｅ）や消滅に関わるシステムコール（例えばｅｘｉｔ）をトレースするように設定する。
【００８６】
その後、制御プロセス１１０はｗａｉｔシステムコールを実行して、ＯＳ１３０のプロセストレース機能１３４から通知がくるのを待つ。
【００８７】
続いて、図１２を用いて被制御プロセスが子プロセスを作成する場合の動作手順を示す。手順としては、以下の手順となる。被制御プロセス１２０が子プロセスの生成のためのシステムコールを発行する（Ｓ５０）。
【００８８】
予めなされていた設定にしたがって、ＯＳ１３０のプロセストレース機能が呼ばれる（Ｓ５１）。
【００８９】
次にＯＳ１３０のプロセストレース機能１３４は、被制御プロセス１２０を停止する（Ｓ５２）。さらに、ＯＳ１３０のプロセストレース機能１３４は、制御プロセス１１０に被制御プロセス１２０から前記子プロセスの生成のためのシステムコールの発行があった旨の通知を行う（Ｓ５３）。制御プロセス１１０は、前記通知を受け取るとｗａｉｔシステムコールから復帰し、被制御プロセス表１１３に当該新たに生成された子プロセスを追加する（Ｓ５４）。
【００９０】
制御プロセス１１０は、被制御プロセス１２０の再開ためのシステムコールを実行する（Ｓ５５）。
【００９１】
その後、ＯＳ１３０が被制御プロセス１２０を再開させる（Ｓ５６）。
【００９２】
また、上記構成のもとで被制御プロセス１２０が消滅する場合の動作は、以下の手順となる。
【００９３】
被制御プロセス１２０が子プロセスの消滅のためのシステムコールを発行する（Ｓ５０）。予めなされていた設定にしたがって、ＯＳ１３０のプロセストレース機能が呼ばれる（Ｓ５１）。
【００９４】
ＯＳ１３０のプロセストレース機能１３４は、被制御プロセス１２０を停止する（Ｓ５２）。ＯＳ１３０のプロセストレース機能１３４は、制御プロセス１１０に被制御プロセス１２０が前記子プロセスの消滅のためのシステムコールの発行があった旨の通知を行う（Ｓ５３）。制御プロセス１１０は、前記通知を受け取るとｗａｉｔシステムコールから復帰し、被制御プロセス表１１３より、当該消滅される子プロセスを削除する（Ｓ５４）。
【００９５】
制御プロセス１１０は、被制御プロセス１２０の再開ためのシステムコールを実行する（Ｓ５５）。
【００９６】
その後、ＯＳ１３０が被制御プロセス１２０を再開させる（Ｓ５６）、との手順となる。
【００９７】
第３の実施形態は、前記した実施形態１または２と異なり、被制御プロセスのリンクの方式によらずに用いることができるという効果がある。更に、通知のためのカスタムライブラリを作成する必要がないという効果もある。また、ＯＳのトレース機能は、被制御プロセスを一度停止してから制御プロセスに通知を行うため、制御プロセスへの通知が行われる前に被制御プロセスが動作を開始してしまうということがないという効果もある。
【００９８】
次に、本発明の第４の実施形態の構成を図１３に示す。第４の実施形態は、本発明の第３の実施の形態に対応するものである。本実施形態では、制御プロセスが、ＯＳ１３０のプロセステーブルを検索するプロセステーブル検索機能１１４を持つことで、制御プロセス１１０自身が、プロセス生成検出機能及びプロセス消滅検出機能を備えていることを特徴とする。
【００９９】
プロセステーブル検索機能１１４は、ＯＳ１３０の提供するＡＰＩを用いて、ＯＳ１３０のプロセステーブル１３１にアクセスして、存在するプロセスに関する情報を調べる機能を持つ。プロセステーブル１３１にアクセスするためのＡＰＩとしては、例としてＬｉｎｕｘの持つｐｒｏＣファイルシステムが挙げられる。
【０１００】
次に、図１４を用いて、被制御プロセスが子プロセスの生成を行った際の、第４の実施形態の動作について説明する。
【０１０１】
まず、被制御プロセス１２０が子プロセス生成のためのシステムコールをＯＳ１３０に対して実行する（Ｓ６０）。ＯＳ１３０は当該システムコールを受けて、子プロセスを生成し、プロセステーブル１３１に、新しいプロセスのＩＤ及びそのプロセスの親プロセスのＩＤを追加する（Ｓ６１）。
【０１０２】
制御プロセス１１０のプロセス管理機能部１１１が、プロセステーブル検索機能１１４を呼び出し、現在の被制御プロセス１２０を親プロセスとする新しいプロセスが存在するかを検索する（Ｓ６２）。
【０１０３】
次に、制御プロセス１１０のプロセステーブル検索機能１１４は、プロセステーブル１３１にアクセスして、現在の被制御プロセス１２０を親プロセスとする前記新しい子プロセスを検索して発見する（Ｓ６３）。
【０１０４】
その後、制御プロセス１１０のプロセス管理機能部１１１は、プロセステーブル検索機能１１４の検索結果を受け取り、子プロセスが生成されたことを検出する（Ｓ６４）。
【０１０５】
そして、プロセス管理機能部１１１は、前記新しい子プロセスを新たな制御対象として、被制御プロセス表１１３に登録する（Ｓ６５）。
【０１０６】
上記の手順に従うことにより、被制御プロセスが子プロセスの生成を行ったことを制御プロセス１１０は、把握できる。
【０１０７】
また、同様の手順をとることにより子プロセスの生成があった場合のみならず、プロセスの消滅があった場合も、被制御プロセスが当該プロセス消滅の事実を把握できる。
【０１０８】
以上説明した、当該第４の実施形態は、上記のようにプロセステーブルを利用することにより、ダイナミックリンカに通知機能を付加することが困難な場合や、プログラムのスタティックリンク時にカスタムライブラリをリンクすることが不可能な場合、ＯＳがプロセストレース機能を備えていない場合といった、実施形態１乃至３のいずれも実施できない場合であっても本発明を利用できるという効果がある。
【０１０９】
次に、本発明を実行した場合の実行結果の具体例ついて図１５を用いて説明する。なお、本発明は、制御プロセスが、被制御プロセスを親プロセスとする子プロセスの管理機能を持つことを特徴とし、制御プロセスが行うプロセス制御の具体的な内容には無関係であるが、本発明の効果をわかり易く示すために、本実施形態ではプロセスのＣＰＵへ割り当て制御（ユーザレベルプロセススケジュリング）に用いて説明する。
【０１１０】
本具体例では、ユーザレベルプロセススケジューリングのための属性変更手段として、シグナルによるプロセスの実行/停止状態属性の変更が利用される。本具体例では、被制御プロセスとして三つのプロセスがあるものとする。
【０１１１】
プロセスＡ５１０は音楽再生を行うリアルタイム処理プロセスで、周期的な動作している。この周期動作が乱れると音飛びが発生しユーザに不快感を与えてしまう。つまり、リアルタイムに処理することが要求されるプロセスである。
【０１１２】
次に、プロセスＢ５２０は電子メール表示プロセスで、音楽再生中に電子メールを受信し電子メール表示プログラムを起動した場合を想定している。電子メール表示プロセスは多少動作が遅れてもユーザに影響を与えない非リアルタイム処理プロセスである。
【０１１３】
一方、プロセスＣ５３０はプロセスＢ５２０が生成した子プロセスで、メールに添付された画像を表示するプロセスである。これも非リアルタイム処理プロセスである。
【０１１４】
ここで、当該図１５は、図の凸部分がＣＰＵを利用していることを示しており、図の左から右に向かって時間が進むことを表している。なお、この図は、それぞれのプロセスが理想的な動作をした場合についての、それぞれのプロセスのＣＰＵ利用を示している。また、制御プロセスの実行時間は短いため図では省略している。
【０１１５】
図１５（ａ)は個々のプロセスが単独で動いた場合のＣＰＵ利用を示している、また、図１５（ｂ）はユーザレベルプロセス制御を行わないで三つのプロセスを同時に動かした場合である。ＯＳのプロセススケジューラは、上記のようなプロセス毎の特徴を知らないため、必ずしも望ましいスケジューリングが行われるとは限らない。
【０１１６】
この例ではＯＳのプロセススケジューリングによりプロセスＢ５２０、Ｃ５３０が優先してＣＰＵを利用している場合を示している。この場合、前記の様にリアルタイム処理プロセスであるか否かなどのプロセス毎の特徴は考慮されていないため、プロセスＡ５１の周期動作が乱れ、音飛びが発生している状態となる。
【０１１７】
このような不適切な状態を避けるためには、各プロセスが適切にＣＰＵを利用するように制御する必要がある。
【０１１８】
図１５（ｃ）はプロセス管理機能を持たないユーザレベルプロセス制御を用いた場合である。したがって、親プロセスであるプロセスＢのみに対してＣＰＵ利用時間制御が行われている。
【０１１９】
本実施形態では、プロセスＡ５１０の実行タイミングに合わせて、制御プロセスからプロセスＢ５２０にシグナルを送り実行停止状態に変えることにより、プロセスＡ５１０の実行を妨げないように制御し、音飛びを防ぐことができる。しかし、子プロセスであるプロセスＣ５３０はユーザレベルプロセス制御機構の管理下にないため、プロセスＣ５３に対してはＣＰＵ利用時間制御が行われず、プロセスＡ５１０の動作を妨げることとなる。よって、完全にはプロセスＡ５１０の実行タイミングに合わせたプロセス制御を行うことはできないため、結果として完全に音飛びを防止することはできない。
【０１２０】
さらに、図１５（ｄ）はプロセス管理機能をも備えたユーザレベルプロセス制御機構の場合のＣＰＵ利用を示している。（ｄ）ではプロセスＣ５３０もＣＰＵ利用時間を制御されている。このためリアルタイム処理プロセスであるプロセスＡ５１０は優先的にＣＰＵが割り当てられ、正常に周期動作している。これにより、上記の音飛びの問題は防止されている。
【０１２１】
このように、プロセス管理機能を備えたユーザレベルプロセス制御を用いることによって、ＯＳや個々のプロセスを改造することなく、被制御プロセスが子プロセスを生成した場合も、リアルタイム性を維持するようにプロセス制御が行われることが可能となる。
【０１２２】
なお、上記では、ユーザレベルプロセス制御の実現手段を属性及び属性変更として述べているが、これは、あくまでユーザレベルプロセス制御の実現手段の一例である。よって、当然のことながら前記実現手段にとらわれず、ＯＳがプロセス制御に利用し、ユーザレベルから変更可能な他の手段を用いても良い。よって上記で言う属性及び属性変更はその他のユーザレベルプロセス制御の実現手段をも総称しているものとする。
【産業上の利用可能性】
【０１２３】
本発明は、複数のアプリケションプログラムがＯＳの管理下で動くコンピュータシステムで、各アプリケションプログラムを適切に動作させる用途に利用できる。
【図面の簡単な説明】
【０１２４】
【図１】本発明の概要を説明するための図面である。
【図２】本発明の第１の実施の形態の構成を説明するための図面である。
【図３】本発明の第１の実施の形態におけるプロセス制御の動作を説明するための図面である。
【図４】本発明の第１の実施の形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。
【図５】本発明の第１の実施の形態における、被制御プロセスの消滅時の動作を説明するための図面である。
【図６】本発明の第１の実施形態の構成を説明するための図面である。
【図７】本発明の第１の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。
【図８】本発明の第１の実施形態の変形例の構成を説明するための図面である。
【図９】本発明の第１の実施形態の変形例の構成を説明するための図面である。
【図１０】本発明の第２の実施形態の構成を説明するための図面である。
【図１１】本発明の第３の実施形態の構成を説明するための図面である。
【図１２】本発明の第３の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。
【図１３】本発明の第４の実施形態の構成を説明するための図面である。
【図１４】本発明の第４の実施形態における、被制御プロセスによる子プロセス生成時の動作を説明するための図面である。
【図１５】本発明を実行した場合の実行結果について、具体的な効果を説明するための図面である。
【符号の説明】
【０１２５】
１１０  制御プロセス
１１１  プロセス管理機能部
１１２  属性変更機能部
１１３  被制御プロセス表
１１４  プロセステーブル検索機能
１２０  被制御プロセス
１２１  被制御プロセスＡ
１２２  被制御プロセスＢ
１３０  オペレーティングシステム
１３１  プロセステーブル
１３２  プロセス制御機能
１３３  プロセス生成/消滅機能
１３４  プロセストレース機能
２１０  プロセス生成通知
２２０  プロセス消滅通知
３１０  プロセス生成検出部
３２０  プロセス終了検出部
４１０  ダイナミックリンカ
４２０  システムライブラリ
４３０  カスタムライブラリ
５１０  プロセスＡ
５２０  プロセスＢ
５３０  プロセスＣ
【図１】
2008186383.tif 000003
【図２】
2008186383.tif 000004
【図３】
2008186383.tif 000005
【図４】
2008186383.tif 000006
【図５】
2008186383.tif 000007
【図６】
2008186383.tif 000008
【図７】
2008186383.tif 000009
【図８】
2008186383.tif 000010
【図９】
2008186383.tif 000011
【図１０】
2008186383.tif 000012
【図１１】
2008186383.tif 000013
【図１２】
2008186383.tif 000014
【図１３】
2008186383.tif 000015
【図１４】
2008186383.tif 000016
【図１５】
2008186383.tif 000017