JP3678414B2 - 多重プロセッサ・システム - Google Patents
多重プロセッサ・システム Download PDFInfo
- Publication number
- JP3678414B2 JP3678414B2 JP2001198349A JP2001198349A JP3678414B2 JP 3678414 B2 JP3678414 B2 JP 3678414B2 JP 2001198349 A JP2001198349 A JP 2001198349A JP 2001198349 A JP2001198349 A JP 2001198349A JP 3678414 B2 JP3678414 B2 JP 3678414B2
- Authority
- JP
- Japan
- Prior art keywords
- thread
- threads
- processor
- execution queue
- node
- 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
- 238000000034 method Methods 0.000 claims description 97
- 230000000737 periodic effect Effects 0.000 claims description 40
- 230000008569 process Effects 0.000 claims description 40
- 241001522296 Erithacus rubecula Species 0.000 claims description 31
- 235000003642 hunger Nutrition 0.000 claims description 28
- 230000037351 starvation Effects 0.000 claims description 25
- 238000012545 processing Methods 0.000 claims description 18
- 238000010586 diagram Methods 0.000 description 10
- 238000004590 computer program Methods 0.000 description 8
- 229910000831 Steel Inorganic materials 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 239000010959 steel Substances 0.000 description 5
- 238000013459 approach Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000013256 coordination polymer Substances 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000007616 round robin method Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000010187 selection method Methods 0.000 description 1
- 238000009987 spinning Methods 0.000 description 1
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/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- 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/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
Description
【０００１】
【発明の属する技術分野】
本発明は、多重プロセッサ・システムに関する。本発明は、特に、多重実行キュー・システムにおいて負荷平準化（load balancing: ロード・バランシング）を行なう方法と装置に関する。
【０００２】
【従来の技術】
多重プロセッサ（multiple processor: 多重処理装置）システムは、一般に、当技術分野では公知である。プロセスは、並行して処理することのできる複数のスレッドに分解される。しかしながら、スレッドは、プロセッサが実行できる状態になるまで、多重プロセッサ・システムの各プロセッサごとにキュー（queue:待ち行列）に入れる必要がある。
【０００３】
多重プロセッサ・システム中の１つのプロセッサがディスパッチすべきスレッドをキューに入れる公知の手法の１つに、単一の集中化したキュー、すなわち単一の集中化した「実行キュー（run queue)」を保持するものがある（「ディスパッチする」とは、実行の準備ができているスレッドに対してプロセッサ時間を割り当てることである）。プロセッサは、自らが使用可能になると、実行キューから次のスレッドを取り出して、それを処理する。ところが、集中化した実行キューから次のスレッドを取り出すのを待つ間に、プロセッサが実行キューのロックの上で空転する、すなわちアイドルになるのに起因して、スレッドと処理時間が失われる可能性がある。したがって、この手法の欠点は、集中化した実行キューがボトルネック（障害）になってしまう、という点である。
【０００４】
スレッドを実行キューに入れる別の公知の手法は、各プロセッサごとに独立した実行キューを保持することである。この場合、スレッドが生成されると、それは、ラウンド・ロビン方式（総当たり方式）でプロセッサに割り当てられる。しかしながら、このような手法では、過負荷になるプロセッサがある一方、比較的アイドルなプロセッサがある、という状態になる。さらに、優先順位の低いスレッドが待っている対象のプロセッサの実行キューに優先順位の高いスレッドが付加されることになるので、優先順位の低いスレッドの中には、飢餓状態、すなわち処理時間が全く与えられない状態になるものが出てくる。
【０００５】
上述したことから、多重プロセッサ・システムにおいて、高スループットを維持しながら、各プロセッサにかかる作業負荷を平準化する方法と装置を提供する新たな技術が求められている。さらに、複数の実行キューの間における作業負荷の初期負荷平準化を実現する新たな技術が求められている。
【０００６】
【課題を解決するための手段】
本発明は、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を実行して、システムの各プロセッサにかかる作業負荷が最適に平準化されるのを保証する方法と装置を提供する。初期負荷平準化は、プロセスの新たなスレッドをどの実行キューに割り当てるべきであるかを扱う。アイドル状態負荷平準化は、プロセッサがアイドル状態になり始めているときに、スレッドをある実行キューから別の実行キューに移動させる仕方を扱う。周期的負荷平準化は、負荷平準化を維持するために、スレッドを最重量負荷実行キューから最軽量負荷実行キューへ移動させる仕方を扱う。飢餓状態負荷平準化は、プロセッサ時間に飢えているスレッドが入っている実行キューを入れ換える仕方を扱う。
【０００７】
これらの手法は、グローバル実行キューとローカル実行キューを使って、負荷平準化を実行している。グローバル実行キューは、当該グローバル実行キューの面倒を見ているプロセッサのノードに関連付けられている。このノード内の各プロセッサは、ローカル実行キューの面倒も見ている。したがって、１つのノード内の各プロセッサは、グローバル実行キューとローカル実行キューとの双方の面倒を見ている。
【０００８】
初期負荷平準化は、グローバル実行キューを使って、アイドル状態のプロセッサのローカル実行キューに直接に配置できないスレッドを配置する。飢餓状態負荷平準化は、プロセッサ時間に飢えているスレッドをあまり忙しくないプロセッサがディスパッチできる公算を大きくするために、グローバル実行キューを使って、プロセッサ時間に飢えているスレッドを配置する。
【０００９】
アイドル状態負荷平準化と周期的負荷平準化は、システムのプロセッサの作業負荷を平準化させる過程で、スレッドをあるローカル実行キューから別のローカル実行キューへ移動させようとする。
【００１０】
【発明の実施の形態】
図１は、本発明を実現することのできる多重キュー・システム１００の典型例を示す図である。図１に示すように、多重キュー・システム１００は、多重プロセッサ（multiple processor: ＭＰ）システム１１０、組織化されてノード１２０〜１４０を形成している複数のＣＰＵ（central processing unit:中央処理装置）１１１〜１１７、およびディスパッチャ１５０を備えている（ディスパッチャとは、ＣＰＵがスレッドを実行するときの実行順序を管理する、オペレーティング・システムの機能単位〔ルーチン〕のことである）。
【００１１】
ＭＰシステム１１０は、複数のプロセッサ、たとえばＣＰＵ１１１〜１１７を備えていれば、どのような種類のシステムであってもよい。ＣＰＵ１１１〜１１７は、割り当てられた処理ジョブを処理することのできる処理装置であれば、どのような種類の処理装置であってもよい。ＣＰＵ１１１〜１１７は、組織化されてノード１２０〜１４０を形成している。ノード１２０〜１４０は、本来、実際の装置でなくてもよいが、しかし、グループ分けされたＣＰＵ１１１〜１１７の各グループを代表していると見なしうるものである。したがって、たとえば、ＣＰＵ１１１と１１２はノード１２０に関連付けられており、ＣＰＵ１１３と１１４はノード１３０に含まれており、ＣＰＵ１１５〜１１７はノード１４０に含まれている。
【００１２】
ディスパッチャ１５０は、ノード１２０〜１４０とＣＰＵ１１１〜１１７との間におけるジョブの負荷平準化を実行する。図１ではディスパッチャ１５０を集中化した単一の装置として示してあるけれども、ディスパッチャ１５０は、ＭＰシステム１１０全体に分布していてもよい。たとえば、各ノード１２０〜１４０、あるいはノード１２０〜１４０から成る各グループに独立したディスパッチャ１５０が関連付けられるように、ディスパッチャ１５０は、分散させることができる。さらに、ＭＰシステム１１０の各ＣＰＵ１１１〜１１７上で実行されるソフトウェアの命令としてディスパッチャ１５０を実現することもできる。
【００１３】
各ＣＰＵ１１１〜１１７は関連付けられたローカル実行キューを備えており、各ノード１２０〜１４０は関連付けられたグローバル実行キューを備えている。したがって、各ＣＰＵ１１１〜１１７は単一のローカル実行キューの面倒を見ており、各ノード１２０〜１４０に属す各ＣＰＵ１１１〜１１７は自らが属すノード用のグローバル実行キューの面倒を見ている。たとえば、ＣＰＵ１１１と１１２との双方は、ノード１２０に関連付けられたグローバル実行キューの面倒を見ている。
【００１４】
好適な実施形態では、ＣＰＵ１１１〜１１７とローカル実行キューとの間に１対１の対応関係があるけれども、本発明は、このような実施形態に限定されない。むしろ、ローカル実行キューは、ノードに属す複数のＣＰＵが共有することができる。したがって、たとえば、ＣＰＵ１１５と１１６が単一のロ第１のーカル実行キューを共用している一方で、ＣＰＵ１１７が第２のローカル実行キューを単独で使用するようにすることが可能である。
【００１５】
グローバル実行キューとローカル実行キューには、スレッドが格納されている。スレッドとは、マルチスレッド環境における個々のトランザクションのことである。マルチスレッド環境とは、単一のプログラム内でマルチタスクを許す環境のことである。マルチスレッドによって、同じプログラム内で並行して実行される実行の流れを多重化することが可能になる。各実行の流れは、異なるトランザクションまたはメッセージを処理している。www.techweb.com を参照されたい。
【００１６】
あるノードのグローバル実行キューは、ＣＰＵが自分のスレッドの面倒を見るための、対応するローカル実行キューと競合する。グローバル実行キュー内に存在するスレッドとローカル実行キュー内に存在するスレッドとは、優先順位に基づいて、ＣＰＵの資源を求めて競争する。
【００１７】
（ローカルおよびグローバル）実行キューに存在するスレッドは、自分に関連付けられた優先順位をもつことができる。実行キューは、その実行キューに関し最も優先順位が高い待ち状態のスレッドの優先順位の情報を実行キュー構造の中に保持している。ディスパッチャ１５０は、この優先順位情報を使って、次にディスパッチすべきスレッドを検索すべき実行キューはどれであるかを判断する。
【００１８】
グローバル実行キューとローカル実行キューとの双方が同じ優先順位の待ち状態にあるスレッドをもっている場合、ディスパッチャ１５０は、一般に、「同点決戦の勝者（tie breaker)」としてローカル実行キューを選択してスレッドをディスパッチする。ローカル実行キュー上のスレッドはそれに割り当てられたＣＰＵだけしか面倒を見ないので、このような選考方法を使う。他方、グローバル実行キューは、ノードに割り当てられたＣＰＵのうちどれが面倒を見てもかまわない。
【００１９】
しかし、上記のようにローカル実行キューを選択した結果、ローカル実行キューを勝者とする「同点決戦（tie break)」が２回続く場合には、グローバル実行キューを選択する。その理由は、ローカル実行キューを無条件に選択することを繰り返すことによって生じるグローバル実行キューの飢餓状態（長時間の停止状態）を避けるためである。
【００２０】
スレッドをディスパッチするために（ローカルまたはグローバル）実行キューを選択するとき、ディスパッチャ１５０は、当該実行キューをロックしようとする。実行キューを「ロックする（locking)」、あるいは、「実行キューのロック（run queue's lock）」を獲得する、という用語は、ディスパッチャ１５０がスレッドをディスパッチしようとしている間に実行キューが変更されるのを防ぐために、当該実行キューに対するアクセスをディスパッチャ１５０が制限することを指している。
【００２１】
グローバル実行キューをロックしようとして、それが不成功だった場合、たとえば別のＣＰＵが当該実行キューを既にロックしていた場合、ディスパッチャ１５０は、当該実行キューをロックしようと再試行する代わりに、ローカル実行キューを選択し、それからスレッドをディスパッチしようとする。実行キューに対してロックしようと再試行することは、実行キュー上で「空転する（spinning）」と呼ばれている。
【００２２】
グローバル実行キューをロックしようとして、それが成功したが、しかし、いったんロックしたのに当該グローバル実行キューの中にスレッドが全く存在しない場合、ディスパッチャ１５０は、ローカル実行キューを選択し、それからスレッドをディスパッチャしようとする。ロックは成功したが、しかし、グローバル実行キュー内には予期した優先順位と異なる優先順位のスレッドしか存在しない場合、ディスパッチャ１５０は、とにかくそのスレッドをディスパッチする。
【００２３】
上述したようなスレッドは、「未バインド（unbound)」スレッドと呼ばれている。「未バインド」スレッドとは、特定のＣＰＵが処理する必要のないスレッドのことである。「バインド済み（bound)」スレッドとは、特定のＣＰＵまたはＣＰＵ群が処理すべきことを示す識別子を備えたスレッドのことである。あるスレッドが特定のＣＰＵにバインドされている場合、当該スレッドは、当該ＣＰＵが面倒を見ているローカル実行キューに入れる必要がある。
【００２４】
通常、未バインドのスレッドは、いったん所定のＣＰＵにディスパッチされると、当該ＣＰＵが面倒を見ているローカル実行キューに半永久的に関連付けられる。例外（exception)は、ＰＯＳＩＸ（Portable Operating System Interface for ＵＮＩＸ（Ｒ） ）のコンプライアンス・フラグがセットされて（１にされて）実行される未バインドの固定優先順位のスレッドである。下で詳述するように、これらのスレッドは、常に優先順位を互いに厳格に維持してディスパッチしうるように、グローバル実行キューに格納されている。
【００２５】
ディスパッチャ１５０が実行するノード１２０〜１４０とＣＰＵ１１１〜１１７との間における負荷平準化に基づいて、グローバル実行キューにスレッドを追加する。負荷平準化には、多重実行キュー・システム１００の様々な実行キューを等しく使用するようにする多数の方法がある。負荷平準化は、次の４つの部分から検討することができる。すなわち、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および、飢餓状態負荷平準化である。以下ではこれら４つの部分のおのおのを独立して扱う。しかし、ＭＰシステム１１０全体で最適な負荷平準化を実現するために、これら４つの部分は、互いに協働して実装（implement)するように意図されている。
【００２６】
〔初期負荷平準化〕
初期負荷平準化とは、スレッド群が新たに生成されたときに、実行キュー全体に当該新たなスレッド群の作業負荷を分散させることである。図２と図３は、初期負荷平準化法を説明する多重実行キュー・システム２００の典型例を示す図である。
【００２７】
図２に示すように、新たなプロセス（あるいはジョブ）の一部として未バインドの新たなスレッドＴｈ１３が生成されると、ディスパッチャ１５０は、そのスレッドをアイドル状態のＣＰＵに関連付けられた実行キューに配置しようとする。こうするために、ディスパッチャ１５０は、多重実行キュー・システム２００のＣＰＵ２３０〜２８０の間のラウンド・ロビン検索を実行する。アイドル状態のＣＰＵが見つかったら、新たなスレッドＴｈ１３は、当該アイドル状態のＣＰＵのローカル実行キューに付加される。
【００２８】
ラウンド・ロビン検索は、一連のノード／実行キューのうち、最後のスレッドが割り当てられたノード／実行キューの後ろのノード／実行キューから開始する。
このように、この方法は、すべてのノードとＣＰＵ全体にスレッドを分散させながら、新たなプロセスの新たなスレッドをアイドル状態のＣＰＵに割り当てる。
【００２９】
以上のことから、図２に示す多重実行キュー・システム２００にラウンド・ロビン手法を適用して、新たなスレッドＴｈ１３は、アイドル状態のＣＰＵ２４０に関連付けられたローカル実行キュー２９２に割り当てる。新たなスレッドが次に生成されると、アイドル状態のＣＰＵを求めるラウンド・ロビン検索は、ＣＰＵ２５０とローカル実行キュー２９３から開始し、ＣＰＵ２６０〜２４０、およびノード２２０、２２４、２２５のローカル実行キュー２９４〜２９２を、アイドル状態のＣＰＵが見つかるまで、あるいは、ＣＰＵ／実行キューのおのおのを検索し終えるまで、総当たりする。
【００３０】
既存のプロセスの一部として未バインドのスレッドが生成されると、ディスパッチャ１５０は、この場合も、アイドル状態のＣＰＵがあればそれに当該未バインドのスレッドを配置しようとする。しかし、検索するＣＰＵと対応するローカル実行キューは、上記既存のプロセスのスレッドが割り当てられていたノードに関連付けられたものに限定する。複数のノードにわたってアドレス空間を共有するのは非効率なので、検索をこのように限定する。
【００３１】
したがって、たとえば、未バインドの新たなスレッドＴｈ１３が、スレッドＴｈ９が属すプロセスの一部をなすスレッドである場合、アイドル状態のＣＰＵを求めるラウンド・ロビン検索は、ノード２２４およびＣＰＵ２５０、２６０に限定する。図２の場合、ＣＰＵ２５０とＣＰＵ２６０はどちらもアイドル状態にないから、ＣＰＵ２５０およびＣＰＵ２６０の一方がスレッドＴｈ１３を処理するのに使用可能になるまで、スレッドＴｈ１３はグローバル実行キュー２２２に割り当てることになる。ＣＰＵ２５０およびＣＰＵ２６０の一方がスレッドＴｈ１３を処理するのに使用可能になったときには、スレッドＴｈ１３は、使用可能なＣＰＵ２５０または２６０のローカル実行キュー２９３または２９４に入れる。
【００３２】
図３に示すように、新たなスレッドＴｈ２０用に使用可能なＣＰＵが１つもない場合、スレッドＴｈ２０は、ラウンド・ロビン検索によって選考したグローバル実行キューに割り当てる。あるいは、スレッドＴｈ２０が新たなプロセスの新たなスレッドである場合、スレッドＴｈ２０は、最も空きの多い（すなわち最も少ししかロードされていない）ノードのグローバル実行キューに割り当てる。
【００３３】
図３に示す多重実行キュー・システム２００では、最も空きの多いグローバル実行キューは、グローバル実行キュー２２１である。スレッドＴｈ２０が既存のプロセスの新たなスレッドである場合、スレッドＴｈ２０は、上記既存のプロセスのスレッドが既に割り当てられているノード２２０、２２４、または２２６のグローバル実行キュー２２１〜２２３に割り当てる。
【００３４】
典型的な実施形態ではラウンド・ロビン検索を使用したけれども、本発明は、スレッドの割り当てに関し、ラウンド・ロビン検索に限定されない。むしろ、上述したラウンド・ロビン手法の代わりに、任意の負荷配置手法を使用することができる。
【００３５】
上述した初期負荷平準化法によれば、未バインドの新たなスレッドを現在アイドル状態にあるＣＰＵに割り当てることにより、あるいは、それらをグローバル実行キューに割り当てることにより、未バインドの新たなスレッドを迅速にディスパッチすることができる。グローバル実行キュー上のスレッドは、優先順位が許すかぎり、当該グローバル実行キューが属すノードで次に使用可能なＣＰＵにディスパッチする。
【００３６】
システム資源の平準化された利用を保証するために、初期負荷平準化のほかに、他の３つの方法、すなわちアイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を実行する。説明を明快にするために、これら３つの負荷平準化法は、単一のノードとそれに対応するＣＰＵに関して説明する。当業者にとって明らかになるように、これら３つの負荷平準化法は、本発明の本旨と範囲の内で、任意の数のノードとＣＰＵに適用することができる。
【００３７】
〔アイドル状態負荷平準化〕
アイドル状態負荷平準化は、それをしないとＣＰＵがアイドル状態になってしまうときに適用する。したがって、ディスパッチャ１５０（図１）は、作業負荷を他のＣＰＵから潜在的アイドル状態のＣＰＵ（放置するとアイドル状態になってしまうＣＰＵ）に移動させようとする。しかしながら、この移動プロセスは、スレッドにとってローカル実行キューが「キャッシュと類似している点（cache affinity）」を便宜的に考慮に入れている。
【００３８】
メモリ・キャッシュは、その速度がＣＰＵに近い暫定的な記憶装置である。メモリ・キャッシュは、命令実行速度を上げる「先読み（look-ahead）」機能を備えている。しかし、データは、キャッシュに数秒間あるいは数ミリ秒間しか留まることができない。
【００３９】
あるスレッド（あるいは同じプロセス起源の関連スレッド）がＣＰＵで以前に実行されていると、当該スレッドは、メモリ・キャッシュとの類似性を示すことがある。この「類似性（affinity）」は、ＣＰＵのキャッシュにはいくつかのデータが存在したままになっている可能性があるので、その既にキャッシュされているデータを使ってスレッドを迅速に処理することができる、という点にある。負荷平準化を実行しながら、このキャッシュとの類似性を考慮に入れるために、次に示すアイドル状態負荷平準化法を実行する。
【００４０】
あるＣＰＵがアイドル状態になろうとしている場合、ディスパッチャ１５０は、潜在的アイドル状態のＣＰＵで処理するノードに割り当てられている別の実行キューからスレッドを「スチール（steal)」しようとする。ディスパッチャ１５０は、潜在的アイドル状態のＣＰＵが割り当てられているノードのローカル実行キューを走査して、それらが次に示す基準を満たすローカル実行キューでないかどうか調べる。
（１）当該ローカル実行キューのスレッドの数は、当該ローカル実行キューが属すノードの全ローカル実行キューのうちで最大である。
（２）当該ローカル実行キューのスレッドの数は、当該ローカル実行キューが属すノードの現在のスチールしきい値（下で定義する）よりも大きい。
（３）当該ローカル実行キューには、少なくとも１つの未バインドのスレッドがある。
（４）現在のクロック・サイクルの間に、当該ローカル実行キューから最大スチールしきい値を超える数のスレッドがスチールされたことがない。
【００４１】
これらの基準を満たすローカル実行キューが見つかると、ディスパッチャ１５０は、当該ローカル実行キューから未バインドのスレッドをスチールしようとする。選択したローカル実行キューのロックを獲得したのちに、当該ローカル実行キューからスレッドをスチールする。選択したローカル実行キューのロックを直ぐに獲得できない場合、再試行は行なわない。
【００４２】
選択したローカル実行キューのロックを獲得したら、ディスパッチャ２５０は、未バインドのスレッドがまだ使用可能であり、最も優先順位の高い未バインドのスレッドを選択したことを確認する。スレッドのスチールは、当該スレッドのロックを獲得し、当該スレッドの実行キュー・ポインタを潜在的アイドル状態のＣＰＵに割り当てられているローカル実行キュー用の実行キュー・ポインタに変更することにより、行なう。ここでも、選択したスレッドのロックを直ぐに獲得できない場合、再試行は行なわない。
【００４３】
選択したスレッドのロックを獲得し、当該スレッドをスチールしたら、スチールしたスレッドは、直ぐにＣＰＵによって処理されるので、実際には、潜在的アイドル状態のＣＰＵのローカル実行キューに入れられることはない。典型的な動作を想定すると、スチールしたスレッドがディスパッチ・サイクルを完了すると、自然にこのようになっている。
【００４４】
アイドル状態負荷平準化は、対象とするノードのスチールしきい値によって束縛されている。スチールしきい値は、対象とするノードに属すすべてのローカル実行キューに対する平滑化平均負荷因数（smoothed average load factor）にある分数を乗じた数値である。この平滑化平均負荷因数は、クロック・サイクルごとに各ローカル実行キュー上のスレッドの数をサンプリングして決定する。
【００４５】
たとえば、ある期間におけるあるＣＰＵの負荷因数が５、１５、１６である場合、平滑化平均負荷因数は、１２になる（（５＋１５＋１６）÷３＝１２）。
たとえば、スチールしきい値＝（１／４）×平滑化平均負荷因数、である場合を想定すると、上記した例では、スチールしきい値＝（１／４）×１２＝３となる。スチールしきい値を算出する際に使用する分数（上記した例では１／４）は、実際には調整可能な数値である。したがって、スチールしきい値（上記した例では３）も調整可能な数値である。
【００４６】
したがって、スレッドのスチール元のローカル実行キューは、スチールしきい値を超える数のスレッドを保持している必要がある。上記した例では、スチールしきい値＝３であるから、スレッドのスチール元のスチール実行キューは、３個を超えるスレッドを保持している必要がある。そして、このうちの少なくとも１つは、未バインド、したがってスチール可能なスレッドでなければならない。また、上記ローカル実行キューは、すべてのローカル実行キューの中で最大個数のスレッドを保持していることも必要である。さらに、上記ローカル実行キューは、現在のクロック・サイクルの間に自分の中から最大個数のスレッドをスチールされていないことも必要である。
【００４７】
上述した方法の一例として、図４に示すノードを考える。図４に示すように、ＣＰＵ４２０がアイドル状態になろうとしており、それに関連付けられたローカル実行キュー４７２とグローバル実行キューには、スレッドが割り当てられていない。したがって、アイドル状態のＣＰＵ４２０は、別のローカル実行キュー４７１、４７３〜４７６からスレッドをスチールしようとする。
【００４８】
上述したスチール基準を考慮すると、上述した基準を満たすローカル実行キューは、ローカル実行キュー４７４である。これは、ローカル実行キュー４７４がすべてのローカル実行キュー４７１〜４７６の中で最も多い個数のスレッド（５個のスレッド）を保有しているからである。ローカル実行キュー４７４は、少なくとも１つの未バインドのスレッドを保有している（このように想定する）。ローカル実行キュー４７４は、スチールされうるスレッドの最大個数に達していない（これもこのように想定する）。
【００４９】
各ローカル実行キューの現在の作業負荷はローカル実行キュー群の平均負荷因数に等しいものとすると、ノード４００のスチールしきい値は現在約１であり、ローカル実行キュー４７４には５個のスレッドが割り当てられているから、ローカル実行キュー４７４が保有しているスレッドの個数は、当該ローカル実行キュー４７４が属すノードの現在のスチールしきい値よりも大きい。したがって、ローカル実行キュー４７４は、上述したスチール基準をすべて満たしている。それ故、ローカル実行キュー４７４中の第１の未バインドのスレッドをスチールして、その実行キュー・ポインタをローカル実行キュー４７２に再割り当てすることになる。
【００５０】
〔周期的負荷平準化〕
周期的負荷平準化は、Ｎクロック・サイクルごとに行なう。周期的負荷平準化は、アイドル状態負荷平準化と同様の方法で、１つのノードのローカル実行キューの作業負荷を平準化しようとするものである。しかしながら、周期的負荷平準化は、一般に、すべてのＣＰＵが１００％使用中であるときに行なう。
【００５１】
周期的負荷平準化には、割り当てられているスレッドの個数が平均して最も多いローカル実行キューと最も少ないローカル実行キューとを特定するために、１つのノードのローカル実行キューを走査することが含まれている。割り当てられているスレッドの個数が平均して最も多いローカル実行キューと最も少ないローカル実行キューとは、平均負荷が最も大きいローカル実行キューと平均負荷が最も小さいローカル実行キューのことであり、以下、これらを、それぞれ最重量ローカル実行キュー、最軽量ローカル実行キューと呼ぶ。
【００５２】
最後のＮクロック・サイクルでアイドル状態負荷平準化を通じて最軽量ローカル実行キューがスレッドをスチールした場合、周期的負荷平準化は行なわない。これは、周期的負荷平準化が、アイドル状態負荷平準化が行なわれておらず、かつ、すべてのノードのＣＰＵが使用中である状況を取り扱うことを指向しているからである。
【００５３】
最重量ローカル実行キューと最軽量ローカル実行キューとの間における負荷因数の差が所定のしきい値（たとえば１．５）以上の場合、周期的負荷平準化を行なう。上記の差がしきい値未満の場合、ＣＰＵの作業負荷は良好に平準化しているから、周期的負荷平準化を行なわない、と判断する。
【００５４】
周期的負荷平準化を行なうべき場合、ディスパッチャ１５０は、最重量ローカル実行キューのロックを獲得する。この場合、最重量ローカル実行キューのロックが直ぐに獲得できないときには、ディスパッチャ１５０は、最重量ローカル実行キューのロックを獲得する試行を繰り返す、すなわち、ディスパッチャ１５０は、最重量ローカル実行キューのロックの上で空転することになる。
【００５５】
いったん最重量ローカル実行キューのロックを獲得したら、ディスパッチャ１５０は、最重量ローカル実行キューを走査してスチールすべき未バインドのスレッドがないかどうか調べる。システム性能に影響を与えるのに十分なＣＰＵ時間を使うことになるスレッドをスチールする公算を高めるとともに、優先順位の高いスレッドを元のＣＰＵに委（ゆだ）ねるために、スチール可能な未バインドのスレッドを求める上記走査は、中くらいの優先順位のスレッドから開始する。次いで、上述したのと同じ方法で、該当するスレッドをスチールする。
【００５６】
周期的負荷平準化の一例として、図５に示すノード５００を考える。図５に示すように、各ＣＰＵ５１０〜５６０は、各自のローカル実行キュー５７１〜５７６にあるスレッドをディスパッチするのに忙しい。しかし、ＣＰＵ５１０〜５６０の間の作業負荷は、平準化していない。周期的負荷平準化では、最重量ローカル実行キューと最軽量ローカル実行キュー（この例の場合、ローカル実行キュー５７４と５７２）を見つける。
【００５７】
図５に示すように、最重量ローカル実行キュー５７４の負荷因数は４であり、最軽量ローカル実行キュー５７２の負荷因数は１である。負荷因数の間の差は、３であり、しきい値１．５よりも大きいから、ローカル実行キュー５７１〜５７６の作業負荷は平準化していない。
【００５８】
したがって、ディスパッチャ１５０は、ローカル実行キュー５７４と５７２用のロックを獲得し、ローカル実行キュー５７４にある第１の未バインドのスレッドをスチールして、それをローカル実行キュー５７２に配置する。２つのローカル実行キュー５７２と５７４を同時に保持しなければならないことを避けるために、スチールしたスレッドを一時的にキューから出して、一時キュー（図示せず）に配置してもよい。この場合、次に、ローカル実行キュー５７４用のロックを解放したのち、ローカル実行キュー５７２用のロックを獲得する。次いで、上記スレッドをローカル実行キュー５７２に入れる。
【００５９】
〔飢餓状態負荷平準化〕
飢餓状態負荷平準化は、所定の期間内にディスパッチされていない未バインドのスレッドをグローバル実行キューに移動させることを指向している。このように、ローカル実行キューにあるディスパッチされていないスレッドが、それらをディスパッチすることのできるＣＰＵ用のローカル実行キューに割り当てられることになる公算が大きい場合、当該ディスパッチされていないスレッドを、ローカル実行キューからグローバル実行キューに移動させる。
【００６０】
飢餓状態負荷平準化法によると、各スレッドは、ローカル実行キューに割り当てられたときにタイムスタンプを押される。周期的な時間間隔で、ディスパッチャ１５０は、システム内の各スレッドを走査して、しきい値時間よりも長い間、たとえば１．５秒よりも長い間、ローカル実行キューで未定のままでいる未バインドのスレッドを見つける。ディスパッチャ１５０が、この基準を満たす未バインドのスレッドを見つけると、ディスパッチャ１５０は、ローカル実行キューから当該スレッドをスチールして、それをノード用のグローバル実行キューに配置する。
【００６１】
このように、上記スレッドは、優先順位が許すかぎり、ノード内の次に使用可能なＣＰＵがディスパッチすることになる。したがって、あるローカル実行キュー内に優先順位の高いスレッド群があるためにディスパッチされえない優先順位の低いスレッドを、あまり忙しくないローカル実行キューに入れて、ディスパッチされる公算を大きくすることができる。
【００６２】
さらに、ディスパッチされていないスレッドをグローバル実行キューに移動させることにより、負荷平準化が望みの効果を達成しうる公算が大きくなる。たとえば、あるローカル実行キューがディスパッチされていないスレッドを大量に保有している場合、本来別のローカル実行キューに配置すべきスレッドが負荷平準化により誤ってディスパッチされてしまう、ということが起こりがちになる。ディスパッチされていないスレッドをグローバル実行キューに移動させることにより、スレッドのディスパッチがローカル実行キューの間に均一に分散されることになる。
【００６３】
飢餓状態負荷平準化の一例として、図６のノード６００を考える。図６に示すように、ローカル実行キュー６７１には、しきい値時間内にディスパッチされていない未バインドのスレッドがある。この未バインドのスレッドは、ディスパッチャ１５０がただ一回の操作で突き止める。それは、次のようにする。ディスパッチャ１５０は、システムのスレッドを走査し、各ローカル実行キュー６７１〜６７６内にあるスレッドであって、しきい値時間よりも長い間ローカル実行キューで未定のままでいることを示すタイムスタンプを有するスレッドを調べることにより、上記未バインドのスレッドを突き止める。
【００６４】
いったん未バインドのスレッドを突き止めると、ディスパッチャ１５０は、ローカル実行キュー６７１用のロックを獲得し、ローカル実行キュー６７１からスレッドをスチールし、それをグローバル実行キュー６８１に配置する。所定のスレッドの優先順位でスレッドの面倒を見るのを許されている次に使用可能なＣＰＵ６１０〜６６０が、上記スレッドをディスパッチすることになる。その後、上記スレッドは、ローカル実行キュー６７１〜６７６に割り当てることになる。
【００６５】
以上のように、本発明は、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を使用して、ＣＰＵ資源の間の最適な負荷平準化を達成している。このように、ＣＰＵ資源を平等に利用することができるので、システム全体のスループットを顕著に向上させることができる。
【００６６】
図７は、図１のディスパッチャ１５０の典型的なブロック図である。上述したように、ディスパッチャ１５０は、集中化した装置として描いてある。しかしながら、本発明は、たとえば各ノードまたはノードのグループが関連する独立したディスパッチャ１５０を備えた分散ディスパッチャ１５０を使って実現することもできる。
【００６７】
さらに、各ＣＰＵが、関連するディスパッチャ１５０を備えることもできる。そのような実施形態では、ある負荷平準化機能は各ＣＰＵのディスパッチャ１５０が実行することができるが、一方、残りの負荷平準化機能はディスパッチャ１５０のうちの特定のものしか実行することができない。たとえば、各ＣＰＵに関連付けられた各ディスパッチャ１５０は、ＣＰＵがアイドル状態になるとアイドル状態負荷平準化を実行することができるが、一方、１つのノードに存在する１つのマスタＣＰＵ（通常は最も小さな番号が付与されたＣＰＵ）に関連付けられたディスパッチャ１５０しか、周期的負荷平準化と飢餓状態負荷平準化を実行することができない。
【００６８】
図７に示すように、ディスパッチャ１５０は、コントローラ７００、メモリ７１０、初期負荷平準化装置７３０、アイドル状態負荷平準化装置７４０、周期的負荷平準化装置７５０、および飢餓状態負荷平準化装置７６０を備えている。これらの構成要素７００〜７６０は、信号／制御バス７７０を介して互いに交信している。図７ではバス・アーキテクチャを示したけれども、本発明は、このようなアーキテクチャに限定されない。むしろ、構成要素７００〜７６０の間の通信を考慮に入れたアーキテクチャであれば、どのようなものであっても、それは本発明の本旨と範囲の内のものである。
【００６９】
コントローラ７００は、たとえばメモリ７１０に格納されている制御プログラムに基づいてディスパッチャ１５０の動作を制御する。コントローラ７００は、ＭＰシステム・インタフェース７２０を介してノードとの間で情報を送受信する。ＭＰシステム１００でプロセスが新たなスレッドを生成すると、コントローラ７００は、初期負荷平準化装置７３０を使い上述した方法で初期負荷平準化を実行する。ノードのＣＰＵがアイドル状態になろうとしているという情報を、ノードから受信すると、コントローラ７００は、アイドル状態負荷平準化装置７４０を使い上述した方法でアイドル状態初期負荷平準化を実行する。コントローラ７００は、周期的負荷平準化装置７５０を使い上述した方法で周期的負荷平準化を実行する。コントローラ７００は、飢餓状態負荷平準化装置７６０を使い上述した方法で飢餓状態負荷平準化を実行する。
【００７０】
初期負荷平準化装置７３０、アイドル状態負荷平準化装置７４０、周期的負荷平準化装置７５０、および飢餓状態負荷平準化装置７６０としては、たとえば、プログラムされたマイクロプロセッサ装置（またはプログラムされたマイクロコントローラと周辺集積回路装置）、ＡＳＩＣ（Application Specific Integrated Circuit)などの集積回路装置、個別素子回路などのハードウェア電子（すなわち論理）回路、プログラマブル論理素子（ＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬなど）を用いることができる。要するに、上述し、かつ、後述する図８〜図１１のフローチャートで説明する機能を実行することのできる装置は、すべて、本発明の本旨と範囲の内で使用することができる。
【００７１】
図８は、初期負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。操作は、ＣＰＵがディスパッチすべき新たなスレッドをコントローラ７００が受け取ることにより開始する（ステップ８１０）。
【００７２】
次いで、コントローラ７００は、新たなスレッドが未バインドのスレッドであるかバインド済みのスレッドであるかを判断する（ステップ８２０）。これは、新たなスレッドが特定のＣＰＵにバインド済みであるか、あるいは未バインドであるかを示す、当該新たなスレッドに関連付けられた属性情報を読み取ることにより実行することができる。新たなスレッドがバインド済みの場合（ステップ８２０：ＹＥＳ）、コントローラ７００は、当該新たなスレッドをバインドされたＣＰＵに関連付けられたローカル実行キューに配置する（ステップ８３０）。新たなスレッドが未バインドの場合（ステップ８２０：ＮＯ）、コントローラ７００は、初期負荷平準化装置７３０に命じて初期負荷平準化を実行させる。初期負荷平準化装置７３０は、新たなスレッドが既存のプロセスの一部であるか否かを判断する（ステップ８４０）。これも、新たなスレッドに関連付けられた属性情報を読み取ることにより実行することができる。
【００７３】
新たなスレッドが既存のプロセスの一部である場合（ステップ８４０：ＹＥＳ）、初期負荷平準化装置７３０は、当該既存のプロセスの残りのスレッドが割り当てられていたノードのＣＰＵ群に対するラウンド・ロビン検索を実行して（ステップ８５０）アイドル状態のＣＰＵを探す。新たなスレッドが既存のプロセスの一部でない場合（ステップ８４０：ＮＯ）、初期負荷平準化装置７３０は、アイドル状態のＣＰＵを求めてすべてのノードとＣＰＵに対するラウンド・ロビン検索を実行する（ステップ８６０）。
【００７４】
初期負荷平準化装置７３０は、アイドル状態のＣＰＵが見つかったか否かを判断し（ステップ８７０）、もし見つかっていれば、そのアイドル状態のＣＰＵのローカル実行キューに新たなスレッドを配置する（ステップ８９０）。アイドル状態のＣＰＵが見つかっていなければ、初期負荷平準化装置７３０は、新たなスレッドをグローバル実行キューに配置する（ステップ８８０）。新たなスレッドが既存のプロセスの一部である場合、新たなスレッが付加されるグローバル実行キューは、当該既存のプロセスの残りのスレッド（あるいは現在のスレッドを生成したスレッド）が割り当てられていたノード用のグローバル実行キューである。新たなスレッドが既存のプロセスの一部でない場合、新たなスレッドが付加されるグローバル実行キューは、たとえばラウンド・ロビン検索に基づいて選考されたグローバル実行キューである。（ただし、ラウンド・ロビン検索の代わりに、別の負荷配置手法を使うこともできる）。このグローバル実行キューは、保有するスレッドの数が最も少ないノード、すなわち最も負荷が少ないノードに関連付けられたグローバル実行キューである。
【００７５】
図９は、アイドル状態負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図９に示すように、操作は、コントローラ７００がアイドル状態負荷平準化装置７４０に命じてアイドル状態負荷平準化を実行させたときに開始する。
【００７６】
したがって、アイドル状態負荷平準化装置７４０は、潜在的アイドル状態のＣＰＵのノードのローカル実行キューを走査して、上述したアイドル状態負荷平準化基準を満たすローカル実行キューを探す（ステップ９１０）。アイドル状態負荷平準化基準を満たすローカル実行キューが見つかった場合（ステップ９２０：ＹＥＳ）、アイドル状態負荷平準化装置７４０は、アイドル状態負荷平準化基準を満たすローカル実行キューからスレッドをスチールする（ステップ９４０）。アイドル状態負荷平準化基準を満たすローカル実行キューが見つからない場合（ステップ９２０：ＮＯ）、アイドル状態負荷平準化装置７４０は、ＣＰＵがアイドル状態になるのに任せる（ステップ９３０）。
【００７７】
図１０は、周期的負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図１０に示すように、操作は、コントローラ７００が周期的負荷平準化装置７５０に命じて周期的負荷平準化を実行させたときに開始する（ステップ１０１０）。
これは、たとえば周期的な操作タイミングに基づいて実行することができる。
【００７８】
周期的負荷平準化装置７５０は、最重量負荷ローカル実行キューと最軽量負荷ローカル実行キューを特定する（ステップ１０２０）。次いで、周期的負荷平準化装置７５０は、最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けているか否かを判断する（ステップ１０３０）。これは、最軽量負荷ローカル実行キューに相当する内部構造のフラグの現在の設定を判定することにより実行することができる。
【００７９】
最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けている場合（ステップ１０３０：ＹＥＳ）、周期的負荷平準化は実行しない（ステップ１０７０）。
【００８０】
最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けていない場合（ステップ１０３０：ＮＯ）、周期的負荷平準化装置７５０は、これら最重量負荷ローカル実行キュー用の負荷因数と最軽量負荷ローカル実行キュー用の負荷因数を算出したのち（ステップ１０４０）、これら負荷因数の差を算出し（ステップ１０５０）、その差がしきい値よりも大きいか否かを判断する（ステップ１０６０）。
【００８１】
上記負荷因数間の差がしきい値よりも大きい場合（ステップ１０６０：ＹＥＳ）、周期的負荷平準化装置７５０は、最重量負荷ローカル実行キューから未バインドのスレッドをスチールして、それを最軽量負荷ローカル実行キューに配置する（ステップ１０７０）。上記負荷因数間の差がしきい値よりも大きくない場合（ステップ１０６０：ＮＯ）、システムは良好に負荷平準化されているので、負荷平準化は実行しない。
【００８２】
図１１は、飢餓状態負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図１１に示すように、操作は、コントローラ７００が飢餓状態負荷平準化装置７６０に命じて飢餓状態負荷平準化を実行させたときに開始する（ステップ１１１０）。これは、たとえば周期的な操作タイミングに基づいて実行することができる。
【００８３】
飢餓状態負荷平準化装置７６０は、システム内の各スレッドを走査して未バインドのスレッドがないかどうか調べる（ステップ１１２０）。飢餓状態負荷平準化装置７６０は、未バインドのスレッド用のタイムスタンプを識別し（ステップ１１３０）、そのタイムスタンプが当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいるか否かを判断する（ステップ１１４０）。
【００８４】
当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいる場合（ステップ１１４０：ＹＥＳ）、当該未バインドのスレッドを、当該未バインドのスレッドのローカル実行キューを含んでいるノードのグローバル実行キューに入れる。当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいなかった場合（ステップ１１４０：ＮＯ）、当該未バインドのスレッドは、当該未バインドのスレッドのローカル実行キューに残置する。次いで、飢餓状態負荷平準化装置７６０は、検索すべきスレッドが他にあるか否かを判断する（ステップ１１６０）。検索すべきスレッドが他にもある場合（ステップ１１６０：ＹＥＳ）、飢餓状態負荷平準化装置７６０は、上述した操作を繰り返して実行する（ステップ１１２０〜１１６０）。検索すべきスレッドがもはや存在しない場合（ステップ１１６０：ＮＯ）、操作は終了する。
【００８５】
本発明によれば、グローバル実行キューとローカル実行キューとの双方を使うことにより、多重実行キュー・システムにおいて負荷平準化を行なうことができる。本発明によれば、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を互いに協働して実行することにより、ローカル実行キュー群間の最適な負荷平準化を実現することができる。
【００８６】
〔固定優先順位スレッド〕
ある条件下では、スレッドを固定した優先順位の順番でディスパッチする必要がある。たとえば、ＡＩＸ（Advanced Interactive eXective)オペレーティング・システムにおいて、ＰＯＳＩＸ（portable operating system interface for computer environments)準拠のプロセスでは、優先順位に厳格な順番でスレッドをディスパッチする必要がある。（ＡＩＸとはインターナショナル・ビジネス・マシーンズ・コーポレーション〔International Business Machines Corporation 〕が独自に開発したＵＮＩＸ（Ｒ）オペレーティング・システムの１つのバージョンのことである。ＰＯＳＩＸとは米国電気電子学会〔ＩＥＥＥ〕委員会がＵＮＩＸ（Ｒ）をベースに策定している移植性の高いＯＳインタフェース仕様のことである）。優先順位に厳格な順番でスレッドをディスパッチするには、すべてのスレッドを単一のＣＰＵにディスパッチする必要があるので、従来技術の多重実行キュー・システムなど多重実行キュー・システムでは、優先順位に厳格な順番でスレッドをディスパッチすることは、実行できない。
【００８７】
本発明は、この課題を、ＰＯＳＩＸ準拠の固定優先順位スレッドなどすべての固定優先順位スレッドを、たとえばＭＰシステム１１０の第１のノード１２０用のグローバル実行キューに割り当てることにより、解決している。このように、本発明では、固定優先順位スレッドは、複数のローカル実行キューに分散しておらず、単一のグローバル実行キューに存在しているので、優先順位に厳格な順番でディスパッチされることが保証されている。
【００８８】
ＣＰＵは、所定優先順位のスレッドをディスパッチできるようになると、グローバル実行キュー中の次順位のスレッドをディスパッチすることになるので、固定優先順位スレッドをグローバル実行キューに自動的に割り当てると、キャッシュとの類似性によって得られる利点がなくなってしまう。これを避けるために、キャッシュとの類似性がありうる点は無視して、固定優先順位スレッドは、使用可能になった任意のＣＰＵにまず割り当てる。しかしながら、固定優先順位スレッドを優先順位に厳格な順番でディスパッチすることの利点、および、次に使用可能なった任意のＣＰＵが固定優先順位スレッドをディスパッチする利点によって、キャッシュとの類似性が失われた点を埋め合わすことができる。これは、固定優先順位スレッドは非常に恵まれたスレッドであるので、それらはできるだけ早く実行するのが望ましい、ということを根拠にしている。
【００８９】
固定優先順位スレッドを識別するために、固定優先順位スレッドは、固定優先順位フラグを含む属性情報を備えている。固定優先順位フラグは、たとえばＰＯＳＩＸ準拠のフラグであり、固定優先順位スレッドが固定優先順位スレッドとして扱われるときにセットする（「１」にする）。あるスレッドにこの固定優先順位フラグがセットされていると、ディスパッチャ１５０は、そのスレッドを固定優先順位スレッドとしてＭＰシステム１１０の第１のノード１２０用のグローバル実行キューに割り当てる。次いで、各ＣＰＵはグローバル実行キューの面倒を見ているから、上記ノード１２０に関連付けられているＣＰＵは、自分がスレッドをディスパッチできるようになると、上記固定優先順位スレッドを優先順位に厳格な順番でディスパッチすることができる。このように、本発明による多重実行キュー・システムで、ＰＯＳＩＸ準拠のスレッドなどの固定優先順位スレッドを利用することが可能になる。
【００９０】
留意すべき重要な点として、完全に機能するデータ処理システムの文脈で本発明を説明したけれども、本発明の方法は命令を記録したコンピュータ読み取り可能な媒体など様々な形態で頒布することができるとともに、本発明は頒布するのに実際に使用されている特定の種類の信号搬送媒体とは無関係に等しく適用することができる、ということを当業者は認識できる。コンピュータ読み取り可能な媒体の例には、フロッピー（Ｒ）・ディスク、ハード・ディスク駆動装置、ＲＡＭ、ＣＤ−ＲＯＭなどの記録型媒体、ならびに、ディジタルおよびアナログの通信リンクなどの伝送型媒体がある。
【００９１】
上述した本発明の説明は、説明および記述のために行なったものであり、本発明を開示した形態のものに限定することを意図していない。多くの変更および変形は、当業者にとって自明である。実施形態は、本発明の原理および実際の適用を最もうまく説明するために、ならびに、当業者が考えうる特定の用途に適合するように様々な変更を加えた様々な実施形態について本発明を理解しうるように、選んだ。
【００９２】
まとめとして以下の事項を開示する。
（１）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる方法であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断するステップと、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てるステップと、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てるステップとを備えた方法。
（２）アイドル状態のプロセッサがあるか否かを判断するステップが、
前記複数のローカル実行キューのラウンド・ロビン検索を実行するステップ
を備えている、
上記（１）に記載の方法。
（３）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索の実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（２）に記載の方法。
（４）前記割り当てるスレッドが未バインドのスレッドである、
上記（３）に記載の方法。
（５）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（２）に記載の方法。
（６）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
スレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（１）に記載の方法。
（７）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（６）に記載の方法。
（８）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる、コンピュータ読み取り可能な媒体を使ったコンピューター・プログラム製品であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断する第１の命令群と、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てる第２の命令群と、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てる第３の命令群と
を備えたコンピューター・プログラム製品。
（９）前記第１の命令群が、
前記複数のローカル実行キューのラウンド・ロビン検索を実行する命令群
を含んでいる、
上記（８）に記載のコンピューター・プログラム製品。
（１０）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（９）に記載のコンピューター・プログラム製品。
（１１）前記割り当てるスレッドが未バインドのスレッドである、
上記（１０）に記載のコンピューター・プログラム製品。
（１２）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（９）に記載のコンピューター・プログラム製品。
（１３）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
スレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（８）に記載のコンピューター・プログラム製品。
（１４）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（１３）に記載のコンピューター・プログラム製品。
（１５）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる装置であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断する判断手段と、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てる第１の割り当て手段と、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てる第２の割り当て手段と
を備えた装置。
（１６）前記判断手段が、
アイドル状態のプロセッサがあるか否かを、前記複数のローカル実行キューのラウンド・ロビン検索を実行することにより判断する、
上記（１５）に記載の装置。
（１７）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記判断手段は、
前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始して前記ラウンド・ロビン検索を実行する、
上記（１６）に記載の装置。
（１８）前記割り当てるスレッドが未バインドのスレッドである、
上記（１７）に記載の装置。
（１９）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（１６）に記載の装置。
（２０）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
前記第２の割り当て手段によってスレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（１５）に記載の装置。
（２１）前記第２の割り当て手段は、
あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであると判断する、
上記（２０）に記載の装置。
（２２）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる方法であって、
割り当てるスレッドが未バインドであるかバインド済みであるかを判断するステップと、
割り当てるスレッドがバインド済みである場合、当該スレッドを、当該スレッドがバインドされているローカル実行キューに割り当てるステップと、
割り当てるスレッドが未バインドである場合、初期負荷平準化を実行して、当該スレッドを、前記複数のローカル実行キューのうちの１つのローカル実行キュー、または、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューに割り当てるステップと
を備えた方法。
（２３）前記初期負荷平準化が、
前記複数のローカル実行キューを検索して空のローカル実行キューを見つけるステップと、
空のローカル実行キューが見つかった場合、前記割り当てるスレッドを当該空のローカル実行キューに割り当てるステップと
を備えている、
上記（２２）に記載の方法。
（２４）前記初期負荷平準化が、さらに、
空のローカル実行キューが見つからなかった場合、前記割り当てるスレッドを前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューに割り当てるステップ
を備えている、
上記（２３）に記載の方法。
（２５）前記複数のローカル実行キューを検索して空のローカル実行キューを見つける前記ステップが、
前記複数のローカル実行キューのラウンド・ロビン検索を実行するステップ
を備えている、
上記（２３）に記載の方法。
（２６）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索の実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（２５）に記載の方法。
（２７）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
前記割り当てるスレッドを、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきであると判断したグローバル実行キューに割り当てる、
上記（２２）に記載の方法。
（２８）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（２７）に記載の方法。
【図面の簡単な説明】
【図１】 多重実行キュー・システムの典型的なブロック図である。
【図２】 初期負荷平準化法を説明する、多重実行キュー・システムの典型的なブロック図である。
【図３】 アイドル状態のプロセッサが見つからないときにおける初期負荷平準化法を説明する、多重実行キュー・システムの典型的なブロック図である。
【図４】 アイドル状態負荷平準化法を説明する、あるノードの典型例を示す図である。
【図５】 周期的負荷平準化法を説明する、あるノードの典型例を示す図である。
【図６】 飢餓状態負荷平準化法を説明する、あるノードの典型例を示す図である。
【図７】 図１のディスパッチャの典型的なブロック図である。
【図８】 初期負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図９】 アイドル状態負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図１０】 周期的負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図１１】 飢餓状態負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【符号の説明】
１００…多重キュー・システム、１１０…多重プロセッサ（ＭＰ）システム、１１１…ＣＰＵ、１１２…ＣＰＵ、１１３…ＣＰＵ、１１４…ＣＰＵ、１１５…ＣＰＵ、１１６…ＣＰＵ、１１７…ＣＰＵ、１２０…ノード、１３０…ノード、１４０…ノード、１５０…ディスパッチャ、２００…多重実行キュー・システム、２０５…ＭＰシステム、２２０…ノード、２２１…グローバル実行キュー、２２２…グローバル実行キュー、２２３…グローバル実行キュー、２２４…ノード、２２５…ノード、２３０…ＣＰＵ、２４０…ＣＰＵ、２５０…ＣＰＵ、２６０…ＣＰＵ、２７０…ＣＰＵ、２８０…ＣＰＵ、２９１…ローカル実行キュー、２９２…ローカル実行キュー、２９３…ローカル実行キュー、２９４…ローカル実行キュー、２９５…ローカル実行キュー、２９６…ローカル実行キュー、４００…ノード、４１０…ＣＰＵ、４２０…ＣＰＵ、４３０…ＣＰＵ、４４０…ＣＰＵ、４５０…ＣＰＵ、４６０…ＣＰＵ、４７１…ローカル実行キュー、４７２…ローカル実行キュー、４７３…ローカル実行キュー、４７４…ローカル実行キュー、４７５…ローカル実行キュー、４７６…ローカル実行キュー、５００…ノード、５１０…ＣＰＵ、５２０…ＣＰＵ、５３０…ＣＰＵ、５４０…ＣＰＵ、５５０…ＣＰＵ、５６０…ＣＰＵ、５７１…ローカル実行キュー、５７２…ローカル実行キュー、５７３…ローカル実行キュー、５７４…ローカル実行キュー、５７５…ローカル実行キュー、５７６…ローカル実行キュー、６００…ノード、６１０…ＣＰＵ、６２０…ＣＰＵ、６３０…ＣＰＵ、６４０…ＣＰＵ、６５０…ＣＰＵ、６６０…ＣＰＵ、６７１…ローカル実行キュー、６７２…ローカル実行キュー、６７３…ローカル実行キュー、６７４…ローカル実行キュー、６７５…ローカル実行キュー、６７６…ローカル実行キュー、６８１…グローバル実行キュー、７００…コントローラ、７１０…メモリ、７２０…ＭＰシステム・インタフェース、７３０…初期負荷平準化装置、７４０…アイドル状態負荷平準化装置、７５０…周期的負荷平準化装置、７６０…飢餓状態負荷平準化装置、７７０…信号／制御バス。
【発明の属する技術分野】
本発明は、多重プロセッサ・システムに関する。本発明は、特に、多重実行キュー・システムにおいて負荷平準化（load balancing: ロード・バランシング）を行なう方法と装置に関する。
【０００２】
【従来の技術】
多重プロセッサ（multiple processor: 多重処理装置）システムは、一般に、当技術分野では公知である。プロセスは、並行して処理することのできる複数のスレッドに分解される。しかしながら、スレッドは、プロセッサが実行できる状態になるまで、多重プロセッサ・システムの各プロセッサごとにキュー（queue:待ち行列）に入れる必要がある。
【０００３】
多重プロセッサ・システム中の１つのプロセッサがディスパッチすべきスレッドをキューに入れる公知の手法の１つに、単一の集中化したキュー、すなわち単一の集中化した「実行キュー（run queue)」を保持するものがある（「ディスパッチする」とは、実行の準備ができているスレッドに対してプロセッサ時間を割り当てることである）。プロセッサは、自らが使用可能になると、実行キューから次のスレッドを取り出して、それを処理する。ところが、集中化した実行キューから次のスレッドを取り出すのを待つ間に、プロセッサが実行キューのロックの上で空転する、すなわちアイドルになるのに起因して、スレッドと処理時間が失われる可能性がある。したがって、この手法の欠点は、集中化した実行キューがボトルネック（障害）になってしまう、という点である。
【０００４】
スレッドを実行キューに入れる別の公知の手法は、各プロセッサごとに独立した実行キューを保持することである。この場合、スレッドが生成されると、それは、ラウンド・ロビン方式（総当たり方式）でプロセッサに割り当てられる。しかしながら、このような手法では、過負荷になるプロセッサがある一方、比較的アイドルなプロセッサがある、という状態になる。さらに、優先順位の低いスレッドが待っている対象のプロセッサの実行キューに優先順位の高いスレッドが付加されることになるので、優先順位の低いスレッドの中には、飢餓状態、すなわち処理時間が全く与えられない状態になるものが出てくる。
【０００５】
上述したことから、多重プロセッサ・システムにおいて、高スループットを維持しながら、各プロセッサにかかる作業負荷を平準化する方法と装置を提供する新たな技術が求められている。さらに、複数の実行キューの間における作業負荷の初期負荷平準化を実現する新たな技術が求められている。
【０００６】
【課題を解決するための手段】
本発明は、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を実行して、システムの各プロセッサにかかる作業負荷が最適に平準化されるのを保証する方法と装置を提供する。初期負荷平準化は、プロセスの新たなスレッドをどの実行キューに割り当てるべきであるかを扱う。アイドル状態負荷平準化は、プロセッサがアイドル状態になり始めているときに、スレッドをある実行キューから別の実行キューに移動させる仕方を扱う。周期的負荷平準化は、負荷平準化を維持するために、スレッドを最重量負荷実行キューから最軽量負荷実行キューへ移動させる仕方を扱う。飢餓状態負荷平準化は、プロセッサ時間に飢えているスレッドが入っている実行キューを入れ換える仕方を扱う。
【０００７】
これらの手法は、グローバル実行キューとローカル実行キューを使って、負荷平準化を実行している。グローバル実行キューは、当該グローバル実行キューの面倒を見ているプロセッサのノードに関連付けられている。このノード内の各プロセッサは、ローカル実行キューの面倒も見ている。したがって、１つのノード内の各プロセッサは、グローバル実行キューとローカル実行キューとの双方の面倒を見ている。
【０００８】
初期負荷平準化は、グローバル実行キューを使って、アイドル状態のプロセッサのローカル実行キューに直接に配置できないスレッドを配置する。飢餓状態負荷平準化は、プロセッサ時間に飢えているスレッドをあまり忙しくないプロセッサがディスパッチできる公算を大きくするために、グローバル実行キューを使って、プロセッサ時間に飢えているスレッドを配置する。
【０００９】
アイドル状態負荷平準化と周期的負荷平準化は、システムのプロセッサの作業負荷を平準化させる過程で、スレッドをあるローカル実行キューから別のローカル実行キューへ移動させようとする。
【００１０】
【発明の実施の形態】
図１は、本発明を実現することのできる多重キュー・システム１００の典型例を示す図である。図１に示すように、多重キュー・システム１００は、多重プロセッサ（multiple processor: ＭＰ）システム１１０、組織化されてノード１２０〜１４０を形成している複数のＣＰＵ（central processing unit:中央処理装置）１１１〜１１７、およびディスパッチャ１５０を備えている（ディスパッチャとは、ＣＰＵがスレッドを実行するときの実行順序を管理する、オペレーティング・システムの機能単位〔ルーチン〕のことである）。
【００１１】
ＭＰシステム１１０は、複数のプロセッサ、たとえばＣＰＵ１１１〜１１７を備えていれば、どのような種類のシステムであってもよい。ＣＰＵ１１１〜１１７は、割り当てられた処理ジョブを処理することのできる処理装置であれば、どのような種類の処理装置であってもよい。ＣＰＵ１１１〜１１７は、組織化されてノード１２０〜１４０を形成している。ノード１２０〜１４０は、本来、実際の装置でなくてもよいが、しかし、グループ分けされたＣＰＵ１１１〜１１７の各グループを代表していると見なしうるものである。したがって、たとえば、ＣＰＵ１１１と１１２はノード１２０に関連付けられており、ＣＰＵ１１３と１１４はノード１３０に含まれており、ＣＰＵ１１５〜１１７はノード１４０に含まれている。
【００１２】
ディスパッチャ１５０は、ノード１２０〜１４０とＣＰＵ１１１〜１１７との間におけるジョブの負荷平準化を実行する。図１ではディスパッチャ１５０を集中化した単一の装置として示してあるけれども、ディスパッチャ１５０は、ＭＰシステム１１０全体に分布していてもよい。たとえば、各ノード１２０〜１４０、あるいはノード１２０〜１４０から成る各グループに独立したディスパッチャ１５０が関連付けられるように、ディスパッチャ１５０は、分散させることができる。さらに、ＭＰシステム１１０の各ＣＰＵ１１１〜１１７上で実行されるソフトウェアの命令としてディスパッチャ１５０を実現することもできる。
【００１３】
各ＣＰＵ１１１〜１１７は関連付けられたローカル実行キューを備えており、各ノード１２０〜１４０は関連付けられたグローバル実行キューを備えている。したがって、各ＣＰＵ１１１〜１１７は単一のローカル実行キューの面倒を見ており、各ノード１２０〜１４０に属す各ＣＰＵ１１１〜１１７は自らが属すノード用のグローバル実行キューの面倒を見ている。たとえば、ＣＰＵ１１１と１１２との双方は、ノード１２０に関連付けられたグローバル実行キューの面倒を見ている。
【００１４】
好適な実施形態では、ＣＰＵ１１１〜１１７とローカル実行キューとの間に１対１の対応関係があるけれども、本発明は、このような実施形態に限定されない。むしろ、ローカル実行キューは、ノードに属す複数のＣＰＵが共有することができる。したがって、たとえば、ＣＰＵ１１５と１１６が単一のロ第１のーカル実行キューを共用している一方で、ＣＰＵ１１７が第２のローカル実行キューを単独で使用するようにすることが可能である。
【００１５】
グローバル実行キューとローカル実行キューには、スレッドが格納されている。スレッドとは、マルチスレッド環境における個々のトランザクションのことである。マルチスレッド環境とは、単一のプログラム内でマルチタスクを許す環境のことである。マルチスレッドによって、同じプログラム内で並行して実行される実行の流れを多重化することが可能になる。各実行の流れは、異なるトランザクションまたはメッセージを処理している。www.techweb.com を参照されたい。
【００１６】
あるノードのグローバル実行キューは、ＣＰＵが自分のスレッドの面倒を見るための、対応するローカル実行キューと競合する。グローバル実行キュー内に存在するスレッドとローカル実行キュー内に存在するスレッドとは、優先順位に基づいて、ＣＰＵの資源を求めて競争する。
【００１７】
（ローカルおよびグローバル）実行キューに存在するスレッドは、自分に関連付けられた優先順位をもつことができる。実行キューは、その実行キューに関し最も優先順位が高い待ち状態のスレッドの優先順位の情報を実行キュー構造の中に保持している。ディスパッチャ１５０は、この優先順位情報を使って、次にディスパッチすべきスレッドを検索すべき実行キューはどれであるかを判断する。
【００１８】
グローバル実行キューとローカル実行キューとの双方が同じ優先順位の待ち状態にあるスレッドをもっている場合、ディスパッチャ１５０は、一般に、「同点決戦の勝者（tie breaker)」としてローカル実行キューを選択してスレッドをディスパッチする。ローカル実行キュー上のスレッドはそれに割り当てられたＣＰＵだけしか面倒を見ないので、このような選考方法を使う。他方、グローバル実行キューは、ノードに割り当てられたＣＰＵのうちどれが面倒を見てもかまわない。
【００１９】
しかし、上記のようにローカル実行キューを選択した結果、ローカル実行キューを勝者とする「同点決戦（tie break)」が２回続く場合には、グローバル実行キューを選択する。その理由は、ローカル実行キューを無条件に選択することを繰り返すことによって生じるグローバル実行キューの飢餓状態（長時間の停止状態）を避けるためである。
【００２０】
スレッドをディスパッチするために（ローカルまたはグローバル）実行キューを選択するとき、ディスパッチャ１５０は、当該実行キューをロックしようとする。実行キューを「ロックする（locking)」、あるいは、「実行キューのロック（run queue's lock）」を獲得する、という用語は、ディスパッチャ１５０がスレッドをディスパッチしようとしている間に実行キューが変更されるのを防ぐために、当該実行キューに対するアクセスをディスパッチャ１５０が制限することを指している。
【００２１】
グローバル実行キューをロックしようとして、それが不成功だった場合、たとえば別のＣＰＵが当該実行キューを既にロックしていた場合、ディスパッチャ１５０は、当該実行キューをロックしようと再試行する代わりに、ローカル実行キューを選択し、それからスレッドをディスパッチしようとする。実行キューに対してロックしようと再試行することは、実行キュー上で「空転する（spinning）」と呼ばれている。
【００２２】
グローバル実行キューをロックしようとして、それが成功したが、しかし、いったんロックしたのに当該グローバル実行キューの中にスレッドが全く存在しない場合、ディスパッチャ１５０は、ローカル実行キューを選択し、それからスレッドをディスパッチャしようとする。ロックは成功したが、しかし、グローバル実行キュー内には予期した優先順位と異なる優先順位のスレッドしか存在しない場合、ディスパッチャ１５０は、とにかくそのスレッドをディスパッチする。
【００２３】
上述したようなスレッドは、「未バインド（unbound)」スレッドと呼ばれている。「未バインド」スレッドとは、特定のＣＰＵが処理する必要のないスレッドのことである。「バインド済み（bound)」スレッドとは、特定のＣＰＵまたはＣＰＵ群が処理すべきことを示す識別子を備えたスレッドのことである。あるスレッドが特定のＣＰＵにバインドされている場合、当該スレッドは、当該ＣＰＵが面倒を見ているローカル実行キューに入れる必要がある。
【００２４】
通常、未バインドのスレッドは、いったん所定のＣＰＵにディスパッチされると、当該ＣＰＵが面倒を見ているローカル実行キューに半永久的に関連付けられる。例外（exception)は、ＰＯＳＩＸ（Portable Operating System Interface for ＵＮＩＸ（Ｒ） ）のコンプライアンス・フラグがセットされて（１にされて）実行される未バインドの固定優先順位のスレッドである。下で詳述するように、これらのスレッドは、常に優先順位を互いに厳格に維持してディスパッチしうるように、グローバル実行キューに格納されている。
【００２５】
ディスパッチャ１５０が実行するノード１２０〜１４０とＣＰＵ１１１〜１１７との間における負荷平準化に基づいて、グローバル実行キューにスレッドを追加する。負荷平準化には、多重実行キュー・システム１００の様々な実行キューを等しく使用するようにする多数の方法がある。負荷平準化は、次の４つの部分から検討することができる。すなわち、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および、飢餓状態負荷平準化である。以下ではこれら４つの部分のおのおのを独立して扱う。しかし、ＭＰシステム１１０全体で最適な負荷平準化を実現するために、これら４つの部分は、互いに協働して実装（implement)するように意図されている。
【００２６】
〔初期負荷平準化〕
初期負荷平準化とは、スレッド群が新たに生成されたときに、実行キュー全体に当該新たなスレッド群の作業負荷を分散させることである。図２と図３は、初期負荷平準化法を説明する多重実行キュー・システム２００の典型例を示す図である。
【００２７】
図２に示すように、新たなプロセス（あるいはジョブ）の一部として未バインドの新たなスレッドＴｈ１３が生成されると、ディスパッチャ１５０は、そのスレッドをアイドル状態のＣＰＵに関連付けられた実行キューに配置しようとする。こうするために、ディスパッチャ１５０は、多重実行キュー・システム２００のＣＰＵ２３０〜２８０の間のラウンド・ロビン検索を実行する。アイドル状態のＣＰＵが見つかったら、新たなスレッドＴｈ１３は、当該アイドル状態のＣＰＵのローカル実行キューに付加される。
【００２８】
ラウンド・ロビン検索は、一連のノード／実行キューのうち、最後のスレッドが割り当てられたノード／実行キューの後ろのノード／実行キューから開始する。
このように、この方法は、すべてのノードとＣＰＵ全体にスレッドを分散させながら、新たなプロセスの新たなスレッドをアイドル状態のＣＰＵに割り当てる。
【００２９】
以上のことから、図２に示す多重実行キュー・システム２００にラウンド・ロビン手法を適用して、新たなスレッドＴｈ１３は、アイドル状態のＣＰＵ２４０に関連付けられたローカル実行キュー２９２に割り当てる。新たなスレッドが次に生成されると、アイドル状態のＣＰＵを求めるラウンド・ロビン検索は、ＣＰＵ２５０とローカル実行キュー２９３から開始し、ＣＰＵ２６０〜２４０、およびノード２２０、２２４、２２５のローカル実行キュー２９４〜２９２を、アイドル状態のＣＰＵが見つかるまで、あるいは、ＣＰＵ／実行キューのおのおのを検索し終えるまで、総当たりする。
【００３０】
既存のプロセスの一部として未バインドのスレッドが生成されると、ディスパッチャ１５０は、この場合も、アイドル状態のＣＰＵがあればそれに当該未バインドのスレッドを配置しようとする。しかし、検索するＣＰＵと対応するローカル実行キューは、上記既存のプロセスのスレッドが割り当てられていたノードに関連付けられたものに限定する。複数のノードにわたってアドレス空間を共有するのは非効率なので、検索をこのように限定する。
【００３１】
したがって、たとえば、未バインドの新たなスレッドＴｈ１３が、スレッドＴｈ９が属すプロセスの一部をなすスレッドである場合、アイドル状態のＣＰＵを求めるラウンド・ロビン検索は、ノード２２４およびＣＰＵ２５０、２６０に限定する。図２の場合、ＣＰＵ２５０とＣＰＵ２６０はどちらもアイドル状態にないから、ＣＰＵ２５０およびＣＰＵ２６０の一方がスレッドＴｈ１３を処理するのに使用可能になるまで、スレッドＴｈ１３はグローバル実行キュー２２２に割り当てることになる。ＣＰＵ２５０およびＣＰＵ２６０の一方がスレッドＴｈ１３を処理するのに使用可能になったときには、スレッドＴｈ１３は、使用可能なＣＰＵ２５０または２６０のローカル実行キュー２９３または２９４に入れる。
【００３２】
図３に示すように、新たなスレッドＴｈ２０用に使用可能なＣＰＵが１つもない場合、スレッドＴｈ２０は、ラウンド・ロビン検索によって選考したグローバル実行キューに割り当てる。あるいは、スレッドＴｈ２０が新たなプロセスの新たなスレッドである場合、スレッドＴｈ２０は、最も空きの多い（すなわち最も少ししかロードされていない）ノードのグローバル実行キューに割り当てる。
【００３３】
図３に示す多重実行キュー・システム２００では、最も空きの多いグローバル実行キューは、グローバル実行キュー２２１である。スレッドＴｈ２０が既存のプロセスの新たなスレッドである場合、スレッドＴｈ２０は、上記既存のプロセスのスレッドが既に割り当てられているノード２２０、２２４、または２２６のグローバル実行キュー２２１〜２２３に割り当てる。
【００３４】
典型的な実施形態ではラウンド・ロビン検索を使用したけれども、本発明は、スレッドの割り当てに関し、ラウンド・ロビン検索に限定されない。むしろ、上述したラウンド・ロビン手法の代わりに、任意の負荷配置手法を使用することができる。
【００３５】
上述した初期負荷平準化法によれば、未バインドの新たなスレッドを現在アイドル状態にあるＣＰＵに割り当てることにより、あるいは、それらをグローバル実行キューに割り当てることにより、未バインドの新たなスレッドを迅速にディスパッチすることができる。グローバル実行キュー上のスレッドは、優先順位が許すかぎり、当該グローバル実行キューが属すノードで次に使用可能なＣＰＵにディスパッチする。
【００３６】
システム資源の平準化された利用を保証するために、初期負荷平準化のほかに、他の３つの方法、すなわちアイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を実行する。説明を明快にするために、これら３つの負荷平準化法は、単一のノードとそれに対応するＣＰＵに関して説明する。当業者にとって明らかになるように、これら３つの負荷平準化法は、本発明の本旨と範囲の内で、任意の数のノードとＣＰＵに適用することができる。
【００３７】
〔アイドル状態負荷平準化〕
アイドル状態負荷平準化は、それをしないとＣＰＵがアイドル状態になってしまうときに適用する。したがって、ディスパッチャ１５０（図１）は、作業負荷を他のＣＰＵから潜在的アイドル状態のＣＰＵ（放置するとアイドル状態になってしまうＣＰＵ）に移動させようとする。しかしながら、この移動プロセスは、スレッドにとってローカル実行キューが「キャッシュと類似している点（cache affinity）」を便宜的に考慮に入れている。
【００３８】
メモリ・キャッシュは、その速度がＣＰＵに近い暫定的な記憶装置である。メモリ・キャッシュは、命令実行速度を上げる「先読み（look-ahead）」機能を備えている。しかし、データは、キャッシュに数秒間あるいは数ミリ秒間しか留まることができない。
【００３９】
あるスレッド（あるいは同じプロセス起源の関連スレッド）がＣＰＵで以前に実行されていると、当該スレッドは、メモリ・キャッシュとの類似性を示すことがある。この「類似性（affinity）」は、ＣＰＵのキャッシュにはいくつかのデータが存在したままになっている可能性があるので、その既にキャッシュされているデータを使ってスレッドを迅速に処理することができる、という点にある。負荷平準化を実行しながら、このキャッシュとの類似性を考慮に入れるために、次に示すアイドル状態負荷平準化法を実行する。
【００４０】
あるＣＰＵがアイドル状態になろうとしている場合、ディスパッチャ１５０は、潜在的アイドル状態のＣＰＵで処理するノードに割り当てられている別の実行キューからスレッドを「スチール（steal)」しようとする。ディスパッチャ１５０は、潜在的アイドル状態のＣＰＵが割り当てられているノードのローカル実行キューを走査して、それらが次に示す基準を満たすローカル実行キューでないかどうか調べる。
（１）当該ローカル実行キューのスレッドの数は、当該ローカル実行キューが属すノードの全ローカル実行キューのうちで最大である。
（２）当該ローカル実行キューのスレッドの数は、当該ローカル実行キューが属すノードの現在のスチールしきい値（下で定義する）よりも大きい。
（３）当該ローカル実行キューには、少なくとも１つの未バインドのスレッドがある。
（４）現在のクロック・サイクルの間に、当該ローカル実行キューから最大スチールしきい値を超える数のスレッドがスチールされたことがない。
【００４１】
これらの基準を満たすローカル実行キューが見つかると、ディスパッチャ１５０は、当該ローカル実行キューから未バインドのスレッドをスチールしようとする。選択したローカル実行キューのロックを獲得したのちに、当該ローカル実行キューからスレッドをスチールする。選択したローカル実行キューのロックを直ぐに獲得できない場合、再試行は行なわない。
【００４２】
選択したローカル実行キューのロックを獲得したら、ディスパッチャ２５０は、未バインドのスレッドがまだ使用可能であり、最も優先順位の高い未バインドのスレッドを選択したことを確認する。スレッドのスチールは、当該スレッドのロックを獲得し、当該スレッドの実行キュー・ポインタを潜在的アイドル状態のＣＰＵに割り当てられているローカル実行キュー用の実行キュー・ポインタに変更することにより、行なう。ここでも、選択したスレッドのロックを直ぐに獲得できない場合、再試行は行なわない。
【００４３】
選択したスレッドのロックを獲得し、当該スレッドをスチールしたら、スチールしたスレッドは、直ぐにＣＰＵによって処理されるので、実際には、潜在的アイドル状態のＣＰＵのローカル実行キューに入れられることはない。典型的な動作を想定すると、スチールしたスレッドがディスパッチ・サイクルを完了すると、自然にこのようになっている。
【００４４】
アイドル状態負荷平準化は、対象とするノードのスチールしきい値によって束縛されている。スチールしきい値は、対象とするノードに属すすべてのローカル実行キューに対する平滑化平均負荷因数（smoothed average load factor）にある分数を乗じた数値である。この平滑化平均負荷因数は、クロック・サイクルごとに各ローカル実行キュー上のスレッドの数をサンプリングして決定する。
【００４５】
たとえば、ある期間におけるあるＣＰＵの負荷因数が５、１５、１６である場合、平滑化平均負荷因数は、１２になる（（５＋１５＋１６）÷３＝１２）。
たとえば、スチールしきい値＝（１／４）×平滑化平均負荷因数、である場合を想定すると、上記した例では、スチールしきい値＝（１／４）×１２＝３となる。スチールしきい値を算出する際に使用する分数（上記した例では１／４）は、実際には調整可能な数値である。したがって、スチールしきい値（上記した例では３）も調整可能な数値である。
【００４６】
したがって、スレッドのスチール元のローカル実行キューは、スチールしきい値を超える数のスレッドを保持している必要がある。上記した例では、スチールしきい値＝３であるから、スレッドのスチール元のスチール実行キューは、３個を超えるスレッドを保持している必要がある。そして、このうちの少なくとも１つは、未バインド、したがってスチール可能なスレッドでなければならない。また、上記ローカル実行キューは、すべてのローカル実行キューの中で最大個数のスレッドを保持していることも必要である。さらに、上記ローカル実行キューは、現在のクロック・サイクルの間に自分の中から最大個数のスレッドをスチールされていないことも必要である。
【００４７】
上述した方法の一例として、図４に示すノードを考える。図４に示すように、ＣＰＵ４２０がアイドル状態になろうとしており、それに関連付けられたローカル実行キュー４７２とグローバル実行キューには、スレッドが割り当てられていない。したがって、アイドル状態のＣＰＵ４２０は、別のローカル実行キュー４７１、４７３〜４７６からスレッドをスチールしようとする。
【００４８】
上述したスチール基準を考慮すると、上述した基準を満たすローカル実行キューは、ローカル実行キュー４７４である。これは、ローカル実行キュー４７４がすべてのローカル実行キュー４７１〜４７６の中で最も多い個数のスレッド（５個のスレッド）を保有しているからである。ローカル実行キュー４７４は、少なくとも１つの未バインドのスレッドを保有している（このように想定する）。ローカル実行キュー４７４は、スチールされうるスレッドの最大個数に達していない（これもこのように想定する）。
【００４９】
各ローカル実行キューの現在の作業負荷はローカル実行キュー群の平均負荷因数に等しいものとすると、ノード４００のスチールしきい値は現在約１であり、ローカル実行キュー４７４には５個のスレッドが割り当てられているから、ローカル実行キュー４７４が保有しているスレッドの個数は、当該ローカル実行キュー４７４が属すノードの現在のスチールしきい値よりも大きい。したがって、ローカル実行キュー４７４は、上述したスチール基準をすべて満たしている。それ故、ローカル実行キュー４７４中の第１の未バインドのスレッドをスチールして、その実行キュー・ポインタをローカル実行キュー４７２に再割り当てすることになる。
【００５０】
〔周期的負荷平準化〕
周期的負荷平準化は、Ｎクロック・サイクルごとに行なう。周期的負荷平準化は、アイドル状態負荷平準化と同様の方法で、１つのノードのローカル実行キューの作業負荷を平準化しようとするものである。しかしながら、周期的負荷平準化は、一般に、すべてのＣＰＵが１００％使用中であるときに行なう。
【００５１】
周期的負荷平準化には、割り当てられているスレッドの個数が平均して最も多いローカル実行キューと最も少ないローカル実行キューとを特定するために、１つのノードのローカル実行キューを走査することが含まれている。割り当てられているスレッドの個数が平均して最も多いローカル実行キューと最も少ないローカル実行キューとは、平均負荷が最も大きいローカル実行キューと平均負荷が最も小さいローカル実行キューのことであり、以下、これらを、それぞれ最重量ローカル実行キュー、最軽量ローカル実行キューと呼ぶ。
【００５２】
最後のＮクロック・サイクルでアイドル状態負荷平準化を通じて最軽量ローカル実行キューがスレッドをスチールした場合、周期的負荷平準化は行なわない。これは、周期的負荷平準化が、アイドル状態負荷平準化が行なわれておらず、かつ、すべてのノードのＣＰＵが使用中である状況を取り扱うことを指向しているからである。
【００５３】
最重量ローカル実行キューと最軽量ローカル実行キューとの間における負荷因数の差が所定のしきい値（たとえば１．５）以上の場合、周期的負荷平準化を行なう。上記の差がしきい値未満の場合、ＣＰＵの作業負荷は良好に平準化しているから、周期的負荷平準化を行なわない、と判断する。
【００５４】
周期的負荷平準化を行なうべき場合、ディスパッチャ１５０は、最重量ローカル実行キューのロックを獲得する。この場合、最重量ローカル実行キューのロックが直ぐに獲得できないときには、ディスパッチャ１５０は、最重量ローカル実行キューのロックを獲得する試行を繰り返す、すなわち、ディスパッチャ１５０は、最重量ローカル実行キューのロックの上で空転することになる。
【００５５】
いったん最重量ローカル実行キューのロックを獲得したら、ディスパッチャ１５０は、最重量ローカル実行キューを走査してスチールすべき未バインドのスレッドがないかどうか調べる。システム性能に影響を与えるのに十分なＣＰＵ時間を使うことになるスレッドをスチールする公算を高めるとともに、優先順位の高いスレッドを元のＣＰＵに委（ゆだ）ねるために、スチール可能な未バインドのスレッドを求める上記走査は、中くらいの優先順位のスレッドから開始する。次いで、上述したのと同じ方法で、該当するスレッドをスチールする。
【００５６】
周期的負荷平準化の一例として、図５に示すノード５００を考える。図５に示すように、各ＣＰＵ５１０〜５６０は、各自のローカル実行キュー５７１〜５７６にあるスレッドをディスパッチするのに忙しい。しかし、ＣＰＵ５１０〜５６０の間の作業負荷は、平準化していない。周期的負荷平準化では、最重量ローカル実行キューと最軽量ローカル実行キュー（この例の場合、ローカル実行キュー５７４と５７２）を見つける。
【００５７】
図５に示すように、最重量ローカル実行キュー５７４の負荷因数は４であり、最軽量ローカル実行キュー５７２の負荷因数は１である。負荷因数の間の差は、３であり、しきい値１．５よりも大きいから、ローカル実行キュー５７１〜５７６の作業負荷は平準化していない。
【００５８】
したがって、ディスパッチャ１５０は、ローカル実行キュー５７４と５７２用のロックを獲得し、ローカル実行キュー５７４にある第１の未バインドのスレッドをスチールして、それをローカル実行キュー５７２に配置する。２つのローカル実行キュー５７２と５７４を同時に保持しなければならないことを避けるために、スチールしたスレッドを一時的にキューから出して、一時キュー（図示せず）に配置してもよい。この場合、次に、ローカル実行キュー５７４用のロックを解放したのち、ローカル実行キュー５７２用のロックを獲得する。次いで、上記スレッドをローカル実行キュー５７２に入れる。
【００５９】
〔飢餓状態負荷平準化〕
飢餓状態負荷平準化は、所定の期間内にディスパッチされていない未バインドのスレッドをグローバル実行キューに移動させることを指向している。このように、ローカル実行キューにあるディスパッチされていないスレッドが、それらをディスパッチすることのできるＣＰＵ用のローカル実行キューに割り当てられることになる公算が大きい場合、当該ディスパッチされていないスレッドを、ローカル実行キューからグローバル実行キューに移動させる。
【００６０】
飢餓状態負荷平準化法によると、各スレッドは、ローカル実行キューに割り当てられたときにタイムスタンプを押される。周期的な時間間隔で、ディスパッチャ１５０は、システム内の各スレッドを走査して、しきい値時間よりも長い間、たとえば１．５秒よりも長い間、ローカル実行キューで未定のままでいる未バインドのスレッドを見つける。ディスパッチャ１５０が、この基準を満たす未バインドのスレッドを見つけると、ディスパッチャ１５０は、ローカル実行キューから当該スレッドをスチールして、それをノード用のグローバル実行キューに配置する。
【００６１】
このように、上記スレッドは、優先順位が許すかぎり、ノード内の次に使用可能なＣＰＵがディスパッチすることになる。したがって、あるローカル実行キュー内に優先順位の高いスレッド群があるためにディスパッチされえない優先順位の低いスレッドを、あまり忙しくないローカル実行キューに入れて、ディスパッチされる公算を大きくすることができる。
【００６２】
さらに、ディスパッチされていないスレッドをグローバル実行キューに移動させることにより、負荷平準化が望みの効果を達成しうる公算が大きくなる。たとえば、あるローカル実行キューがディスパッチされていないスレッドを大量に保有している場合、本来別のローカル実行キューに配置すべきスレッドが負荷平準化により誤ってディスパッチされてしまう、ということが起こりがちになる。ディスパッチされていないスレッドをグローバル実行キューに移動させることにより、スレッドのディスパッチがローカル実行キューの間に均一に分散されることになる。
【００６３】
飢餓状態負荷平準化の一例として、図６のノード６００を考える。図６に示すように、ローカル実行キュー６７１には、しきい値時間内にディスパッチされていない未バインドのスレッドがある。この未バインドのスレッドは、ディスパッチャ１５０がただ一回の操作で突き止める。それは、次のようにする。ディスパッチャ１５０は、システムのスレッドを走査し、各ローカル実行キュー６７１〜６７６内にあるスレッドであって、しきい値時間よりも長い間ローカル実行キューで未定のままでいることを示すタイムスタンプを有するスレッドを調べることにより、上記未バインドのスレッドを突き止める。
【００６４】
いったん未バインドのスレッドを突き止めると、ディスパッチャ１５０は、ローカル実行キュー６７１用のロックを獲得し、ローカル実行キュー６７１からスレッドをスチールし、それをグローバル実行キュー６８１に配置する。所定のスレッドの優先順位でスレッドの面倒を見るのを許されている次に使用可能なＣＰＵ６１０〜６６０が、上記スレッドをディスパッチすることになる。その後、上記スレッドは、ローカル実行キュー６７１〜６７６に割り当てることになる。
【００６５】
以上のように、本発明は、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を使用して、ＣＰＵ資源の間の最適な負荷平準化を達成している。このように、ＣＰＵ資源を平等に利用することができるので、システム全体のスループットを顕著に向上させることができる。
【００６６】
図７は、図１のディスパッチャ１５０の典型的なブロック図である。上述したように、ディスパッチャ１５０は、集中化した装置として描いてある。しかしながら、本発明は、たとえば各ノードまたはノードのグループが関連する独立したディスパッチャ１５０を備えた分散ディスパッチャ１５０を使って実現することもできる。
【００６７】
さらに、各ＣＰＵが、関連するディスパッチャ１５０を備えることもできる。そのような実施形態では、ある負荷平準化機能は各ＣＰＵのディスパッチャ１５０が実行することができるが、一方、残りの負荷平準化機能はディスパッチャ１５０のうちの特定のものしか実行することができない。たとえば、各ＣＰＵに関連付けられた各ディスパッチャ１５０は、ＣＰＵがアイドル状態になるとアイドル状態負荷平準化を実行することができるが、一方、１つのノードに存在する１つのマスタＣＰＵ（通常は最も小さな番号が付与されたＣＰＵ）に関連付けられたディスパッチャ１５０しか、周期的負荷平準化と飢餓状態負荷平準化を実行することができない。
【００６８】
図７に示すように、ディスパッチャ１５０は、コントローラ７００、メモリ７１０、初期負荷平準化装置７３０、アイドル状態負荷平準化装置７４０、周期的負荷平準化装置７５０、および飢餓状態負荷平準化装置７６０を備えている。これらの構成要素７００〜７６０は、信号／制御バス７７０を介して互いに交信している。図７ではバス・アーキテクチャを示したけれども、本発明は、このようなアーキテクチャに限定されない。むしろ、構成要素７００〜７６０の間の通信を考慮に入れたアーキテクチャであれば、どのようなものであっても、それは本発明の本旨と範囲の内のものである。
【００６９】
コントローラ７００は、たとえばメモリ７１０に格納されている制御プログラムに基づいてディスパッチャ１５０の動作を制御する。コントローラ７００は、ＭＰシステム・インタフェース７２０を介してノードとの間で情報を送受信する。ＭＰシステム１００でプロセスが新たなスレッドを生成すると、コントローラ７００は、初期負荷平準化装置７３０を使い上述した方法で初期負荷平準化を実行する。ノードのＣＰＵがアイドル状態になろうとしているという情報を、ノードから受信すると、コントローラ７００は、アイドル状態負荷平準化装置７４０を使い上述した方法でアイドル状態初期負荷平準化を実行する。コントローラ７００は、周期的負荷平準化装置７５０を使い上述した方法で周期的負荷平準化を実行する。コントローラ７００は、飢餓状態負荷平準化装置７６０を使い上述した方法で飢餓状態負荷平準化を実行する。
【００７０】
初期負荷平準化装置７３０、アイドル状態負荷平準化装置７４０、周期的負荷平準化装置７５０、および飢餓状態負荷平準化装置７６０としては、たとえば、プログラムされたマイクロプロセッサ装置（またはプログラムされたマイクロコントローラと周辺集積回路装置）、ＡＳＩＣ（Application Specific Integrated Circuit)などの集積回路装置、個別素子回路などのハードウェア電子（すなわち論理）回路、プログラマブル論理素子（ＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬなど）を用いることができる。要するに、上述し、かつ、後述する図８〜図１１のフローチャートで説明する機能を実行することのできる装置は、すべて、本発明の本旨と範囲の内で使用することができる。
【００７１】
図８は、初期負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。操作は、ＣＰＵがディスパッチすべき新たなスレッドをコントローラ７００が受け取ることにより開始する（ステップ８１０）。
【００７２】
次いで、コントローラ７００は、新たなスレッドが未バインドのスレッドであるかバインド済みのスレッドであるかを判断する（ステップ８２０）。これは、新たなスレッドが特定のＣＰＵにバインド済みであるか、あるいは未バインドであるかを示す、当該新たなスレッドに関連付けられた属性情報を読み取ることにより実行することができる。新たなスレッドがバインド済みの場合（ステップ８２０：ＹＥＳ）、コントローラ７００は、当該新たなスレッドをバインドされたＣＰＵに関連付けられたローカル実行キューに配置する（ステップ８３０）。新たなスレッドが未バインドの場合（ステップ８２０：ＮＯ）、コントローラ７００は、初期負荷平準化装置７３０に命じて初期負荷平準化を実行させる。初期負荷平準化装置７３０は、新たなスレッドが既存のプロセスの一部であるか否かを判断する（ステップ８４０）。これも、新たなスレッドに関連付けられた属性情報を読み取ることにより実行することができる。
【００７３】
新たなスレッドが既存のプロセスの一部である場合（ステップ８４０：ＹＥＳ）、初期負荷平準化装置７３０は、当該既存のプロセスの残りのスレッドが割り当てられていたノードのＣＰＵ群に対するラウンド・ロビン検索を実行して（ステップ８５０）アイドル状態のＣＰＵを探す。新たなスレッドが既存のプロセスの一部でない場合（ステップ８４０：ＮＯ）、初期負荷平準化装置７３０は、アイドル状態のＣＰＵを求めてすべてのノードとＣＰＵに対するラウンド・ロビン検索を実行する（ステップ８６０）。
【００７４】
初期負荷平準化装置７３０は、アイドル状態のＣＰＵが見つかったか否かを判断し（ステップ８７０）、もし見つかっていれば、そのアイドル状態のＣＰＵのローカル実行キューに新たなスレッドを配置する（ステップ８９０）。アイドル状態のＣＰＵが見つかっていなければ、初期負荷平準化装置７３０は、新たなスレッドをグローバル実行キューに配置する（ステップ８８０）。新たなスレッドが既存のプロセスの一部である場合、新たなスレッが付加されるグローバル実行キューは、当該既存のプロセスの残りのスレッド（あるいは現在のスレッドを生成したスレッド）が割り当てられていたノード用のグローバル実行キューである。新たなスレッドが既存のプロセスの一部でない場合、新たなスレッドが付加されるグローバル実行キューは、たとえばラウンド・ロビン検索に基づいて選考されたグローバル実行キューである。（ただし、ラウンド・ロビン検索の代わりに、別の負荷配置手法を使うこともできる）。このグローバル実行キューは、保有するスレッドの数が最も少ないノード、すなわち最も負荷が少ないノードに関連付けられたグローバル実行キューである。
【００７５】
図９は、アイドル状態負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図９に示すように、操作は、コントローラ７００がアイドル状態負荷平準化装置７４０に命じてアイドル状態負荷平準化を実行させたときに開始する。
【００７６】
したがって、アイドル状態負荷平準化装置７４０は、潜在的アイドル状態のＣＰＵのノードのローカル実行キューを走査して、上述したアイドル状態負荷平準化基準を満たすローカル実行キューを探す（ステップ９１０）。アイドル状態負荷平準化基準を満たすローカル実行キューが見つかった場合（ステップ９２０：ＹＥＳ）、アイドル状態負荷平準化装置７４０は、アイドル状態負荷平準化基準を満たすローカル実行キューからスレッドをスチールする（ステップ９４０）。アイドル状態負荷平準化基準を満たすローカル実行キューが見つからない場合（ステップ９２０：ＮＯ）、アイドル状態負荷平準化装置７４０は、ＣＰＵがアイドル状態になるのに任せる（ステップ９３０）。
【００７７】
図１０は、周期的負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図１０に示すように、操作は、コントローラ７００が周期的負荷平準化装置７５０に命じて周期的負荷平準化を実行させたときに開始する（ステップ１０１０）。
これは、たとえば周期的な操作タイミングに基づいて実行することができる。
【００７８】
周期的負荷平準化装置７５０は、最重量負荷ローカル実行キューと最軽量負荷ローカル実行キューを特定する（ステップ１０２０）。次いで、周期的負荷平準化装置７５０は、最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けているか否かを判断する（ステップ１０３０）。これは、最軽量負荷ローカル実行キューに相当する内部構造のフラグの現在の設定を判定することにより実行することができる。
【００７９】
最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けている場合（ステップ１０３０：ＹＥＳ）、周期的負荷平準化は実行しない（ステップ１０７０）。
【００８０】
最軽量負荷ローカル実行キューが直前のクロック・サイクルでアイドル状態負荷平準化の恩恵を受けていない場合（ステップ１０３０：ＮＯ）、周期的負荷平準化装置７５０は、これら最重量負荷ローカル実行キュー用の負荷因数と最軽量負荷ローカル実行キュー用の負荷因数を算出したのち（ステップ１０４０）、これら負荷因数の差を算出し（ステップ１０５０）、その差がしきい値よりも大きいか否かを判断する（ステップ１０６０）。
【００８１】
上記負荷因数間の差がしきい値よりも大きい場合（ステップ１０６０：ＹＥＳ）、周期的負荷平準化装置７５０は、最重量負荷ローカル実行キューから未バインドのスレッドをスチールして、それを最軽量負荷ローカル実行キューに配置する（ステップ１０７０）。上記負荷因数間の差がしきい値よりも大きくない場合（ステップ１０６０：ＮＯ）、システムは良好に負荷平準化されているので、負荷平準化は実行しない。
【００８２】
図１１は、飢餓状態負荷平準化を実行するときにおけるディスパッチャ１５０の典型的な操作の概要を示すフローチャートを示す図である。図１１に示すように、操作は、コントローラ７００が飢餓状態負荷平準化装置７６０に命じて飢餓状態負荷平準化を実行させたときに開始する（ステップ１１１０）。これは、たとえば周期的な操作タイミングに基づいて実行することができる。
【００８３】
飢餓状態負荷平準化装置７６０は、システム内の各スレッドを走査して未バインドのスレッドがないかどうか調べる（ステップ１１２０）。飢餓状態負荷平準化装置７６０は、未バインドのスレッド用のタイムスタンプを識別し（ステップ１１３０）、そのタイムスタンプが当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいるか否かを判断する（ステップ１１４０）。
【００８４】
当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいる場合（ステップ１１４０：ＹＥＳ）、当該未バインドのスレッドを、当該未バインドのスレッドのローカル実行キューを含んでいるノードのグローバル実行キューに入れる。当該未バインドのスレッドがしきい値時間よりも長い間ローカル実行キューに未定のままでいなかった場合（ステップ１１４０：ＮＯ）、当該未バインドのスレッドは、当該未バインドのスレッドのローカル実行キューに残置する。次いで、飢餓状態負荷平準化装置７６０は、検索すべきスレッドが他にあるか否かを判断する（ステップ１１６０）。検索すべきスレッドが他にもある場合（ステップ１１６０：ＹＥＳ）、飢餓状態負荷平準化装置７６０は、上述した操作を繰り返して実行する（ステップ１１２０〜１１６０）。検索すべきスレッドがもはや存在しない場合（ステップ１１６０：ＮＯ）、操作は終了する。
【００８５】
本発明によれば、グローバル実行キューとローカル実行キューとの双方を使うことにより、多重実行キュー・システムにおいて負荷平準化を行なうことができる。本発明によれば、初期負荷平準化、アイドル状態負荷平準化、周期的負荷平準化、および飢餓状態負荷平準化を互いに協働して実行することにより、ローカル実行キュー群間の最適な負荷平準化を実現することができる。
【００８６】
〔固定優先順位スレッド〕
ある条件下では、スレッドを固定した優先順位の順番でディスパッチする必要がある。たとえば、ＡＩＸ（Advanced Interactive eXective)オペレーティング・システムにおいて、ＰＯＳＩＸ（portable operating system interface for computer environments)準拠のプロセスでは、優先順位に厳格な順番でスレッドをディスパッチする必要がある。（ＡＩＸとはインターナショナル・ビジネス・マシーンズ・コーポレーション〔International Business Machines Corporation 〕が独自に開発したＵＮＩＸ（Ｒ）オペレーティング・システムの１つのバージョンのことである。ＰＯＳＩＸとは米国電気電子学会〔ＩＥＥＥ〕委員会がＵＮＩＸ（Ｒ）をベースに策定している移植性の高いＯＳインタフェース仕様のことである）。優先順位に厳格な順番でスレッドをディスパッチするには、すべてのスレッドを単一のＣＰＵにディスパッチする必要があるので、従来技術の多重実行キュー・システムなど多重実行キュー・システムでは、優先順位に厳格な順番でスレッドをディスパッチすることは、実行できない。
【００８７】
本発明は、この課題を、ＰＯＳＩＸ準拠の固定優先順位スレッドなどすべての固定優先順位スレッドを、たとえばＭＰシステム１１０の第１のノード１２０用のグローバル実行キューに割り当てることにより、解決している。このように、本発明では、固定優先順位スレッドは、複数のローカル実行キューに分散しておらず、単一のグローバル実行キューに存在しているので、優先順位に厳格な順番でディスパッチされることが保証されている。
【００８８】
ＣＰＵは、所定優先順位のスレッドをディスパッチできるようになると、グローバル実行キュー中の次順位のスレッドをディスパッチすることになるので、固定優先順位スレッドをグローバル実行キューに自動的に割り当てると、キャッシュとの類似性によって得られる利点がなくなってしまう。これを避けるために、キャッシュとの類似性がありうる点は無視して、固定優先順位スレッドは、使用可能になった任意のＣＰＵにまず割り当てる。しかしながら、固定優先順位スレッドを優先順位に厳格な順番でディスパッチすることの利点、および、次に使用可能なった任意のＣＰＵが固定優先順位スレッドをディスパッチする利点によって、キャッシュとの類似性が失われた点を埋め合わすことができる。これは、固定優先順位スレッドは非常に恵まれたスレッドであるので、それらはできるだけ早く実行するのが望ましい、ということを根拠にしている。
【００８９】
固定優先順位スレッドを識別するために、固定優先順位スレッドは、固定優先順位フラグを含む属性情報を備えている。固定優先順位フラグは、たとえばＰＯＳＩＸ準拠のフラグであり、固定優先順位スレッドが固定優先順位スレッドとして扱われるときにセットする（「１」にする）。あるスレッドにこの固定優先順位フラグがセットされていると、ディスパッチャ１５０は、そのスレッドを固定優先順位スレッドとしてＭＰシステム１１０の第１のノード１２０用のグローバル実行キューに割り当てる。次いで、各ＣＰＵはグローバル実行キューの面倒を見ているから、上記ノード１２０に関連付けられているＣＰＵは、自分がスレッドをディスパッチできるようになると、上記固定優先順位スレッドを優先順位に厳格な順番でディスパッチすることができる。このように、本発明による多重実行キュー・システムで、ＰＯＳＩＸ準拠のスレッドなどの固定優先順位スレッドを利用することが可能になる。
【００９０】
留意すべき重要な点として、完全に機能するデータ処理システムの文脈で本発明を説明したけれども、本発明の方法は命令を記録したコンピュータ読み取り可能な媒体など様々な形態で頒布することができるとともに、本発明は頒布するのに実際に使用されている特定の種類の信号搬送媒体とは無関係に等しく適用することができる、ということを当業者は認識できる。コンピュータ読み取り可能な媒体の例には、フロッピー（Ｒ）・ディスク、ハード・ディスク駆動装置、ＲＡＭ、ＣＤ−ＲＯＭなどの記録型媒体、ならびに、ディジタルおよびアナログの通信リンクなどの伝送型媒体がある。
【００９１】
上述した本発明の説明は、説明および記述のために行なったものであり、本発明を開示した形態のものに限定することを意図していない。多くの変更および変形は、当業者にとって自明である。実施形態は、本発明の原理および実際の適用を最もうまく説明するために、ならびに、当業者が考えうる特定の用途に適合するように様々な変更を加えた様々な実施形態について本発明を理解しうるように、選んだ。
【００９２】
まとめとして以下の事項を開示する。
（１）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる方法であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断するステップと、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てるステップと、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てるステップとを備えた方法。
（２）アイドル状態のプロセッサがあるか否かを判断するステップが、
前記複数のローカル実行キューのラウンド・ロビン検索を実行するステップ
を備えている、
上記（１）に記載の方法。
（３）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索の実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（２）に記載の方法。
（４）前記割り当てるスレッドが未バインドのスレッドである、
上記（３）に記載の方法。
（５）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（２）に記載の方法。
（６）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
スレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（１）に記載の方法。
（７）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（６）に記載の方法。
（８）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる、コンピュータ読み取り可能な媒体を使ったコンピューター・プログラム製品であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断する第１の命令群と、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てる第２の命令群と、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てる第３の命令群と
を備えたコンピューター・プログラム製品。
（９）前記第１の命令群が、
前記複数のローカル実行キューのラウンド・ロビン検索を実行する命令群
を含んでいる、
上記（８）に記載のコンピューター・プログラム製品。
（１０）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（９）に記載のコンピューター・プログラム製品。
（１１）前記割り当てるスレッドが未バインドのスレッドである、
上記（１０）に記載のコンピューター・プログラム製品。
（１２）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（９）に記載のコンピューター・プログラム製品。
（１３）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
スレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（８）に記載のコンピューター・プログラム製品。
（１４）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（１３）に記載のコンピューター・プログラム製品。
（１５）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる装置であって、
前記多重プロセッサ・システムにアイドル状態のプロセッサがあるか否かを判断する判断手段と、
アイドル状態のプロセッサがある場合、当該アイドル状態のプロセッサに関連付けられた複数のローカル実行キューのうちの１つのローカル実行キューにスレッドを割り当てる第１の割り当て手段と、
アイドル状態のプロセッサがない場合、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューにスレッドを割り当てる第２の割り当て手段と
を備えた装置。
（１６）前記判断手段が、
アイドル状態のプロセッサがあるか否かを、前記複数のローカル実行キューのラウンド・ロビン検索を実行することにより判断する、
上記（１５）に記載の装置。
（１７）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記判断手段は、
前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始して前記ラウンド・ロビン検索を実行する、
上記（１６）に記載の装置。
（１８）前記割り当てるスレッドが未バインドのスレッドである、
上記（１７）に記載の装置。
（１９）前記割り当てるスレッドが既存のプロセスの一部であり、
前記複数のローカル実行キューの前記ラウンド・ロビン検索が、前記既存のプロセスの残りのスレッドが割り当てられていたプロセッサのサブグループ内のプロセッサに関連付けられたローカル実行キューに限定されている、
上記（１６）に記載の装置。
（２０）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
前記第２の割り当て手段によってスレッドが割り当てられるグローバル実行キューが、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきグローバル実行キューである、
上記（１５）に記載の装置。
（２１）前記第２の割り当て手段は、
あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであると判断する、
上記（２０）に記載の装置。
（２２）複数のローカル実行キューおよび少なくとも１つのグローバル実行キューを備えた多重プロセッサ・システムにおいて、スレッドを実行キューに割り当てる方法であって、
割り当てるスレッドが未バインドであるかバインド済みであるかを判断するステップと、
割り当てるスレッドがバインド済みである場合、当該スレッドを、当該スレッドがバインドされているローカル実行キューに割り当てるステップと、
割り当てるスレッドが未バインドである場合、初期負荷平準化を実行して、当該スレッドを、前記複数のローカル実行キューのうちの１つのローカル実行キュー、または、前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューに割り当てるステップと
を備えた方法。
（２３）前記初期負荷平準化が、
前記複数のローカル実行キューを検索して空のローカル実行キューを見つけるステップと、
空のローカル実行キューが見つかった場合、前記割り当てるスレッドを当該空のローカル実行キューに割り当てるステップと
を備えている、
上記（２２）に記載の方法。
（２４）前記初期負荷平準化が、さらに、
空のローカル実行キューが見つからなかった場合、前記割り当てるスレッドを前記少なくとも１つのグローバル実行キューのうちの１つのグローバル実行キューに割り当てるステップ
を備えている、
上記（２３）に記載の方法。
（２５）前記複数のローカル実行キューを検索して空のローカル実行キューを見つける前記ステップが、
前記複数のローカル実行キューのラウンド・ロビン検索を実行するステップ
を備えている、
上記（２３）に記載の方法。
（２６）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、該サブグループは順番をなしており、
前記ラウンド・ロビン検索の実行は、前記順番において、直前のスレッドが割り当てられていたプロセッサのサブグループの後ろに位置するプロセッサのサブグループのローカル実行キューから開始する、
上記（２５）に記載の方法。
（２７）前記多重プロセッサ・システムがプロセッサのサブグループに編成されており、各プロセッサのサブグループは１つのグローバル実行キューを備えており、
前記割り当てるスレッドを、前記多重プロセッサ・システム内の前記少なくとも１つのグローバル実行キューのラウンド・ロビン検索によって選考すべきであると判断したグローバル実行キューに割り当てる、
上記（２２）に記載の方法。
（２８）あるグローバル実行キューが、最大限に負荷をかけられたノードまたは最小限に負荷をかけられたノードのうちの少なくとも一方に関連付けられている場合、当該グローバル実行キューを選考すべきであるとする、
上記（２７）に記載の方法。
【図面の簡単な説明】
【図１】 多重実行キュー・システムの典型的なブロック図である。
【図２】 初期負荷平準化法を説明する、多重実行キュー・システムの典型的なブロック図である。
【図３】 アイドル状態のプロセッサが見つからないときにおける初期負荷平準化法を説明する、多重実行キュー・システムの典型的なブロック図である。
【図４】 アイドル状態負荷平準化法を説明する、あるノードの典型例を示す図である。
【図５】 周期的負荷平準化法を説明する、あるノードの典型例を示す図である。
【図６】 飢餓状態負荷平準化法を説明する、あるノードの典型例を示す図である。
【図７】 図１のディスパッチャの典型的なブロック図である。
【図８】 初期負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図９】 アイドル状態負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図１０】 周期的負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【図１１】 飢餓状態負荷平準化を実行するときにおけるディスパッチャの典型的な操作の概要を示すフローチャートを示す図である。
【符号の説明】
１００…多重キュー・システム、１１０…多重プロセッサ（ＭＰ）システム、１１１…ＣＰＵ、１１２…ＣＰＵ、１１３…ＣＰＵ、１１４…ＣＰＵ、１１５…ＣＰＵ、１１６…ＣＰＵ、１１７…ＣＰＵ、１２０…ノード、１３０…ノード、１４０…ノード、１５０…ディスパッチャ、２００…多重実行キュー・システム、２０５…ＭＰシステム、２２０…ノード、２２１…グローバル実行キュー、２２２…グローバル実行キュー、２２３…グローバル実行キュー、２２４…ノード、２２５…ノード、２３０…ＣＰＵ、２４０…ＣＰＵ、２５０…ＣＰＵ、２６０…ＣＰＵ、２７０…ＣＰＵ、２８０…ＣＰＵ、２９１…ローカル実行キュー、２９２…ローカル実行キュー、２９３…ローカル実行キュー、２９４…ローカル実行キュー、２９５…ローカル実行キュー、２９６…ローカル実行キュー、４００…ノード、４１０…ＣＰＵ、４２０…ＣＰＵ、４３０…ＣＰＵ、４４０…ＣＰＵ、４５０…ＣＰＵ、４６０…ＣＰＵ、４７１…ローカル実行キュー、４７２…ローカル実行キュー、４７３…ローカル実行キュー、４７４…ローカル実行キュー、４７５…ローカル実行キュー、４７６…ローカル実行キュー、５００…ノード、５１０…ＣＰＵ、５２０…ＣＰＵ、５３０…ＣＰＵ、５４０…ＣＰＵ、５５０…ＣＰＵ、５６０…ＣＰＵ、５７１…ローカル実行キュー、５７２…ローカル実行キュー、５７３…ローカル実行キュー、５７４…ローカル実行キュー、５７５…ローカル実行キュー、５７６…ローカル実行キュー、６００…ノード、６１０…ＣＰＵ、６２０…ＣＰＵ、６３０…ＣＰＵ、６４０…ＣＰＵ、６５０…ＣＰＵ、６６０…ＣＰＵ、６７１…ローカル実行キュー、６７２…ローカル実行キュー、６７３…ローカル実行キュー、６７４…ローカル実行キュー、６７５…ローカル実行キュー、６７６…ローカル実行キュー、６８１…グローバル実行キュー、７００…コントローラ、７１０…メモリ、７２０…ＭＰシステム・インタフェース、７３０…初期負荷平準化装置、７４０…アイドル状態負荷平準化装置、７５０…周期的負荷平準化装置、７６０…飢餓状態負荷平準化装置、７７０…信号／制御バス。
Claims (27)
- ディスパッチャと、このディスパッチャに接続された複数のノードと、この複数のノードのうち一のノードに対して接続された複数のプロセッサとを含み、
前記ディスパッチャが、複数のスレッドを受信し、この複数のスレッドを前記複数のノードのうち一のノードに送信し、前記一のノードは、前記ディスパッチャから送信されたスレッドをグローバル実行キューに格納し、前記一のノードに接続された複数のプロセッサのうち一のプロセッサに前記スレッドを送信し、前記一のプロセッサは、前記一のノードから送信されたスレッドを受信し、この受信したスレッドをローカル実行キューに格納する多重実行キュー・システムにより、受信した複数のスレッドを実行キューに割り当てる方法であって、
前記ディスパッチャが、スレッドを受信し、前記多重実行キュー・システム内の全てのプロセッサがスレッドを処理しているかを判断するステップと、
前記ディスパッチャが、前記プロセッサの全てがスレッドを処理していると判断した場合には、前記ディスパッチャが、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索するステップと、
前記格納されたスレッドの数が最も少ないグローバル実行キューを備えたノードに、前記スレッドを送信するステップと、
前記ノードが一時的にこの送信されたスレッドを格納するステップと、
このノードが接続された複数のプロセッサのうち一のプロセッサの処理が終了したときに、前記ディスパッチャが、前記ノードに一時的に格納されたスレッドをこの一のプロセッサに送信するステップと、
を含む方法。 - 請求項１の方法において、
前記多重実行キュー・システム内の全てのプロセッサがスレッドを処理しているかを判断した後に、
前記スレッドが特定のプロセッサで処理すべきスレッドであると前記ディスパッチャが判断するステップと、
前記ディスパッチャは、この特定のプロセッサに接続されたノードを介して、前記特定のプロセッサに、前記スレッドを送信するステップと、
を含む方法。 - 請求項１に記載の方法において、前記ディスパッチャが、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索するステップの前に、
前記ディスパッチャが、前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断するステップと、
前記ディスパッチャが、アイドル状態のプロセッサがあると判断した場合には、前記ディスパッチャが、アイドル状態であるプロセッサに、このプロセッサに接続されたノードを介して、前記スレッドを送信するステップと、
を含む方法。 - 請求項１に記載の方法において、前記ディスパッチャが、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索するステップの前に、
前記ディスパッチャが、前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断するステップと、
前記ディスパッチャは、前記ノードに接続された複数のプロセッサのうち、前記ローカル実行キューに格納されたスレッドの数が最も多いプロセッサを判断するステップと、
この格納されたスレッドの数が最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドから一以上のスレッドをスチールするステップと、
このスチールしたスレッドを、前記アイドル状態のプロセッサのローカル実行キューに送信するステップと、を備えるアイドル状態負荷平準化ステップを含む方法。 - 請求項３に記載のステップの、アイドル状態のプロセッサがあるかを判断するときに、
前記多重実行キュー・システム内の全てのプロセッサを、ラウンド・ロビン検索することにより、プロセッサがアイドル状態であるかを判断する方法。 - 請求項１に記載の方法において、
前記複数のノードのうち一のノードが、このノードに接続された複数のプロセッサのうちローカル実行キューに格納されたスレッドが最も多いプロセッサと最も少ないプロセッサを周期的に判断し、その格納されたスレッドが最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドをスチールし、前記スレッドが最も少ないと判断したプロセッサのローカル実行キューに前記スチールしたスレッドを送信するステップと、を備える周期的負荷平準化ステップを含む方法。 - 請求項６に記載の方法の周期的負荷平準化ステップでは、前記ディスパッチャが、前記ローカル実行キューに格納されたスレッドが最も多いプロセッサのスレッドの数と、最も少ないプロセッサのスレッドの数とから、負荷因数を周期的に算出し、この負荷因数から周期的に負荷平準化を行う方法。
- 請求項１に記載の方法において、
前記複数のノードのうち一のノードが、このノードに接続された複数のプロセッサのうち、所定の期間が経過しても処理されていないスレッドがあるかを判断し、この処理されていないスレッドを、前記一のノードのグローバル実行キューに一時的に格納し、格納した一のノードから、前記複数のプロセッサのうち最もスレッドを格納している数が少ないプロセッサに送信するステップと、を備える飢餓状態負荷平準化ステップを含む方法。 - 請求項２に記載の方法において、
前記ディスパッチャがスレッドを受信したときに、前記ディスパッチャが、プロセスが複数のスレッドに分解されたスレッドであるかを判断するステップと、
前記特定のプロセッサで処理すべきスレッドかを前記ディスパッチャが判断するステップの前に、前記プロセスから分解された複数のスレッドのうち一のスレッドが、既に一のプロセッサに送信されていることを判断するステップと、
前記ディスパッチャが、前記一のスレッドが、既に一のプロセッサに送信されていると判断した場合には、他のスレッドもこの一のプロセッサに、この一のプロセッサに接続されたノードを介して送信するステップと、
を含む方法。 - ディスパッチャと、このディスパッチャに接続された複数のノードと、この複数のノードのうち一のノードに対して接続された複数のプロセッサと、を含み、
前記ディスパッチャが、複数のスレッドを受信し、この複数のスレッドを前記複数のノードのうち一のノードに送信し、前記一のノードは、前記ディスパッチャから送信されたスレッドをグローバル実行キューに格納し、前記一のノードに接続された複数のプロセッサのうち一のプロセッサに前記スレッドを送信し、前記一のプロセッサは、前記一のノードから送信されたスレッドを受信し、この受信したスレッドをローカル実行キューに格納する多重実行キュー・システムに、受信した複数のスレッドを実行キューに割り当てる方法を実行させるプログラムであって、
前記ディスパッチャに、
スレッドを受信し、前記多重実行キュー・システム内の全てのプロセッサがスレッドを処理しているかを判断するステップと、
前記ディスパッチャが、前記プロセッサの全てがスレッドを処理していると判断した場合には、前記ディスパッチャが、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索するステップと、
前記格納されたスレッドの数が最も少ないグローバル実行キューを備えたノードに、前記スレッドを送信するステップと、を実行させ、
前記ノードに、一時的にこの送信されたスレッドを格納するステップと、を実行させ、
前記ディスパッチャに、
このノードが接続された複数のプロセッサのうち一のプロセッサの処理が終了したときに、前記ディスパッチャが、前記ノードに一時的に格納されたスレッドをこの一のプロセッサに送信するステップと、を実行させるためのプログラム。 - 請求項１０のプログラムにおいて、
前記ディスパッチャに、
前記多重実行キュー・システム内の全てのプロセッサがスレッドを処理しているかを判断した後に、前記スレッドが特定のプロセッサで処理すべきスレッドであると判断するステップと、
この特定のプロセッサに接続されたノードを介して、前記特定のプロセッサに、前記スレッドを送信するステップと、を実行させるためのプログラム。 - 請求項１０に記載のプログラムにおいて、
前記ディスパッチャに、
前記グローバル実行キューに格納されたスレッドの数が最も少ないノードを検索するステップの前に、
前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断するステップと、
アイドル状態のプロセッサがあると判断した場合には、アイドル状態であるプロセッサに、このプロセッサに接続されたノードを介して、前記スレッドを送信するステップと、を実行させるためのプログラム。 - 請求項１０に記載のプログラムにおいて、
前記ディスパッチャに、
前記グローバル実行キューに格納されたスレッドの数が最も少ないノードを検索するステップの前に、
前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断するステップと、
前記ノードに接続された複数のプロセッサのうち、前記ローカル実行キューに格納されたスレッドの数が最も多いプロセッサを判断するステップと、
この格納されたスレッドの数が最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドから一以上のスレッドをスチールするステップと、
このスチールしたスレッドを、前記アイドル状態のプロセッサのローカル実行キューに送信するステップと、を備えるアイドル状態負荷平準化ステップを実行させるためのプログラム。 - 請求項１３に記載のプログラムであって、
前記アイドル状態のプロセッサがあるか否かを判断するステップは、
前記多重実行キュー・システム内の全てのプロセッサを、ラウンド・ロビン検索することにより、プロセッサがアイドル状態であるかを判断するステップであるプログラム。 - 請求項１０に記載のプログラムにおいて、
前記複数のノードのうち一のノードに、
このノードに接続された複数のプロセッサのうちローカル実行キューに格納されたスレッドが最も多いプロセッサと最も少ないプロセッサを周期的に判断し、その格納されたスレッドが最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドをスチールし、前記スレッドが最も少ないと判断したプロセッサのローカル実行キューに前記スチールしたスレッドを送信するステップと、を備える周期的負荷平準化ステップを実行させるためのプログラム。 - 請求項１５に記載のプログラムであって、
前記周期的負荷平準化ステップにおいて、
前記ディスパッチャに、
前記ローカル実行キューに格納されたスレッドが最も多いプロセッサのスレッドの数と、最も少ないプロセッサのスレッドの数とから、負荷因数を周期的に算出し、この負荷因数から周期的に負荷平準化を行わせるプログラム。 - 請求項１０に記載のプログラムにおいて、
前記複数のノードのうち一のノードに、
このノードに接続された複数のプロセッサのうち、所定の期間が経過しても処理されていないスレッドがあるかを判断し、この処理されていないスレッドを、前記一のノードのグローバル実行キューに一時的に格納し、格納した一のノードから、前記複数のプロセッサのうち最もスレッドを格納している数が少ないプロセッサに送信するステップと、を備える飢餓状態負荷平準化ステップを実行させるためのプログラム。 - 請求項１１に記載のプログラムにおいて、
前記ディスパッチャに、
スレッドを受信したときに、プロセスが複数のスレッドに分解されたスレッドであるかを判断するステップと、
前記特定のプロセッサで処理すべきスレッドかを判断するステップの前に、前記プロセスから分解された複数のスレッドのうち一のスレッドが、既に一のプロセッサに送信されていることを判断するステップと、
前記一のスレッドが、既に一のプロセッサに送信されていると判断した場合には、他のスレッドもこの一のプロセッサに、この一のプロセッサに接続されたノードを介して送信するステップと、
を実行させるためのプログラム。 - 複数のノードと、複数のプロセッサと、ディスパッチャとからなる実行キューが多重化された装置であって、
前記複数のノードは、スレッドを格納するグローバル実行キューを備え、前記複数のプロセッサのうち一のプロセッサにスレッドを送信し、
前記複数のプロセッサは、前記複数のノードのうち一のノードに接続され、前記グローバル実行キューに格納されたスレッドを受信し、この受信したスレッドを格納するローカル実行キューを備え、
前記ディスパッチャは、前記複数のノードの各々に接続され、前記スレッドを受信し、前記多重実行キュー・システム内のプロセッサの全てがスレッドを処理しているかを判断し、前記プロセッサの全てがスレッドを処理していると判断した場合には、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索し、前記格納されたスレッドの数が最も少ないグローバル実行キューを備えたノードに、前記スレッドを送信し、このノードが接続された複数のプロセッサのうち一のプロセッサの処理が終了したときに、前記ノードに一時的に格納されたスレッドをこの一のプロセッサに送信する装置。 - 請求項１９の装置において、
前記ディスパッチャは、前記多重実行キュー・システム内の全てのプロセッサがスレッドを処理しているかを判断した後に、前記スレッドが特定のプロセッサで処理すべきスレッドであると判断し、この特定のプロセッサに接続されたノードを介して、前記特定のプロセッサに、前記スレッドを送信する装置。 - 請求項１９に記載の装置において、
前記ディスパッチャは、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索する前に、前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断し、アイドル状態のプロセッサがあると判断した場合には、前記ディスパッチャが、アイドル状態であるプロセッサに、このプロセッサに接続されたノードを介して、前記スレッドを送信する装置。 - 請求項１９に記載の装置において、
前記ディスパッチャは、前記グローバル実行キューに格納したスレッドの数が最も少ないノードを検索するステップの前に、前記多重実行キュー・システム内の全てのプロセッサのうちアイドル状態のプロセッサがあるか否かを判断し、前記ノードに接続された複数のプロセッサのうち、前記ローカル実行キューに格納されたスレッドの数が最も多いプロセッサを判断し、この格納されたスレッドの数が最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドから一以上のスレッドをスチールし、このスチールしたスレッドを、前記アイドル状態のプロセッサのローカル実行キューに送信する装置。 - 請求項２１に記載の装置において、
前記ディスパッチャは、アイドル状態のプロセッサがあるかを判断するときに、
前記多重実行キュー・システム内の全てのプロセッサを、ラウンド・ロビン検索することにより、プロセッサがアイドル状態であるかを判断する装置。 - 請求項１９に記載の装置において、
前記ディスパッチャは、前記複数のノードのうち一のノードが、このノードに接続された複数のプロセッサのうちローカル実行キューに格納されたスレッドが最も多いプロセッサと最も少ないプロセッサを周期的に判断し、この格納されたスレッドが最も多いと判断したプロセッサのローカル実行キューに格納されたスレッドをスチールし、前記スレッドが最も少ないと判断したプロセッサのローカル実行キューに前記スチールしたスレッドを送信する装置。 - 請求項２４に記載の装置において、
前記ディスパッチャは、前記ローカル実行キューに格納されたスレッドが最も多いプロセッサのスレッドの数と、最も少ないプロセッサのスレッドの数とから、負荷因数を周期的に算出し、この負荷因数から周期的に負荷平準化を行う装置。 - 請求項１９に記載の装置において、
前記ディスパッチャは、前記複数のノードのうち一のノードが、このノードに接続された複数のプロセッサのうち、所定の期間が経過しても処理されていないスレッドがあるかを判断し、この処理されていないスレッドを、前記一のノードのグローバル実行キューに一時的に格納し、格納した一のノードから、前記複数のプロセッサのうち最もスレッドを格納している数が少ないプロセッサに送信する装置。 - 請求項２０に記載の装置において、
前記ディスパッチャは、前記スレッドを受信したときに、プロセスが複数のスレッドに分解されたスレッドであるかを判断し、前記プロセスから分解された複数のスレッドのうち一のスレッドが、既に一のプロセッサに送信されていることを判断し、前記一のスレッドが、既に一のプロセッサに送信されていると判断した場合には、他のスレッドもこの一のプロセッサに、この一のプロセッサに接続されたノードを介して送信する装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/615,768 US6735769B1 (en) | 2000-07-13 | 2000-07-13 | Apparatus and method for initial load balancing in a multiple run queue system |
| US09/615768 | 2000-07-13 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002063148A JP2002063148A (ja) | 2002-02-28 |
| JP3678414B2 true JP3678414B2 (ja) | 2005-08-03 |
Family
ID=24466726
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001198349A Expired - Fee Related JP3678414B2 (ja) | 2000-07-13 | 2001-06-29 | 多重プロセッサ・システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6735769B1 (ja) |
| JP (1) | JP3678414B2 (ja) |
Families Citing this family (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7080379B2 (en) | 2002-06-20 | 2006-07-18 | International Business Machines Corporation | Multiprocessor load balancing system for prioritizing threads and assigning threads into one of a plurality of run queues based on a priority band and a current load of the run queue |
| US7594233B2 (en) * | 2002-06-28 | 2009-09-22 | Hewlett-Packard Development Company, L.P. | Processing thread launching using volunteer information |
| US7093258B1 (en) * | 2002-07-30 | 2006-08-15 | Unisys Corporation | Method and system for managing distribution of computer-executable program threads between central processing units in a multi-central processing unit computer system |
| US7487503B2 (en) * | 2004-08-12 | 2009-02-03 | International Business Machines Corporation | Scheduling threads in a multiprocessor computer |
| US20060112208A1 (en) * | 2004-11-22 | 2006-05-25 | International Business Machines Corporation | Interrupt thresholding for SMT and multi processor systems |
| US20060123423A1 (en) * | 2004-12-07 | 2006-06-08 | International Business Machines Corporation | Borrowing threads as a form of load balancing in a multiprocessor data processing system |
| US8140678B2 (en) * | 2004-12-28 | 2012-03-20 | Sap Ag | Failover protection from a failed worker node in a shared memory system |
| US20070061805A1 (en) * | 2005-09-15 | 2007-03-15 | Brenner Larry B | Method and apparatus for improving thread posting efficiency in a multiprocessor data processing system |
| US7765450B2 (en) * | 2005-10-20 | 2010-07-27 | Jon Udell | Methods for distribution of test generation programs |
| US8566827B2 (en) * | 2005-10-27 | 2013-10-22 | International Business Machines Corporation | System and method of arbitrating access of threads to shared resources within a data processing system |
| US20070143582A1 (en) * | 2005-12-16 | 2007-06-21 | Nvidia Corporation | System and method for grouping execution threads |
| US8707323B2 (en) * | 2005-12-30 | 2014-04-22 | Sap Ag | Load balancing algorithm for servicing client requests |
| US8674987B2 (en) * | 2006-09-19 | 2014-03-18 | Caustic Graphics, Inc. | Dynamic ray population control |
| US9274921B2 (en) * | 2006-12-27 | 2016-03-01 | International Business Machines Corporation | System and method for managing code displacement |
| US8739162B2 (en) * | 2007-04-27 | 2014-05-27 | Hewlett-Packard Development Company, L.P. | Accurate measurement of multithreaded processor core utilization and logical processor utilization |
| US8452947B2 (en) * | 2008-02-01 | 2013-05-28 | International Business Machines Corporation | Hardware wake-and-go mechanism and content addressable memory with instruction pre-fetch look-ahead to detect programming idioms |
| US8516484B2 (en) * | 2008-02-01 | 2013-08-20 | International Business Machines Corporation | Wake-and-go mechanism for a data processing system |
| US8788795B2 (en) * | 2008-02-01 | 2014-07-22 | International Business Machines Corporation | Programming idiom accelerator to examine pre-fetched instruction streams for multiple processors |
| US8171476B2 (en) * | 2008-02-01 | 2012-05-01 | International Business Machines Corporation | Wake-and-go mechanism with prioritization of threads |
| US8145849B2 (en) * | 2008-02-01 | 2012-03-27 | International Business Machines Corporation | Wake-and-go mechanism with system bus response |
| US8386822B2 (en) * | 2008-02-01 | 2013-02-26 | International Business Machines Corporation | Wake-and-go mechanism with data monitoring |
| US8341635B2 (en) * | 2008-02-01 | 2012-12-25 | International Business Machines Corporation | Hardware wake-and-go mechanism with look-ahead polling |
| US8312458B2 (en) * | 2008-02-01 | 2012-11-13 | International Business Machines Corporation | Central repository for wake-and-go mechanism |
| US8612977B2 (en) * | 2008-02-01 | 2013-12-17 | International Business Machines Corporation | Wake-and-go mechanism with software save of thread state |
| US8225120B2 (en) * | 2008-02-01 | 2012-07-17 | International Business Machines Corporation | Wake-and-go mechanism with data exclusivity |
| US8732683B2 (en) | 2008-02-01 | 2014-05-20 | International Business Machines Corporation | Compiler providing idiom to idiom accelerator |
| US8725992B2 (en) | 2008-02-01 | 2014-05-13 | International Business Machines Corporation | Programming language exposing idiom calls to a programming idiom accelerator |
| US8316218B2 (en) * | 2008-02-01 | 2012-11-20 | International Business Machines Corporation | Look-ahead wake-and-go engine with speculative execution |
| US8250396B2 (en) | 2008-02-01 | 2012-08-21 | International Business Machines Corporation | Hardware wake-and-go mechanism for a data processing system |
| US8127080B2 (en) | 2008-02-01 | 2012-02-28 | International Business Machines Corporation | Wake-and-go mechanism with system address bus transaction master |
| US8640141B2 (en) * | 2008-02-01 | 2014-01-28 | International Business Machines Corporation | Wake-and-go mechanism with hardware private array |
| US8880853B2 (en) * | 2008-02-01 | 2014-11-04 | International Business Machines Corporation | CAM-based wake-and-go snooping engine for waking a thread put to sleep for spinning on a target address lock |
| WO2009113172A1 (ja) * | 2008-03-13 | 2009-09-17 | 富士通株式会社 | ジョブ割当装置、ジョブ割当装置の制御プログラム及び制御方法 |
| US8458451B2 (en) * | 2009-01-20 | 2013-06-04 | New York University | Database outsourcing with access privacy |
| US8145723B2 (en) * | 2009-04-16 | 2012-03-27 | International Business Machines Corporation | Complex remote update programming idiom accelerator |
| US8230201B2 (en) * | 2009-04-16 | 2012-07-24 | International Business Machines Corporation | Migrating sleeping and waking threads between wake-and-go mechanisms in a multiple processor data processing system |
| US8886919B2 (en) * | 2009-04-16 | 2014-11-11 | International Business Machines Corporation | Remote update programming idiom accelerator with allocated processor resources |
| US8413161B2 (en) * | 2009-09-29 | 2013-04-02 | International Business Machines Corporation | Work queue selection on a local processor within a multiple processor architecture |
| US8607232B2 (en) * | 2010-11-11 | 2013-12-10 | International Business Machines Corporation | Identifying a transient thread and excluding the transient thread from a processor load calculation |
| US8650538B2 (en) | 2012-05-01 | 2014-02-11 | Concurix Corporation | Meta garbage collection for functional code |
| US9417935B2 (en) | 2012-05-01 | 2016-08-16 | Microsoft Technology Licensing, Llc | Many-core process scheduling to maximize cache usage |
| US8495598B2 (en) | 2012-05-01 | 2013-07-23 | Concurix Corporation | Control flow graph operating system configuration |
| US8726255B2 (en) | 2012-05-01 | 2014-05-13 | Concurix Corporation | Recompiling with generic to specific replacement |
| US8595743B2 (en) | 2012-05-01 | 2013-11-26 | Concurix Corporation | Network aware process scheduling |
| US9047196B2 (en) | 2012-06-19 | 2015-06-02 | Concurix Corporation | Usage aware NUMA process scheduling |
| US8700838B2 (en) | 2012-06-19 | 2014-04-15 | Concurix Corporation | Allocating heaps in NUMA systems |
| US8793669B2 (en) | 2012-07-17 | 2014-07-29 | Concurix Corporation | Pattern extraction from executable code in message passing environments |
| US9575813B2 (en) | 2012-07-17 | 2017-02-21 | Microsoft Technology Licensing, Llc | Pattern matching process scheduler with upstream optimization |
| US8707326B2 (en) | 2012-07-17 | 2014-04-22 | Concurix Corporation | Pattern matching process scheduler in message passing environment |
| US9043788B2 (en) | 2012-08-10 | 2015-05-26 | Concurix Corporation | Experiment manager for manycore systems |
| US8656134B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed on executing code |
| US8656135B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed prior to execution |
| US8607018B2 (en) | 2012-11-08 | 2013-12-10 | Concurix Corporation | Memory usage configuration based on observations |
| US9665474B2 (en) | 2013-03-15 | 2017-05-30 | Microsoft Technology Licensing, Llc | Relationships derived from trace data |
| US9253253B1 (en) * | 2014-09-26 | 2016-02-02 | International Business Machines Corporation | Techniques for assigning user workloads to application servers |
| WO2016067339A1 (ja) * | 2014-10-27 | 2016-05-06 | 株式会社日立製作所 | ストレージシステム、及び、記憶制御方法 |
| US10684968B2 (en) * | 2017-06-15 | 2020-06-16 | International Business Machines Corporation | Conditional memory spreading for heterogeneous memory sizes |
| US11698816B2 (en) * | 2020-08-31 | 2023-07-11 | Hewlett Packard Enterprise Development Lp | Lock-free work-stealing thread scheduler |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS58115569A (ja) * | 1981-12-29 | 1983-07-09 | Fuji Electric Co Ltd | マルチプロセツサ方式 |
| JP2769367B2 (ja) * | 1989-09-28 | 1998-06-25 | 株式会社日立製作所 | マルチプロセッサスケジューリング方法 |
| JP2986930B2 (ja) * | 1991-01-29 | 1999-12-06 | 株式会社東芝 | 対称型マルチプロセッサのタスクスケジューリング方式 |
| US5745778A (en) * | 1994-01-26 | 1998-04-28 | Data General Corporation | Apparatus and method for improved CPU affinity in a multiprocessor system |
| JPH0836547A (ja) * | 1994-07-21 | 1996-02-06 | Hitachi Ltd | オンラインシステムにおけるトランザクションのスケジュール装置 |
| US5826081A (en) * | 1996-05-06 | 1998-10-20 | Sun Microsystems, Inc. | Real time thread dispatcher for multiprocessor applications |
| US5872972A (en) * | 1996-07-05 | 1999-02-16 | Ncr Corporation | Method for load balancing a per processor affinity scheduler wherein processes are strictly affinitized to processors and the migration of a process from an affinitized processor to another available processor is limited |
| US5889989A (en) * | 1996-09-16 | 1999-03-30 | The Research Foundation Of State University Of New York | Load sharing controller for optimizing monetary cost |
| US6292822B1 (en) * | 1998-05-13 | 2001-09-18 | Microsoft Corporation | Dynamic load balancing among processors in a parallel computer |
-
2000
- 2000-07-13 US US09/615,768 patent/US6735769B1/en not_active Expired - Fee Related
-
2001
- 2001-06-29 JP JP2001198349A patent/JP3678414B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002063148A (ja) | 2002-02-28 |
| US6735769B1 (en) | 2004-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3678414B2 (ja) | 多重プロセッサ・システム | |
| US6658449B1 (en) | Apparatus and method for periodic load balancing in a multiple run queue system | |
| US6748593B1 (en) | Apparatus and method for starvation load balancing using a global run queue in a multiple run queue system | |
| US7065766B2 (en) | Apparatus and method for load balancing of fixed priority threads in a multiple run queue environment | |
| US6981260B2 (en) | Apparatus for minimizing lock contention in a multiple processor system with multiple run queues when determining the threads priorities | |
| US5884077A (en) | Information processing system and method in which computer with high load borrows processor of computer with low load to execute process | |
| US8458712B2 (en) | System and method for multi-level preemption scheduling in high performance processing | |
| US6353844B1 (en) | Guaranteeing completion times for batch jobs without static partitioning | |
| US7251815B2 (en) | Multiple virtual machines sharing processor and work queue in memory having program/dispatch functions for assigning and accessing work items while the virtual machine was not idle | |
| US20030037091A1 (en) | Task scheduling device | |
| US20040163085A1 (en) | Method to distribute programs using remote java objects | |
| KR101640848B1 (ko) | 멀티코어 시스템 상에서 단위 작업을 할당하는 방법 및 그 장치 | |
| JPH1055284A (ja) | スレッドをスケジュールする方法及びそのシステム | |
| JPH11353196A (ja) | タイム・スケジュ―ルされたプロセス管理用ガバナ | |
| KR100791296B1 (ko) | 멀티 코어 시스템에서 협력적 스케줄링을 제공하는 장치 및방법 | |
| US20030191794A1 (en) | Apparatus and method for dispatching fixed priority threads using a global run queue in a multiple run queue system | |
| CN105303307B (zh) | 一种分配工作任务的方法及装置 | |
| JP5891284B2 (ja) | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 | |
| JP2007328413A (ja) | 負荷分散方法 | |
| CN110175078B (zh) | 业务处理方法及装置 | |
| JPH0877026A (ja) | 情報処理方法とその装置 | |
| Huang et al. | EDF-Adaptive: A New Semipartitioned Scheduling Algorithm for Multiprocessor Real-Time | |
| JPH11249917A (ja) | 並列型計算機及びそのバッチ処理方法及び記録媒体 | |
| Kakulavarapu et al. | Dynamic load balancers for a multithreaded multiprocessor system | |
| John et al. | Novel backfilling technique with deadlock avoidance and migration for grid workflow scheduling |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040305 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040323 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040622 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20040622 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040623 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041207 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050228 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050322 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050330 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050419 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20050419 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050509 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |