(57)【特許請求の範囲】
【請求項１】
中央処理装置（ＣＰＵ）と複数のアクティブなアプリケーションプロセスを実行するオペレーティングシステムを有し、前記オペレーティングシステムが各プロセスにＣＰＵリソースを割り当て、各プロセスが複数のサブタスクを具備し、各サブタスクが複数のプライオリティレベルのうちの一つに割り当てられ、前記プライオリティレベルが最も高いプライオリティレベルと少なくとも１つのそれよりも低いプライオリティレベルを具備するデジタル処理システムにおいて、
ａ）各プロセスに対し、負荷分散比率が、該当するプロセス内のプライオリティが最も高いサブタスクに割り当てられるＣＰＵリソースとそれよりもプライオリティが低い各レベルのサブタスクに割り当てられるＣＰＵリソースの比を表している負荷分散比率を判定するステップと、
ｂ）各プロセス間で、プライオリティが最も高いサブタスクに割り当てられるＣＰＵリソースの合計とそれよりもプライオリティが低い各レベルのサブタスクに割り当てられるＣＰＵリソースの合計の比を表している総合負荷分散比率を判定するステップと、
ｃ）選択されたプロセスの負荷分散比率が総合負荷分散比率と異なっている場合に、前記選択されたプロセスに割り当てられるＣＰＵリソースを調整するステップと、
から成る前記ＣＰＵの負荷を分散する方法。
【請求項２】
前記調整ステップが、前記選択されたプロセスに割り当てられるＣＰＵリソースを制限するステップとから成る請求項１に記載の方法。
【請求項３】
前記サブタスクが２つのプライオリティレベルのうちの１つに割り当てられる請求項１に記載の方法。
【請求項４】
前記調整ステップが、さらに
ｉ）前記総合負荷分散比率を前記選択プロセスに報告するステップと、
ｉｉ）前記選択プロセスの現行負荷分散比率を判定するステップと、
ｉｉｉ）前記選択プロセスの前記現行負荷分散比率が前記総合負荷分散比率と等しいかそれ以上の場合に、前記オペレーティングシステムによって前記選択プロセスに割り当てられたＣＰＵリソースの一部が放棄されるステップと、
から成る請求項１に記載の方法。
【請求項５】
前記負荷分散比率を判定するステップが、
ｉ）プライオリティが最も高いサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
ｉｉ）それよりもプライオリティの低い各レベルのサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
から成る請求項１に記載の方法。
【請求項６】
複数のプロセスを実行する少なくとも１台の中央処理装置（ＣＰＵ）を有し、各プロセスが複数のサブタスクを具備するデジタル処理システムにおいて、
ａ）前記サブタスクの各々に対して高低いずれかのプライオリティレベルを割り当てるステップと、
ｂ）各プロセスに対し、プライオリティの高いタスクによる負荷とプライオリティの低いタスクによる負荷の比として定義される負荷分散比率を判定するステップと、
ｃ）各プロセスの負荷分散比率を合計することにより総合負荷分散比率を判定するステップと、
ｄ）少なくとも１つの選択プロセスの負荷分散比率が前記総合負荷分散比率と異なる場合に、前記選択プロセスによる負荷を調整するステップと、
から成る前記少なくとも１台のＣＰＵにかかる負荷を分散させる方法。
【請求項７】
前記調整ステップが前記選択プロセスに割り当てられたＣＰＵリソースを制限するステップから成る請求項６に記載の方法。
【請求項８】
前記調整ステップが、さらに、
前記総合負荷分散比率を前記選択プロセスに報告するステップと、
前記選択プロセスの現行負荷分散比率を判定するステップと、
前記選択プロセスの前記現行負荷分散比率が前記総合負荷分散比率と等しいかそれ以上の場合に、前記オペレーティングシステムによって前記選択プロセスに割り当てられたＣＰＵリソースの一部が放棄されるステップと、
から成る請求項６に記載の方法。
【請求項９】
前記負荷分散比率を判定するステップが、
プライオリティが最も高いサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
それよりもプライオリティの低い各レベルのサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
から成る請求項６に記載の方法。
【請求項１０】
メモリに記憶された複数の非通信プロセスを実行する中央処理装置を有し、各プロセスが複数のサブタスクを具備するタイムシェアリングデジタル処理システムにおいて、
ａ）最も高いプライオリティレベルと少なくとも１つのそれよりも低いプライオリティレベルを含む複数のプライオリティレベルのうちの１つを各サブタスクに割り当てるステップと、
ｂ）プライオリティが最も高いサブタスクによる前記総合ＣＰＵリソースとそれよりもプライオリティが低い各レベルのサブタスクによる各プロセス間の総合ＣＰＵ負荷の比に基づき目標負荷分散比率を定期的に判定するステップと、
ｃ）少なくとも１つの選択プロセスの前記負荷分散比率が前記目標負荷分散比率に等しい場合に、前記選択プロセスによる負荷を制限するステップと、
から成る負荷分散方法。
【請求項１１】
前記制限ステップが、前記中央処理装置のタイムスライスの一部をオペレーティングシステムに引き渡すステップから成る請求項１０に記載の方法。
【請求項１２】
前記プライオリティレベルを割り当てるステップが、さらに、２つのプライオリティレベルのうちの１つを割り当てるステップから成る請求項１０に記載の方法。
【請求項１３】
前記制限するステップが、さらに、
ｉ）前記目標負荷分散比率を前記選択プロセスに報告するステップと、
ｉｉ）前記選択プロセスの現行負荷分散比率を判定するステップと、
ｉｉｉ）前記選択プロセスの前記現行負荷分散比率が前記目標負荷分散比率と等しいかそれ以上の場合に、前記オペレーティングシステムによって前記選択プロセスに割り当てられたＣＰＵタイムの一部が放棄されるステップと、
から成る請求項１０に記載の方法。
【請求項１４】
前記負荷分散比率を判定するステップが、
ｉ）プライオリティの最も高いサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
ｉｉ）それよりもプライオリティの低い各レベルのサブタスクによって占有されているＣＰＵタイムの総計を判定するステップと、
から成る請求項１０に記載の方法。
【請求項１５】
複数のアプリケーションプロセスを実行する中央処理装置と前記アプリケーションプロセスに対応する命令を記憶するメモリとを具備し、前記プロセスの各々が複数のサブタスクを有し、サブタスクの各々に高低いずれかのプライオリティレベルが割り当てられているデジタル処理システムにおいて、
ａ）対応するプロセス内のサブタスクの実行をスケジューリングするプロセスの各々に関連し、各スケジューラが該プロセス内のプライオリティの高いサブタスクと低いサブタスクの間の負荷分散を判定するスケジューラと、
ｂ）各プロセスから負荷分散を受信し、目標負荷分散を判定する負荷分散リポジトリと、
ｃ）対応するプロセスの負荷分散が目標負荷分散と異なる場合に、対応するプロセスによる負荷を制限する各スケジューラと、
から成る前記中央処理装置の負荷を分散するシステム。
【請求項１６】
前記負荷分散リポジトリが、プライオリティの高いサブタスクによる中央処理装置の総合負荷とプライオリティの低いサブタスクによる中央処理装置の総合負荷の比に基づき目標負荷分散を判定する請求項１５に記載のシステム。
【請求項１７】
各スケジューラに、前記負荷分散リポジトリに対応する負荷分散を報告する報告サブタスクが設けられている請求項１５に記載のシステム。
【請求項１８】
前記対応するプロセスの負荷分散が前記目標負荷分散に等しいかそれ以上の場合に、オペレーティングシステムによって対応するプロセスに割り当てられたタイムスライスの一部が放棄されるように各スケジューラが作成されている請求項１５に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、少なくとも１台の中央処理装置（ＣＰＵ）と実行される複数のアプリケーションプロセスを有するデジタル処理システムを制御する方法と装置に関し、詳しくは、タイムシェアリングシステムにおいて非通信プロセス間のＣＰＵの負荷を分散させるためのシステムおよび技法に関するものである。
【０００２】
【従来の技術】
タイムシェアリングまたはマルチタスク環境では、ある一定の時点において、多くのアプリケーションプロセスまたはタスク間で、１台またはそれ以上の中央処理装置による処理資源の使用に対して競合が発生する。ＣＰＵは、通常、複数のプロセスを同時に実行することはないが、これらのプロセスは、その完了時まで、ＣＰＵリソース、すなわち、処理時間を共有するという意味において、アクティブである。
【０００３】
アクティブなアプリケーションプロセスによるＣＰＵリソースのリアルタイムな占有を、ここでは、そのプロセスによるＣＰＵ「負荷」と呼ぶことにする。タイムシェアリングシステムでは、既定のプロトコルに応じて、各アクティブなアプリケーションプロセスによる負荷が、オペレーティングシステムによって制御あるいは分散されることがよくある。「負荷分散」という語は、アクティブなアプリケーションプロセスの中でＣＰＵリソースを割り当てるシステムや技法に対して用いられる。負荷分散によって、それぞれ異なる所望の対象を実行することもできる。例えば、予め割り当てられているプライオリティに従って、各アプリケーションプロセスによるＣＰＵ負荷を管理することができる。また、これ以外の負荷分散技法によれば、アプリケーションプロセスの実行時間を速くすることもできる。
【０００４】
複雑なタイムシェアリングまたはマルチタスクシステムでは、ある一定の時点で、何百ものアプリケーションプロセスやタスクをＣＰＵリソースに対してアクティブに競合させることができる。このようなアプリケーションプロセスには、それぞれ何百あるいは何千ものサブタスクが含まれていることもある。無線のセルラー方式では、例えば、移動加入者無線電話と地理的に隣接した区域内に配置されているセルサイトとの無線通信により、電話網へのアクセスが行なえる。各セルサイトは、無線トランシーバやアンテナおよび制御機器などの各種ハードウェアおよびソフトウェアを装備することにより、移動加入者およびセルサイト間の信号伝送を容易にしている。
【０００５】
高度なセルラーシステムでは、セルラー通信の重要な部分に関する制御は、１台のＣＰＵによって行われ、そのＣＰＵリソースは、複数の無線制御システム（ＲＣＳ）の間で共有され、各システムが複数のマイクロセルを支援すると同時に、各自の常駐ソフトウェア支援アプリケーションに依存している。例えば、ＵＮＩＸベースのオペレーティングシステムなどのオペレーティングシステムには、ＲＣＳ間でＣＰＵリソースを共有することができるスケジューラが付いている。各ＲＣＳ内には、ＲＣＳに関連する呼処理、翻訳、および監査などの多様なサブタスクを制御するために、ソフトウェアアプリケーションプロセスが設けられている。これらのサブタスクは、重要度やプライオリティなどの多様なレベルを有している。ＵＮＩＸなどのオペレーティングシステムでは、その配下で動作するアプリケーションプロセスに対して、外部で割り当てられたプライオリティを付与している。通常、同等のプライオリティを有するソフトウェアアプリケーションプロセスは、すべてＵＮＩＸによって、ＣＰＵタイムの同等部分に割り当てられる。
【０００６】
【発明が解決しようとする課題】
負荷分散の前記プライオリティ技法は、複雑な無線通信網の制御に使用されるようなタイムシェアリングシステムに利用された場合に、不適正な結果を招くことがある。そのようなシステムでは、適正な負荷分散を行うために、サブタスクレベルでアドレス指定された特定の種類の機能を検討すべきであるが、周知の技法では、これは実行不可能である。通常、メモリやプロセス上の限界から、オペレーティングシステムは、サブタスクレベルで詳細な情報を追跡することができない。ＣＰＵリソースは、アプリケーションプロセスレベルで割り当てられたプライオリティに関してのみ分配される。したがって、周知のシステムでは、任意の一定の時点に、どのアプリケーションプロセスがＣＰＵリソースの大半をプライオリティの高いサブタスクに割り当てているのか監視または判断することができない。また、周知のシステムでは、どのアプリケーションプロセスがＣＰＵタイムスライスの大半を割り当てて、プライオリティの低いサブタスクを完了させているのか監視あるいは判断することができない。このため、  あるアクティブなアプリケーションプロセスのプライオリティの高いタスクの終了に遅れが生じる一方で、ＣＰＵリソースが別のアプリケーションプロセスのプライオリティの低いタスクに引き渡されることもある  。
【０００７】
この問題は、前記の無線通信システムの例に関連して説明がなされた場合に一層明らかになる。呼処理や翻訳に関連するサブタスクは、監査、保守または「ハウスキーピング」などの機能に関連するサブタスクに比べて明らかに重要であり、呼処理の「ボトルネック」によって、加入者への着呼に遅れが生じることがある。他方、保守に関するサブタスクは、大抵、ある一定のプロセスに割り当てられたＣＰＵタイムスライス内の「アイドルタイム」を埋めるために設計されている。呼処理および翻訳は、「メッセージ駆動」プロセスであり、すなわち、前記プロセスは、加入者への着信などの外部イベントによって開始され、加入者が必要とするＣＰＵリソースがそのときどきで変化する。オペレーティングシステムから見た場合、ある一定のＵＮＩＸプライオリティレベルのアプリケーションプロセスは、いずれもＣＰＵタイムの同等のスライスに対して競合している。あるＲＣＳがそのＣＰＵリソースの全割り当てを用いて呼処理のアドレス指定をする一方で、別のＲＣＳがそのＣＰＵリソースの全割り当てを用いて重要度の低い監査または保守機能だけを実行している場合、オペレーティングシステムは、判断方法を持たない。このため、ＣＰＵリソースは、サブタスクレベルでプライオリティの低い機能よりもプライオリティの高い機能の完了を優先するような方法で割り当てられていない。
【０００８】
したがって、サブタスクレベルでプライオリティの低い機能よりもプライオリティの高い機能を優先するような方法でＣＰＵリソースを割り当てる負荷分散を行う方法および装置を提供することが望ましい。このようなシステムでは、ＣＰＵリソースの割り当てを用いて比較的低い割合を占めるプライオリティの高いサブタスクを完了させるアクティブなアプリケーションプロセスがリソースを放棄して、ＣＰＵリソースの割り当てにより比較的高い割合を占めるプライオリティの高いサブタスクを完了させる１つまたはそれ以上のアクティブなプロセスに有利になるように、ＣＰＵ負荷を分配することができる。
【０００９】
【課題を解決するための手段】
本発明は、前記目的を実現する、タイムシェアリングシステムにおける非通信プロセス間の負荷分散を行う方法と装置を提供する。本発明によれば、ＣＰＵリソースは、全アクティブプロセス内で、プライオリティの低いサブタスクよりもプライオリティの高いサブタスクを優先的に完了させるようにＣＰＵリソースが割り当てられる。各アプリケーションプロセス内のサブタスクは、少なくとも２つのプライオリティレベルのうちの１つに割り当てられる。各プロセスは、負荷分散リポジトリ（ＬＢＲ）とインタフェースする報告サブタスクと共に提供されている。ＬＢＲは、オペレーティングシステムの配下に置かれた別のプロセスであってもよい。また、インタフェースは、メッセージインタフェースでも、プロセス間で共有されるメモリアクセスによって実行されてもよい。各アクティブなアプリケーションプロセスの報告サブタスクは、該当するプロセスに対する負荷分散をＬＢＲに報告する。この負荷分散は、プライオリティが最も高いサブタスクによるＣＰＵ負荷、すなわち、処理時間と、それよりもプライオリティの低い各レベルのサブタスクによるＣＰＵ負荷との比によって定量化される。
【００１０】
すべてのアクティブプロセスの負荷分散比率の総計を求め、総計した負荷分散を再度各アクティブなアプリケーションプロセスに目標比率として報告することにより、ＬＢＲによって目標となる負荷分散比率が判定される。また、各プロセス内のスケジューラは、該当するプロセスの現行負荷分散比率を監視する。目標比率よりも低い負荷分散比率を有するプロセスは、全アクティブプロセス間の平均比率よりも低い割合を占めるプライオリティの高いサブタスクに対してＣＰＵリソースを利用している。このようなプロセス内の対応スケジューラは、現行の負荷分散が目標比率と等しいかそれ以上であるときにＣＰＵリソースを放棄し、これによってオペレーティングシステムの配下にある該当プロセスに割り当てられたＣＰＵタイムスライスの一部が放棄される。
【００１１】
本発明により、  ＣＰＵ負荷分散状況が、高い割合を占めるプライオリティの低いサブタスクが完了間近になるにしたがってＣＰＵリソースを使い果たすアクティブなアプリケーションプロセスのＣＰＵタイムの時間が短縮される一方で、高い割合を占めるプライオリティの高いサブタスクが完了間近になるにつれてＣＰＵリソースを使い果たす１つまたはそれ以上の他のアクティブプロセスにＣＰＵリソースが使用される頻度が高くなるという利点が得られる。
【００１２】
本発明は、一定の各部とステップによる実際の形式を採用し、本明細書では、その好適な実施例が詳細に説明され、本明細書の一部を形成する添付図面に実施例の図が示されている。
【００１３】
【発明の実施の形態】
図１は、本発明による負荷分散システム１００の略図である。コンピュータプラットフォーム１１０は、ＲＡＭ１１４とＲＯＭ１１６に記憶された命令を実行するＣＰＵ１１２などのハードウェアコンポーネントを具備し、ＣＰＵ１１２は、１台のＣＰＵまたは並行して動作する複数のＣＰＵのいずれかを示している。通常の技術を有する当業者であれば、図１がコンピュータプラットフォーム１１０がかなり省略して描かれていることが理解され、通常は、種々の周辺機器やデータバスが中に含まれている。ここでは、本発明の詳細な説明に必要なプラットフォーム１１０の各要素だけが示されている。コンピュータプラットフォーム１１０は、さらに、ＣＰＵ１１２と多く（ｎ）のアプリケーションプロセス１２２との間にある一定の手順インタフェースを提供するオペレーティングシステム１１８を具備しており、オペレーティングシステム１１８は、ＵＮＩＸなどの全機能型オペレーティングシステムでもよい。
【００１４】
アプリケーションプロセス１の略図によって示されているように、各アプリケーションプロセス１２２は、対応するスケジューラ１２６の管理制御によって実行される多く（ｍ）のサブタスクを具備している。図１には、３つのアプリケーションプロセスしか示されていないが、本発明が適用可能なプロセスに特有のシステムが、何百ものアクティブなアプリケーションプロセスを具備してもよいことは明らかである。さらに、各プロセスは、数百あるいは数千ものサブタスクを具備していてもよい。
【００１５】
各プロセス１２２内のサブタスクは、関連する機能により様々なプライオリティレベルを有することが考えられる。各プロセス１２２内のスケジューラ１２６は、常に、プライオリティの高いサブタスクをプライオリティの低いサブタスクよりも先に実行するようにスケジューリングを行う。最も簡単な形式では、スケジューラ１２６が、わずか２つだけのプライオリティレベル、すなわち、高または低を認識する。さらに複雑な形式になると、複数の異なるプライオリティレベルのうちのいずれかが各サブタスクに割り当てられる。本発明では、両方のプライオリティスキームに対するアプリケーションを検索する。
【００１６】
本発明によれば、ＬＢＲ１２０は、プロセス（１〜ｎ）の各々の報告サブタスク１２４とインタフェースする。このインタフェースは、オペレーティングシステム１１８により実行されるメッセージインタフェースの形式を採用してもよい。代わりに、インタフェースが、共有されているメモリアクセスによって実行されてもよく、これにより、各アプリケーションプロセス１２２は、ＬＢＲ１２０からもアクセスされる既定の記憶場所への書き込みおよびそこからの読み出しを行うルーチン（不図示）が得られる。メッセージインタフェースの場合、ＬＢＲは、メッセージが受信された時点で、報告プロセス用の平均値とＣＰＵの総合負荷を更新する働きをする。また、ＬＢＲは、全プロセスに対して一定時間の間隔で更新する機能を持つことも可能である。その場合、下記のＬＢＲ報告インタバルを、任意のアプリケーションプロセス１２２の報告インタバルよりも短くすることが必要である。
【００１７】
図２は、本発明によるＬＢＲ１２０を実行するプロセスを表しているフローチャートである。このフローチャートは、（ｎ個の）プロセスおよび（ｊ個の）プライオリティレベルを有するサブタスクを備えたシステムの一般的な論理の流れを示している。ステップ２００では、ＬＢＲ１２０が、各アクティブなアプリケーションプロセス１２２からＣＰＵの負荷分散を取得する。（ｎ個の）アクティブプロセスの各々に対し、報告サブタスク１２４を介してアプリケーションプロセススケジューラ１２６によってＬＢＲ１２０に負荷分散が報告される。ある一定のプライオリティレベル（ｊ）におけるプロセス（ｉ）のサブタスクによる負荷は、Ｌ（ｉ，ｊ）によって表してもよい。例えば、Ｌ（１，１）は、プロセス１のプライオリティレベル１（最高位のプライオリティレベル）のサブタスクによる負荷を表し、Ｌ（１，２）は、プロセス１のプライオリティレベル２のサブタスクによる負荷を表し、Ｌ（２，１）は、プロセス２のプライオリティレベル１のサブタスクによる負荷を表している。ＣＰＵ負荷Ｌは、ＣＰＵが、ある一定のプライオリティレベルでサブタスクを実行している時間、すなわち、ミリ秒に対応する値によって表してもよい。
【００１８】
通常、オペレーティングシステム１１８は、アプリケーションプロセス（１〜ｎ）に割り当てられた複数の異なるプライオリティレベルを認識する。同一のプライオリティレベルで動作しているアプリケーションプロセスには、オペレーティングシステム１１８の下で等しいＣＰＵタイムが割り当てられる。オペレーティングシステム１１８によって利用されるプライオリティレベルの数は、本発明によるプライオリティ数と異なっていてもよい。例えば、ＵＮＩＸベースのオペレーティングシステムは、８個のプライオリティレベル、０〜７を認識してもよい。ＵＮＩＸの配下で動作しているサブタスクに、８個のプライオリティレベルのうちの一つを割り当ててもよいが、本発明の負荷分散スキームは、ＵＮＩＸプライオリティレベルの全部を認識しなくてもよい。そのような場合、各アプリケーションは、ＵＮＩＸプライオリティレベルを、ＬＢＲが使用するプライオリティレベルにマッピングする必要がある。例えば、ＬＢＲが２つしかないプライオリティレベル（高および低）を有する負荷分散報告スキームを実行する場合、ＵＮＩＸのプライオリティレベル０〜３は低いプライオリティにマッピングされ、ＵＮＩＸのプライオリティレベル４〜７は、高いプライオリティにマッピングされる。このスキームにより、異なるＵＮＩＸプライオリティレベルを持つアプリケーションプロセスは、ＬＢＲ実装範囲内の同等な条件で負荷を比較することができる。
【００１９】
ステップ２１０は、ＬＢＲプロセスが報告インタバルの終了を判断するステップである。本発明の好適な実施例によれば、ＬＢＲは、好ましくは１秒と同種の報告インタバルにより、各アクティブプロセス（ｌ）から負荷分散比率を定期的に取得する。報告インタバルが終了していない場合は、ＬＢＲプロセスは、ステップ２００に戻って負荷Ｌ（ｉ，ｊ）を取得する。通常の技術を有する当業者であれば、プロセス内の各種サブタスクが完了あるいはアクティブまたはイナクティブになるにしたがって、報告インタバル中に負荷Ｌ（ｉ，ｊ）が変化することが理解できるであろう。報告インタバルが終了した場合には、ＬＢＲプロセスは引き続きステップ２１２に移り、各サブタスクプライオリティレベルに対して総合負荷値が判定される。ステップ２１２では、ＬＢＲ１２０により、各プライオリティレベル（ｊ）に対して負荷Ｌ（ｉ，ｊ）の集計が行われる。ある一定のサブタスクプライオリティレベル（ｊ）による総合負荷は、次の式で表すことができる。
ＡＧＧ（ｊ）＝Ｌ（１，ｊ）＋  Ｌ  （２，ｊ）＋．．．  Ｌ  （ｎ，ｊ）          （１）
ただし、ｎをプロセス数とする。
【００２０】
ステップ２１４では、ＬＢＲプロセスが、総合負荷分散または目標比率を判定する。これらの値は、プライオリティが最も高いサブタスクの総合負荷とそれよりもプライオリティが低いサブタスクの各総合負荷との比を表している。ステップ２１６では、以下に説明されている方法により、対応するスケジューラが使用する各プロセスの報告サブタスクに対して総合負荷比率が報告される。
【００２１】
図２は、ＬＢＲプロセスの一般化された論理フローを示している。わずか３つのプロセスと２つのサブタスクプライオリティレベルしか持たない簡易システムに適用される前記一般化論理フローの一例は、ＬＢＲプロセスを理解するうえで役立つものである。この例に関しては、簡易システムなどの最初のＬＢＲ報告インタバル中のＣＰＵ負荷分散を示す図４Ａを参照しながら後で説明がなされている。ステップ２００は、判定する６つのＣＰＵ負荷Ｌ（ｉ，ｊ）（プロセス１、２、３の各々に対して２つ）に関するものである。したがって、最初の報告インタバルでは、オペレーティングシステムによってタイムインタバルが割り当てられるプロセス１による１００ミリ秒（ｍｓ）の負荷には、プライオリティの高い（プライオリティレベル１）サブタスクによる２０ミリ秒が含まれ、８０ミリ秒は、プライオリティの低いサブタスク（プライオリティレベル２）によるものである。同様に、プロセス２および３の負荷が、図４Ａに示されている。ＣＰＵ負荷の合計は、オペレーティングシステムにより各プロセスごとに１００ミリ秒のタイムスライスが割り当てられることから、各プロセスに対して１００ミリ秒となる。各プロセスは、タイムスライスが終了しないうちに、オペレーティングシステムに制御を引き渡すことができるが、プロセスは、オペレーティングシステムによって割り当てられるインタバルを超過してタイムスライスを増加させることはできない。本例は、最初のＬＢＲ報告インタバルに関するものであることから、ステップ２１０は、定義により、２つの総合負荷ＡＧＧ（１）とＡＧＧ（２）（各サブタスクプライオリティレベルに１つ）が判定されるステップ２１２に分岐する。本例では、  ＡＧＧ（１）の値が１５０ミリ秒、  ＡＧＧ（２）の値が１５０ミリ秒となる。ステップ２１４では、１つの総合比率が判定され、  ＡＧＧ（１）：ＡＧＧ（２）は１２０：１８０に等しい。この場合の総合負荷比率は、すべてのアクティブプロセス（この場合、３つ）に関して平均した負荷比率を示すものであり、ＣＰＵ負荷は、プライオリティの高いサブタスクによるものよりも、プライオリティの低いサブタスクによるものの方が多い。
【００２２】
図３は、プロセススケジューラ１２６の論理フローを表すフローチャートである。ステップ３００では、スケジューラ１２６が、ＬＢＲから総合負荷分散または目標比率を取得する。次に、ステップ３１０では、実行可能なプライオリティの最も高い（すなわち、プライオリティレベル１）サブタスクがすべてスケジュールされ、ＣＰＵによって実行される。次にスケジュールプロセスはステップ３２０に進み、次のプライオリティがそれよりも低いサブタスクがスケジュールおよび実行される。ステップ３３０では、プロセスにより、新規のプライオリティの高い方のサブタスクがアクティブになっているか判断される。アクティブになっていれば、プロセスはステップ３１０に分岐して戻り、これらのサブタスクに対してスケジュールと実行がなされる。新規のプライオリティの高いサブタスクがアクティブになっていない場合は、３４０において、プロセスにより現行の負荷分散が判定される。
【００２３】
ステップ３４５では、プロセスに割り当てられたＣＰＵタイムスライスが終了しているかどうか判断がなされる。終了している場合、ステップ３６０に分岐して、オペレーティングシステムにプロセス制御が引き渡される。ＣＰＵタイムスライスが終了していなければ、プロセスによりステップ３５０にそのまま進む。ステップ３５０では、スケジューラにより、現行負荷分散比率が総合負荷分散比率を下回っているかどうか判断され、該プロセスは、ステップ３２０に分岐して戻り、割り当てられたＣＰＵリソースがプライオリティの低いサブタスクに割り当てられる。現行負荷分散比率が総合負荷分散比率よりも低くない場合は、該プロセスはステップ３６０に進み、該当するプロセスに与えられた時間の割り当てを減らすことにより、該プロセスによる負荷が調整される。
【００２４】
通常の技術を有する当業者であれば、図３に示されている論理フローが、２またはそれ以上のサブタスクプライオリティレベルを有するシステムに利用できることが理解できるであろう。例えば、サブタスクプライオリティレベルが３つの場合、スケジュールを行うプロセスが、まず初めに最も高いプライオリティと二番目に高いプライオリティのレベルによって表される現行の負荷分散に基づきＣＰＵ負荷を調整する。最も高いプライオリティレベルと二番目に高いプライオリティレベルを持つサブタスクがすべて完了したら、次に、ステップ３５０において、該プロセスにより、三番目に高いプライオリティレベルによるＣＰＵ負荷を評価し、最も高いプライオリティレベルと三番目に高いプライオリティレベルに関する負荷分散が総合比率の値に達した時点で負荷を調整することにより、分散比率が判定される。
【００２５】
図４Ａに関してすでに説明された簡易例に戻って説明すると、図４Ｂの表に、二番目のＬＢＲ報告インタバル中の負荷分散が示されている。このＣＰＵ負荷分散は、プロセス１および２のスケジューラ１２６の結果として、前記二番目のＬＢＲ報告インタバル中に調整される。この負荷分散は、新規のプライオリティの高いサブタスクが、いずれも前記二番目の報告インタバル中にアクティブになっていない簡潔な状況を表している。しかし、通常は、新規のプライオリティの高いサブタスクはアクティブになり、プロセス内の負荷分散は変化する。重要なのは、２０ミリ秒のプライオリティの高い作業と３０ミリ秒のプライオリティの低い作業が行われた後に、プロセス１が目標分散比率である１２０：１８０に達することから、プロセス１のスケジューラ１２６が５０ミリ秒後にＣＰＵリソースを自発的に放棄する点である。プロセス２の元の負荷分散が目標となる分散比率に等しいことから、プロセス２の負荷分散は変化しない。さらに、プロセス３は、最初のＬＢＲ報告インタバルに見られるように、６０ミリ秒のプライオリティの高い作業と４０ミリ秒のプライオリティの低い作業を実行する。プロセス３は、９０ミリ秒のプライオリティの低い作業を実行して目標分散比率を達成する必要があるが、オペレーティングシステムにより１００ミリ秒の時間しか割り当てられていない。
【００２６】
次に、二番目のＬＢＲ報告インタバル中に、プロセス１によるＣＰＵ負荷が１００ミリ秒から５０ミリ秒に減少したことが明らかに示されている。したがって、ＬＢＲ実装を伴わない場合に比べて５０ミリ秒早く、ＣＰＵリソースがプロセス２およびプロセス３に割り当てられる。このため、プロセス３の範囲内のプライオリティの高いサブタスクは、ＬＢＲ実装があることから、早くアドレス指定される。これにより、比較的大きい割合を占めるプライオリティの高いサブタスクを処理しているプロセスに対して、ＣＰＵリソースがより頻繁に割り当てられることになる。
【００２７】
前記３つのプロセスにおいて三番目と四番目のＬＢＲ報告インタバルをさらに繰り返した２つのプライオリティレベルの例が、図４Ｃと図４Ｄにそれぞれ示されている。図４Ｃについて説明すると、プロセス１に充てられたＣＰＵリソースは、さらに、４１．６ミリ秒まで減少する。同じく、プロセス２に充てられたＣＰＵリソースは、１００ミリ秒（図４Ｂ）から８３．２ミリ秒に減少する。負荷分散比率が最も高い（６０：４０）プロセス３は、（４２＋８３＝）１２５ミリ秒後の処理時間、すなわち、図４Ｂによって示される前回の反復時に比べて約２５ミリ秒早い時間を受信する。図４Ｄについて説明すると、（３８＋７５＝）１１３ミリ秒後に、ＣＰＵリソースがプロセス３に割り当てられる。ＬＢＲをさらに反復していくと、総合負荷分散比率がさらに低下して、等しい負荷分散が得られる方向へ各アプリケーションプロセスが移動していくことが明らかである。
【００２８】
したがって、本発明により、ＣＰＵリソースは、比較的低い割合を占めるプライオリティの高いサブタスクによって占有されているプロセスから、比較的高い割合を占めるプライオリティの高いサブタスクによって占有されているアプリケーションプロセスへと変化する。以上の説明は、本発明の好適な１実施例に対してのみなされたものである。本明細書を一読すれば、他の多くの変更や修正が可能なことは、通常の技術を有する当業者にとって明らかである。本発明の範囲は、そのような変更や修正すべてを網羅するものであり、その範囲は、添付したクレームによって定義される。
【図面の簡単な説明】
【図１】本発明の好適な実施例によるコンピュータプラットフォームの構造とプライオリティに基づく負荷分散システムを示す略図である。
【図２】本発明の好適な実施例によるＬＢＲプロセスを示すフローチャートである。
【図３】本発明の好適な実施例によるプロセススケジューラを示すフローチャートである。
【図４Ａ】本発明による最初のＬＢＲ報告インタバルにおけるプロセス負荷分散を示す表である。
【図４Ｂ】本発明による二番目のＬＢＲ報告インタバルにおけるＣＰＵ負荷分散を示す表である。
【図４Ｃ】本発明による三番目のＬＢＲ報告インタバルにおけるＣＰＵ負荷分散を示す表である。
【図４Ｄ】本発明による四番目のＬＢＲ報告インタバルにおけるＣＰＵ負荷分散を示す表である。
【図１】
0003585755.tif 000002
【図２】
0003585755.tif 000003
【図３】
0003585755.tif 000004
【図４Ａ】
0003585755.tif 000005
【図４Ｂ】
0003585755.tif 000006
【図４Ｃ】
0003585755.tif 000007
【図４Ｄ】
0003585755.tif 000008