JP4127354B2 - Multiprocessor control program and multiprocessor control method - Google Patents

Multiprocessor control program and multiprocessor control method Download PDF

Info

Publication number
JP4127354B2
JP4127354B2 JP2001384027A JP2001384027A JP4127354B2 JP 4127354 B2 JP4127354 B2 JP 4127354B2 JP 2001384027 A JP2001384027 A JP 2001384027A JP 2001384027 A JP2001384027 A JP 2001384027A JP 4127354 B2 JP4127354 B2 JP 4127354B2
Authority
JP
Japan
Prior art keywords
execution
attribute
upper limit
processor
execution unit
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
Application number
JP2001384027A
Other languages
Japanese (ja)
Other versions
JP2003186856A (en
Inventor
英孝 田村
彰一 神尾
明裕 松下
良浩 藤井
幸弘 蔭田
和典 高田
修 宮川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
PFU Ltd
Original Assignee
Fujitsu Ltd
PFU Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd, PFU Ltd filed Critical Fujitsu Ltd
Priority to JP2001384027A priority Critical patent/JP4127354B2/en
Publication of JP2003186856A publication Critical patent/JP2003186856A/en
Application granted granted Critical
Publication of JP4127354B2 publication Critical patent/JP4127354B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Description

【０００１】
【発明の属する技術分野】
本発明はマルチプロセッサ制御プログラム及びマルチプロセッサ制御方法に関し、特に属性が付与された複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御プログラム及びマルチプロセッサ制御方法に関する。
【０００２】
【従来の技術】
現在、コンピュータのデータ処理能力を向上させるための様々な技術が存在する。その技術の中にデータ処理を複数のＣＰＵ(Central Processing Unit)で分担して並列処理させることによりデータ処理能力を向上させるマルチＣＰＵシステムがある。
【０００３】
マルチＣＰＵシステムにデータの並列処理をさせる方法として次の２通りがある。その１は、プロセスやスレッドなどのプログラムの実行単位を複数のＣＰＵに実行させ、実行が終了したＣＰＵに次々と実行待ちをしている実行単位を実行させる方法である。その２は、実行単位に属性を持たせ、属性ごとに実行単位を実行する複数のＣＰＵを決めて実行単位をＣＰＵに実行させ、実行が終了したＣＰＵから順に、そのＣＰＵが実行できる属性をもつ実行待ちをしている実行単位を実行させる方法である。
【０００４】
図１２は従来のマルチＣＰＵシステムの動作（その１）を説明する図である。図に示すマルチＣＰＵシステムは、４つのＣＰＵ４０〜４３を有する。ＣＰＵ４０〜４３はプログラムの実行単位であるプロセス４０ａ〜４３ａを実行している。また、プロセス４４，４５はＣＰＵ４０〜４３の実行待ちをしている。
【０００５】
ＣＰＵ４１がプロセス４１ａの実行を終了したとすると、実行待ちをしているプロセス４４がＣＰＵ４１よって実行される。また、ＣＰＵ４２がプロセス４２ａの実行を終了したとすると、実行待ちをしているプロセス４５がＣＰＵ４２によって実行される。このように、プロセスの実行を終了しプロセスを切り離したＣＰＵは、実行待ちをしているプロセスを順に実行していく。
【０００６】
図１３は従来のマルチＣＰＵシステムの動作（その２）を説明する図である。図に示すマルチＣＰＵシステムは、属性‘＃Ａ’を持つプロセスを実行するＣＰＵ５０，５１と、属性‘＃Ｂ’をもつプロセスを実行するＣＰＵ５２，５３とを有する。ＣＰＵ５０，ＣＰＵ５１は、属性‘＃Ａ’を持つプロセス５０ａ，５１ｂを実行し、ＣＰＵ５２，ＣＰＵ５３は、属性‘＃Ｂ’を持つプロセス５２ａ，５３ａを実行している。また、属性‘＃Ａ’を持つプロセス５４，５５は、ＣＰＵ５０，５１の実行待ちをしており、属性‘＃Ｂ’を持つプロセス５６，５７は、ＣＰＵ５２，５３の実行待ちをしている。
【０００７】
ＣＰＵ５０がプロセス５０ａの実行を終了したとすると、実行待ちをしている属性‘＃Ａ’を持つプロセス５４がＣＰＵ５０によって実行される。また、ＣＰＵ５２がプロセス５２ａの実行を終了したとすると、実行待ちをしている属性‘＃Ｂ’を持つプロセス５６がＣＰＵ５２によって実行される。このように、プロセスに属性を持たせ、属性ごとにプロセスを実行するＣＰＵを決め、プロセスの実行を終了しプロセスを切り離したＣＰＵは、決められた属性の実行待ちをしているプロセスを順に実行していく。
【０００８】
【発明が解決しようとする課題】
ここで、図１２において、ＣＰＵ４０が実行しているプロセス４０ａが、排他資源を利用しているとする。また、ＣＰＵ４１，４２が実行しているプロセス４１ａ，４２ａも排他資源を利用しようとしたとする。このとき、ＣＰＵ４１，４２は、プロセス４０ａの排他資源の利用が終了するまで、プロセス４１ａ，４２ａの実行を進めることができない（排他資源の競合）。このため、ＣＰＵ４３のみが、プロセス４３ａの実行を終了し、実行待ちのプロセス４４，４５を実行できる状態にあり並列動作性が低下してしまう。
【０００９】
このように、実行が終了したＣＰＵに次々と実行待ちをしている実行単位を実行させる方法では、排他資源の競合機会が増加した場合、並列動作性が低下してしまうという問題点があった。
【００１０】
また、図１３において、属性‘＃Ａ’を持つプロセス５０ａ，５１ａの排他資源の競合が起こったとする。属性‘＃Ｂ’を持つプロセス５２ａ，５３ａは、ＣＰＵ５２，５３によって実行が確保される。しかし、属性‘＃Ｂ’を持つプロセス５２ａ，５３ａ，５６，５７のＣＰＵ５２，５３による実行が終了しても、実行待ちをしている属性‘＃Ａ’をもつプロセス５４，５５がＣＰＵ５２，５３によって実行されることはなく、ＣＰＵの使用効率が悪い。
【００１１】
このように、実効単位に属性を持たせ、属性ごとに実行単位をＣＰＵに実行させる方法では、排他資源の競合機会を減らすことはできるが、ＣＰＵの使用効率を低下させるという問題点があった。
【００１２】
本発明はこのような点に鑑みてなされたものであり、プロセッサの並列動作性の低下、及び、プロセッサの使用効率の低下を抑えるマルチプロセッサ制御プログラムを提供することを目的とする。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御プログラムにおいて、コンピュータに、いずれかのプロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、前記上限数が前記実行数より多い場合、実行単位の属性ごとに実行できるプロセッサを決めることなく、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行させ、プロセッサによって実行されている実行単位の排他資源に対する競合回数を実行単位の属性ごとに取得し、前記属性ごとに取得した競合回数に応じて、前記テーブルの前記属性に対応するプロセッサを占有できる上限数を変更する、処理を実行させることを特徴とするマルチプロセッサ制御プログラムが提供される。
【００１４】
このようなマルチプロセッサ制御プログラムによれば、実行単位の属性ごとに、実行単位がプロセッサを占有できる上限数を設け、実行単位の属性ごとに実行できるプロセッサを決めることなく、開放状態になったプロセッサに実行単位を実行させる。また、実行単位の排他資源に対する競合回数を実行単位の属性ごとに取得し、属性ごとに取得した競合回数に応じて、プロセッサを占有できる上限数を変更する。
【００１５】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
図１は、本発明の原理を説明する原理図である。
【００１６】
この図においてコンピュータ１は、属性取得手段１０、上限数取得手段１１、テーブル１２、実行数取得手段１３、実行手段１４、属性を有する実行単位１５ａ〜１５ｈ、及び、プロセッサ１６ａ〜１６ｆを有する。
【００１７】
属性取得手段１０は、プロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得する。
上限数取得手段１１は、属性取得手段１０によって取得された実行待ちをしている実行単位の属性に対応する、プロセッサを占有できる上限数をテーブル１２から取得する。
【００１８】
テーブル１２には、実行単位の属性ごとにプロセッサを占有できる上限数が予め登録される。
実行数取得手段１３は、属性取得手段１０によって取得された実行待ちをしている実行単位の属性と、同じ属性を持つ実行単位を実行しているプロセッサの数である実行数を取得する。
【００１９】
実行手段１４は、上限数取得手段１１によって取得されたプロセッサを占有できる上限数が、実行数取得手段１３によって取得されたプロセッサの実行数より多い場合、処理機能が開放状態となっているプロセッサに実行待ちをしていた実行単位を実行させる。
【００２０】
実行単位１５ａ〜１５ｈは、プロセッサによって実行されるプログラム実行単位である。実行単位１５ａは属性‘＃１’を有する。実行単位１５ｂは属性‘＃１’を有する。実行単位１５ｃは属性‘＃２’を有する。実行単位１５ｄは属性‘＃１’を有する。実行単位１５ｅは属性‘＃２’を有する。実行単位１５ｆは属性‘＃１’を有する。実行単位１５ｇは属性‘＃１’を有する。実行単位１５ｈは属性‘＃２’を有する。
【００２１】
プロセッサ１６ａ〜１６ｆは、実行手段１４によって割り当てられる実行単位を実行する。
以下、図１の原理図の動作について説明する。
【００２２】
図１に示すように、プロセッサ１６ａは実行単位１５ａを実行しているとする。プロセッサ１６ｂは実行単位１５ｂを実行しているとする。プロセッサ１６ｃは実行単位１５ｃを実行しているとする。プロセッサ１６ｄは実行単位１５ｄを実行しているとする。プロセッサ１６ｅは実行単位１５ｅを実行しているとする。プロセッサ１６ｆは実行単位１５ｆを実行しているとする。また、実行単位１５ｇ、１５ｈはプロセッサ１６ａ〜１６ｆの実行待ちをしているとする。
【００２３】
ここで、プロセッサ１６ｂが、実行単位１５ｂの実行を終了したとする。プロセッサ１６ｂは、処理機能が開放状態となり、属性取得手段１０は、実行待ちをしている実行単位１５ｇの属性‘＃１’を取得する。
【００２４】
上限数取得手段１１は、実行単位１５ｇの属性＃１に対応する、プロセッサを占有できる上限数をテーブル１２から取得する。ここで、テーブル１２には、属性‘＃１’を有する実行単位がプロセッサを占有できる上限数は‘９９９９’、属性‘＃２’を有する実行単位がプロセッサを占有できる上限数は‘２’と登録されているとする。これによって、上限数取得手段１１は、属性‘＃１’の実行単位がプロセッサを占有できる上限数‘９９９９’を取得する。
【００２５】
ここで、上限数‘９９９９’は、プロセッサ１６ａ〜１６ｆを制限されることなく割り当てられることを示している。これは、コンピュータ１がプロセッサを６個しか搭載していないので、プロセッサを占有できる上限数は最高で‘６’であるためである。
【００２６】
実行数取得手段１３は、属性取得手段１０によって取得された、実行待ちをしている実行単位１５ｇの属性‘＃１’と、同じ実行単位を実行しているプロセッサの実行数を取得する。プロセッサ１６ｂは、開放状態であることを考慮して、属性‘＃１’の実行単位を実行しているプロセッサは、プロセッサ１６ａ，１６ｄ、１６ｆの３個であり、実行数取得手段１３は、実行数‘３’を取得する。
【００２７】
実行手段１４は、上限数取得手段１１によって取得されたプロセッサを占有できる上限数‘９９９９’が、実行数取得手段１３によって取得されたプロセッサの実行数‘３’より多いので、実行待ちをしていた実行単位１５ｇをプロセッサ１６ｂに実行させる。
【００２８】
実行単位１５ｇがプロセッサ１６ｂに割り当てられたことにより、次に、図１において、実行単位１５ｈが実行待ちの状態となる。
ここで、プロセッサ１６ｄが、実行単位１５ｄの実行を終了したとする。すると、プロセッサ１６ｄは、処理機能が開放状態となり、属性取得手段１０は、実行待ちをしている実行単位１５ｈの属性‘＃２’を取得する。
【００２９】
上限数取得手段１１は、実行単位１５ｈの属性‘＃２’に対応する、プロセッサを占有できる上限数をテーブル１２から取得する。先述したように、テーブル１２には、属性‘＃１’を有する実行単位がプロセッサを占有できる上限数は‘９９９９’、属性‘＃２’を有する実行単位がプロセッサを占有できる上限数は‘２’、と登録されている。これによって、上限数取得手段１１は、属性‘＃２’の実行単位がプロセッサを占有できる上限数‘２’を取得する。
【００３０】
実行数取得手段１３は、属性取得手段１０によって取得された、実行待ちをしている実行単位１５ｈの属性‘＃２’と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得する。プロセッサ１６ｄは、現在、開放状態であること、及び、先述の説明よりプロセッサ１６ｂは、属性‘＃１’の実行単位１５ｇを実行していることを考慮して、属性‘＃２’の実行単位を実行しているプロセッサは、プロセッサ１６ｃ，１６ｅの２個であり、実行数取得手段１３は、実行数‘２’を取得する。
【００３１】
実行手段１４は、上限数取得手段１１によって取得されたプロセッサを占有できる上限数‘２’が、実行数取得手段１３によって取得されたプロセッサの実行数‘２’と同数であるので、実行待ちをしていた実行単位１５ｈをプロセッサ１６ｄに実行させない。
【００３２】
このように、実行単位の属性ごとに、プロセッサを占有できる上限数を設けて、実行単位の競合機会を抑え、実行単位の属性ごとに実行できるプロセッサを決めることなく、開放状態になったプロセッサに実行単位を実行させるようにしたので、プロセッサの並列動作性、及び、使用効率の低下を抑えることができる。
【００３３】
次に、本発明の実施の形態を実現するためのハードウェア構成について説明する。
図２は、本発明の実施の形態を実現するためのコンピュータのハードウェア構成例である。
【００３４】
図に示すように、コンピュータ２は、ＣＰＵ２０ａ〜２０ｆ、各ＣＰＵ２０ａ〜２０ｆに接続されたＲＡＭ(Random Access Memory)２０ａａ〜２０ａｆ、ハードディスクドライブ(ＨＤＤ:Hard Disk Drive)２０ｇ、入力インタフェース２０ｈ、キーボード２０ｉ、グラフィック処理装置２０ｊ、モニタ２０ｋ、通信インタフェース２０ｌ、及び、バス２０ｍとから構成される。
【００３５】
ＲＡＭ２０ａａ〜２０ａｆには、各ＣＰＵ２０ａ〜２０ｆが実行するプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ２０ａａ〜２０ａｆには、各ＣＰＵ２０ａ〜２０ｆによる処理に必要な各種データが保存される。
【００３６】
ＨＤＤ２０ｇには、ＣＰＵ２０ａ〜２０ｆの並列動作を制御するためのプログラムなどが格納される。ＣＰＵ２０ａ〜２０ｆは、ＨＤＤ２０ｇの並列動作を制御するためのプログラムに従って、スレッドなどのプログラムの実行単位を実行する。
【００３７】
入力インタフェース２０ｈには、キーボード２０ｉが接続されている。入力インタフェース２０ｈは、キーボード２０ｉから送られてくる信号を、バス２０ｍを介してＣＰＵ２０ａ〜２０ｆに送信する。
【００３８】
グラフィック処理装置２０ｊには、モニタ２０ｋが接続されている。グラフィック処理装置２０ｊは、ＣＰＵ２０ａ〜２０ｆからの命令に従って、画像をモニタ２０ｋの表示画面に表示させる。
【００３９】
通信インタフェース２０ｌは、ネットワーク２０ｎに接続されている。通信インタフェース２０ｌは、ネットワーク２０ｎを介して、コンピュータ２を他の装置と通信可能にする。
【００４０】
バス２０ｍは、ＣＰＵ２０ａ〜２０ｆ、ＨＤＤ２０ｇ、入力インタフェース２０ｈ、グラフィック処理装置２０ｊ、及び、通信インタフェース２０ｌを接続する。
【００４１】
なお、上記説明では各ＣＰＵにＲＡＭが接続されたハードウェア構成を示したが、ＣＰＵ全体に対し１個のＲＡＭを共有するハードウェア構成でもよく、また、ＣＰＵの数より少ない複数のＲＡＭを用いたハードウェア構成でもよい。
【００４２】
次に、本発明の実施の形態を実現するためのコンピュータの機能について説明する。
図３は、本発明の実施の形態を実現するためのコンピュータの機能ブロック図である。
【００４３】
図に示すコンピュータ２は、ＣＰＵ２０ａ〜２０ｆ、属性取得部２１、上限数取得部２２、上限数テーブル２３、実行数取得部２４、ＣＰＵ割り当て制御部２５、カーネルＡ２６ａ、カーネルＢ２６ｂ、競合計数部２７、設定情報テーブル２８、実行待ちキュー２９、ＯＳ(Operating System)３０ａ、ＯＳ３０ｂ、及び、属性を有するスレッド３１ａ〜３１ｊとを有する。
【００４４】
属性取得部２１は、ＣＰＵ２０ａ〜２０ｆが開放状態のとき、実行待ちキュー２９の先頭（詳細は後述）で実行待ちをしているスレッドの属性を取得する。
上限数取得部２２は、属性取得部２１によって取得された、実行待ちをしているスレッドの属性に対応する、ＣＰＵを占有できる数である上限数を上限数テーブル２３から取得する。
【００４５】
上限数テーブル２３は、スレッドの属性ごとにＣＰＵを占有できる上限数を登録する。
実行数取得部２４は、属性取得部２１によって取得された実行待ちのスレッドの属性と同じ属性をもつスレッドを実行しているＣＰＵの数である実行数を取得する。
【００４６】
ＣＰＵ割り当て制御部２５は、上限数取得部２２によって取得された上限数が、実行数取得部２４によって取得された実行数より多い場合、処理機能が開放状態となっているＣＰＵに、実行待ちキュー２９の先頭で実行待ちをしているスレッドを割り当てる。また、ＣＰＵ割り当て制御部２５は、上限数取得部２２によって取得された上限数が、実行数取得部２４によって取得された実行数以下である場合、実行待ちキュー２９の先頭で実行待ちをしているスレッドを末尾で実行待ちをさせる。
【００４７】
カーネルＡ２６ａ、カーネルＢ２６ｂは、スレッドが特定の処理を実現するときに利用するプログラムである。カーネルＡ２６ａ、カーネルＢ２６ｂは、排他資源であり、あるスレッドがカーネルＡ２６ａ、又は、カーネルＢ２６ｂを利用しているとき、他のスレッドは、カーネルＡ２６ａ、カーネルＢ２６ｂを利用することはできず、スレッドの競合が生じる場合がある。
【００４８】
競合計数部２７は、スレッドのカーネルＡ２６ａ、カーネルＢ２６ｂへの単位時間当たりの競合回数を属性ごとにカウントする。また、競合計数部２７は、設定情報テーブル２８を参照し、スレッドのカーネルＡ２６ａ、カーネルＢ２６ｂへの競合回数に応じた、ＣＰＵを占有できる上限数を取得して、上限数テーブル２３のＣＰＵを占有できる上限数を変更する。
【００４９】
設定情報テーブル２８は、スレッドの属性ごとに、カーネルＡ２６ａ、カーネルＢ２６ｂの競合する回数に対応した、ＣＰＵを占有できる上限数を登録する。実行待ちキュー２９は、ＯＳ３０ａ，３０ｂから生成されたスレッドを、ＣＰＵの割り当てが必要となった順にＣＰＵ割り当て制御部２５に処理されるようにスレッドを管理する。ここで、実行待ちキューの構造について説明する。図４は、実行待ちキューの構造を示した図である。図に示すように、実行待ちキュー２９は、キュー管理部２９ａを有する。キュー管理部２９ａは、ＯＳ３０ａ，３０ｂから生成されたスレッドをＣＰＵの割り当てが必要となった順に先頭方向へスレッドを順番に並べる。図４においては、スレッド３１ｇが先にＣＰＵの割り当てが必要となったスレッドであり、スレッド３１ｈが後にＣＰＵの割り当てが必要となったスレッドである。スレッド３１ｇが実行待ちをしている先頭であり、スレッド３１ｈが実行待ちをしている末尾である。
【００５０】
ＯＳ３０ａ，３０ｂは、プログラムの実行単位であるスレッドを生成し、実行待ちキュー２９に送り出す。このとき、ＯＳ３０ａ、３０ｂは、ＯＳ３０ａ、３０ｂの種別を示す‘ＯＳ＃１’，‘ＯＳ＃２’を、スレッドの属性として付与する。
【００５１】
スレッド３１ａ〜３１ｊは、プログラムの実行単位である。スレッド３１ａは属性‘ＯＳ＃２’を有する。スレッド３１ｂは属性‘ＯＳ＃１’を有する。スレッド３１ｃは属性‘ＯＳ＃１’を有する。スレッド３１ｄは属性‘ＯＳ＃２’を有する。スレッド３１ｅは属性‘ＯＳ＃１’を有する。スレッド３１ｆは属性‘ＯＳ＃１’を有する。スレッド３１ｇは属性‘ＯＳ＃２’を有する。スレッド３１ｈは属性‘ＯＳ＃１’を有する。スレッド３１ｉは属性‘ＯＳ＃２’を有する。スレッド３１ｊは属性‘ＯＳ＃１’を有する。
【００５２】
ここで、スレッドの構造について説明する。図５は、スレッドの構造を示した図である。スレッド３１ａは、プログラム管理領域３１ａａとスレッド管理テーブル領域３１ａｂに分かれる。プログラム管理領域３１ａａは、さらにアプリケーションプログラムを格納するプログラム領域３１ａａａと、アプリケーションプログラムが使用するデータを格納するデータ領域３１ａａｂに分かれる。スレッド管理テーブル領域３１ａｂは、さらにスレッドの属性を格納する属性領域３１ａｂａとＣＰＵのレジスタ値を格納するレジスタ退避域３１ａｂｂとＯＳが使用するデータを格納するデータ領域３１ａｂｃに分かれる。レジスタ退避域３１ａｂｂには、例えば、スレッド３１ａの実行が中断されたときのＣＰＵのレジスタ値（例えば、ＣＰＵのレジスタＡ・・・レジスタＥの値）が格納される。そして、次回スレッド３１ａがＣＰＵによって実行されるとき、レジスタ退避域３１ａｂｂに格納されているレジスタ値がＣＰＵのレジスタに展開されて実行される。
【００５３】
以下に、図３に示すコンピュータの機能ブロック図の処理の流れについて説明する。
図３に示すように、ＣＰＵ２０ａはスレッド３１ａを実行しているとする。ＣＰＵ２０ｂはスレッド３１ｂを実行しているとする。ＣＰＵ２０ｃはスレッド３１ｃを実行しているとする。ＣＰＵ２０ｄはスレッド３１ｄを実行しているとする。ＣＰＵ２０ｅはスレッド３１ｅを実行しているとする。ＣＰＵ２０ｆはスレッド３１ｆを実行しているとする。また、スレッド３１ｇ、スレッド３１ｈは、実行待ちキュー２９で実行待ちをしているとする。
【００５４】
ここで、ＣＰＵ２０ｂがスレッド３１ｂの実行を終了し、切り離したとする。するとＣＰＵ２０ｂは、処理機能が開放状態となる。図６は、ＣＰＵのスレッド処理の遷移状態を説明する図（その１）である。ＣＰＵ２０ａ，ＣＰＵ２０ｃ〜２０ｆは、スレッド３１ａ，スレッド３１ｃ〜３１ｆを実行し、ＣＰＵ２０ｂは、スレッドを実行していない状態（開放状態）を示す。
【００５５】
ＣＰＵ２０ｂが開放状態になると、属性取得部２１は、実行待ちキュー２９の先頭で実行待ちをしているスレッド３１ｇの属性‘ＯＳ＃２’を取得する。
上限数取得部２２は、上限数テーブル２３から、実行待ちキュー２９の先頭で実行待ちをしているスレッド３１ｇの属性‘ＯＳ＃２’に対応する、ＣＰＵを占有できる上限数を取得する。図７は、上限数テーブルに登録されている情報の一例を示した図である。図の上限数テーブル２３には、属性‘ＯＳ＃１’に対応するプロセッサを占有できる上限数として‘４’、属性‘ＯＳ＃２’に対応するプロセッサを占有できる上限数として‘２’が登録されている。
【００５６】
図７より、上限数取得部２２は、属性‘ＯＳ＃２’に対応する、ＣＰＵを占有できる上限数‘２’を取得する。
実行数取得部２４は、属性取得部２１によって取得された、実行待ちをしているスレッド３１ｇの属性‘ＯＳ＃２’と同じ属性をもつスレッドを実行しているＣＰＵの数を取得する。図６において、ＣＰＵ２０ａ，２０ｄが属性‘ＯＳ＃２’を有するスレッド３１ａ，３１ｄを実行しているので、実行数取得部２４は、実行数‘２’を取得する。
【００５７】
上限数取得部２２によって取得された上限数は‘２’であり、属性‘ＯＳ＃２’を有するスレッドをＣＰＵに割り当てることのできる数は最大‘２’である。実行数取得部２４によって取得された実行数は‘２’であり、すでにＣＰＵには属性‘ＯＳ＃２’を有するスレッドが‘２’割り当てられている。これによって、ＣＰＵ割り当て制御部２５は、実行待ちをしていたスレッド３１ｇを開放状態にあるＣＰＵ２０ｂに実行させない。
【００５８】
ＣＰＵ割り当て制御部２５は、実行待ちキュー２９の先頭で実行待ちをしていたスレッド３１ｇを、そのままの順番で実行待ちするように保持し、次の実行待ちをしているスレッド３１ｈを見に行く。
【００５９】
ＣＰＵ２０ｂは、まだ開放状態にあるので、属性取得部２１は、実行待ちキュー２９で実行待ちをしているスレッド３１ｈの属性‘ＯＳ＃１’を取得する。
上限数取得部２２は、実行待ちキュー２９で実行待ちをしているスレッド３１ｈの属性‘ＯＳ＃１’に対応する、ＣＰＵを占有できる上限数を上限数テーブル２３から取得する。図７より、上限数取得部２２は、属性‘ＯＳ＃１’に対応するＣＰＵを占有できる上限数‘４’を取得する。
【００６０】
実行数取得部２４は、属性取得部２１によって取得された、実行待ちをしているスレッド３１ｈの属性‘ＯＳ＃１’と同じ属性をもつスレッドを実行しているＣＰＵの数を取得する。図６において、ＣＰＵ２０ｃ，２０ｅ，２０ｆが属性‘ＯＳ＃１’のスレッドを実行しているので、実行数取得部２４は、実行数‘３’を取得する。
【００６１】
上限数取得部２２によって取得された上限数は‘４’であり、属性‘ＯＳ＃１’のスレッドをＣＰＵに割り当てることのできる数は最大‘４’である。実行数取得部２４によって取得された実行数‘３’であり、スレッド３１ｈを開放状態にあるＣＰＵ２０ｂに割り当てることができる。図８は、ＣＰＵのスレッド処理の遷移状態を説明する図（その２）である。図に示すように、ＣＰＵ２０ｂに、スレッド３１ｈが割り当てられる。
【００６２】
次に、図３の機能ブロック図における上限数テーブル２３の上限数の変更処理の流れについて説明する。
競合計数部２７は、スレッド３１ａ〜３１ｆのカーネルＡ２６ａ、カーネルＢ２６ｂへの競合回数をカウントし、設定情報テーブル２８を参照して、上限数テーブル２３のＣＰＵを占有できる上限数を変更する。
【００６３】
図９は、設定情報テーブルに登録されている情報の一例を示した図である。図に示す設定情報テーブル２８には、属性“ＯＳ＃１”を有するスレッドのカーネルＡ２６ａに対する競合が１秒間に５０００回以上であれば、ＣＰＵを占有できる上限数は‘２’という情報が登録されている。同様に、競合が１秒間に１０００回以上５０００回未満であれば上限数は‘３’、競合が１秒間に１０００回未満であれば上限数は‘４’という情報が登録されている。また、属性“ＯＳ＃２”を有するスレッドのカーネルＢ２６ｂに対する競合が１秒間に７０００回以上であれば、ＣＰＵを占有できる上限数は‘２’、競合が１秒間に５０００回未満であれば上限数は‘３’という情報が登録されている。
【００６４】
ここで、図３に示す属性‘ＯＳ＃１’を有するスレッド３１ｂ，３１ｃ，３１ｅ，３１ｆによるカーネルＡ２６ａへの競合が１秒間に５０００回以上発生したとする。競合計数部２７は、設定情報テーブル２８より、属性‘ＯＳ＃１’を有するスレッドの競合回数５０００回以上に対応するＣＰＵ上限数‘２’を取得し、図７に示した上限数テーブル２３の属性‘ＯＳ＃１’に対応するＣＰＵの上限数を‘２’に変更する。同様に、競合回数が１秒間に１０００回以上５０００回未満であれば、競合計数部２７は、設定情報テーブル２８からＣＰＵ上限数‘３’を取得し、上限数テーブル２３の属性‘ＯＳ＃１’に対応するＣＰＵの上限数を‘３’に変更する。１０００回未満であれば、競合計数部２７は、設定情報テーブル２８からＣＰＵ上限数‘４’を取得し、上限数テーブル２３の属性‘ＯＳ＃１’に対応するＣＰＵの上限数を‘４’に変更する。
【００６５】
同様に、競合計数部２７は、カーネルＢ２６ｂに対する属性‘ＯＳ＃２’を有するスレッド３１ａ，３１ｄの競合回数をカウントし、上限数テーブル２３のＣＰＵ上限数を変更する。カーネルＢ２６ｂへの競合が１秒間に７０００回以上であれば、競合計数部２７は、設定情報テーブル２８を参照して、属性‘ＯＳ＃２’の競合回数７０００回以上に対応するＣＰＵ上限数‘２’を取得し、上限数テーブル２３の属性‘ＯＳ＃２’に対応するＣＰＵ上限数を‘２’に変更する。４０００回未満であれば、ＣＰＵ上限数を‘３’に変更する。
【００６６】
属性‘ＯＳ＃２’のカーネルＢ２６ｂに対する競合回数が４０００回以上７０００回未満であれば、競合計数部２７は、上限数テーブル２３のＣＰＵ上限数を変更しない。ＣＰＵ上限数の変更に履歴を持たせ、ＣＰＵの上限数が頻繁に変更されることを防止する。
【００６７】
次に、コンピュータ２の処理の流れについてフローチャートを用いて説明する。
図１０は、コンピュータのスレッドの割り当て処理を示したフローチャートである。このフローチャートが開始されると以下の処理が行われる。
【００６８】
［ステップＳ１０］属性取得部２１は、ＣＰＵ２０ａ〜２０ｆのいずれかの処理機能が開放状態のとき、実行待ちキュー２９の先頭で実行待ちをしているスレッド３１ｇの属性を取得する。
【００６９】
［ステップＳ１１］上限数取得部２２は、スレッドの属性ごとにＣＰＵ２０ａ〜２０ｆを占有できる上限数を登録した上限数テーブル２３から、スレッド３１ｇの属性に対応するＣＰＵ２０ａ〜２０ｆを占有できる上限数を取得する。
【００７０】
［ステップＳ１２］実行数取得部２４は、スレッド３１ｇと同じ属性を持つスレッドを実行しているＣＰＵ２０ａ〜２０ｆの実行数を取得する。
［ステップＳ１３］ＣＰＵ割り当て制御部２５は、ステップＳ１１で取得した上限数と、ステップＳ１２で取得した実行数を比較し、上限数が、実行数より多い場合、ステップＳ１４へ進む。上限数が、実行数以下である場合、ステップＳ１５へ進む。
【００７１】
［ステップＳ１４］ＣＰＵ割り当て制御部２５は、実行待ちキュー２９の先頭で実行待ちをしているスレッド３１ｇを開放状態にあるＣＰＵ２０ａ〜２０ｆに実行させる。
【００７２】
［ステップＳ１５］ＣＰＵ割り当て制御部２５は、実行待ちキュー２９の先頭で実行待ちをしているスレッド３１ｇを実行待ちキュー２９のそのままの位置で実行待ちをさせ、実行待ちキュー２９の次の実行待ちをしているスレッド３１ｈを見に行き、ステップＳ１０に戻る。
【００７３】
図１１は、コンピュータのプロセッサ上限数の変更処理を示したフローチャートである。このフローチャートが開始されると以下の処理が行われる。
［ステップＳ２０］競合計数部２７は、スレッド３１ａ〜３１ｆのカーネルＡ２６ａ、カーネルＢ２６ｂへの競合回数をスレッド３１ａ〜３１ｆの属性ごとに取得する。
【００７４】
［ステップＳ２１］競合計数部２７は、競合回数に応じてＣＰＵ２０ａ〜２０ｆの占有できる上限数を登録した設定情報テーブル２８から、ステップＳ２０で取得した競合回数に対応する、ＣＰＵ２０ａ〜２０ｆを占有できる上限数を取得する。
【００７５】
［ステップＳ２２］競合計数部２７は、上限数テーブル２３のＣＰＵ２０ａ〜２０ｆを占有できる上限数を、ステップＳ２１で取得したＣＰＵ２０ａ〜２０ｆを占有できる上限数に変更する。
【００７６】
このように、スレッドの属性ごとに、ＣＰＵを占有できる上限を設けたので、排他資源の競合機会が増加することがなく、並列動作性の低下を抑制することができ、スレッドの属性ごとに実行できるＣＰＵを決めることなく、開放状態になったＣＰＵにスレッドを割り当てるようにしたのでプロセッサの使用効率の低下を抑えることができる。
【００７７】
また、スレッドの排他資源であるカーネルへの競合をリアルタイムに監視し、競合回数が多い場合、スレッドのＣＰＵを占有できる上限数を減らし、競合回数が少ない場合、スレッドのＣＰＵを占有できる上限数を増加するようにしたので、ＣＰＵの並列動作性、使用効率を最適の状態にコントロールすることができる。また、スレッドの属性に対応したＣＰＵの割り当て数のチューニングを不要とすることができる。
【００７８】
なお、上記の説明において、ＣＰＵが実行する実行単位をスレッドとして説明したが、プロセスや、ＬＷＰ(Light Weight Process)などのプログラム実行単位であってもよい。また、属性をＯＳの種別としたが、ＯＳ上で動作するアプリケーションの種別によって属性を付与してもよい。また、ＯＳ、アプリケーションの種別によらず、プログラムの実行単位の内容に応じたフラグや、特定の値、名前などの属性を付与してもよい。さらに、スレッドの排他資源への競合回数をカウントして、ＣＰＵを占有できる上限数を変更するようにしたが、スレッドが排他資源をロック（あるスレッドが排他資源を利用している状態）している時間を計測し、ロックした時間に応じてＣＰＵを占有できる上限数を変更するようにしてもよい。また、競合回数のカウント、ＣＰＵを占有できる上限数の変更を一定の周期で行うようにしてもよい。
【００７９】
また、上記の各コンピュータが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述させておくことができる。このプログラムをコンピュータで実行することにより、上記処理がコンピュータで実現できる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリなどがある。市場に流通させる場合には、ＣＤ−ＲＯＭやフレキシブルディスクなどの可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置などにプログラムを格納しておき、メインメモリにロードして実行する。
【００８０】
（付記１） 複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御プログラムにおいて、
コンピュータに、
プロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、
前記上限数が前記実行数より多い場合、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行させる、
処理を実行させることを特徴とするマルチプロセッサ制御プログラム。
【００８１】
（付記２） プロセッサによって実行されている実行単位の排他資源に対する競合回数を前記実行単位の属性ごとに取得し、
前記属性ごとに取得した競合回数に応じて、前記テーブルの前記属性に対応するプロセッサを占有できる上限数を変更する、
処理をさらに実行させることを特徴とする付記１記載のマルチプロセッサ制御プログラム。
【００８２】
（付記３） 前記実行待ちをしている実行単位はキュー構造により管理され、前記上限数が前記実行数以下の場合、前記実行待ちをしている実行単位を前記キュー構造のそのままの位置で実行待ちをさせ、前記実行待ちをしている実行単位の次に実行待ちをしている実行単位に前記処理を実行させることを特徴とする付記１記載のマルチプロセッサ制御プログラム。
【００８３】
（付記４） 前記実行単位の属性はオペレーションシステムの種別であることを特徴とする付記１記載のマルチプロセッサ制御プログラム。
（付記５） 複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御方法において、
プロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、
前記上限数が前記実行数より多い場合、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行する、
ことを特徴とするマルチプロセッサ制御方法。
【００８４】
（付記６） 複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御装置において、
プロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得する属性取得手段と、
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得する上限数取得手段と、
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得する実行数取得手段と、
前記上限数が前記実行数より多い場合、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行する実行手段と、
を有することを特徴とするマルチプロセッサ制御装置。
【００８５】
（付記７） 複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御プログラムを記録したコンピュータ読み取り可能な記録媒体において、
コンピュータに、
プロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、
前記上限数が前記実行数より多い場合、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行させる、
処理を実行させることを特徴とするマルチプロセッサ制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【００８６】
【発明の効果】
以上説明したように本発明では、コンピュータに、実行単位の属性ごとに、実行単位がプロセッサを占有できる上限数を設け、実行単位の属性ごとに実行できるプロセッサを決めることなく、開放状態になったプロセッサに実行単位を実行させる。また、実行単位の排他資源に対する競合回数を実行単位の属性ごとに取得し、属性ごとに取得した競合回数に応じて、プロセッサを占有できる上限数を変更する。これにより、プロセッサの並列動作性の低下及び使用効率の低下を抑えることができ、また、並列動作性及び使用効率を最適の状態に制御することができる。
【図面の簡単な説明】
【図１】本発明の原理を説明する原理図である。
【図２】本発明の実施の形態を実現するためのコンピュータのハードウェア構成例である。
【図３】本発明の実施の形態を実現するためのコンピュータの機能ブロック図である。
【図４】実行待ちキューの構造を示した図である。
【図５】スレッドの構造を示した図である。
【図６】ＣＰＵのスレッド処理の遷移状態を説明する図（その１）である。
【図７】上限数テーブルに登録されている情報の一例を示した図である。
【図８】ＣＰＵのスレッド処理の遷移状態を説明する図（その２）である。
【図９】設定情報テーブルに登録されている情報の一例を示した図である。
【図１０】コンピュータのスレッドの割り当て処理を示したフローチャートである。
【図１１】コンピュータのプロセッサ上限数の変更処理を示したフローチャートである。
【図１２】従来のマルチＣＰＵシステムの動作（その１）を説明する図である。
【図１３】従来のマルチＣＰＵシステムの動作（その２）を説明する図である。
【符号の説明】
１，２ コンピュータ
１０ 属性取得手段
１１ 上限数取得手段
１２ テーブル
１３ 実行数取得手段
１４ 実行手段
１５ａ〜１５ｈ 実行単位
１６ａ〜１６ｆ プロセッサ
２０ａ〜２０ｆ ＣＰＵ
２１ 属性取得部
２２ 上限数取得部
２３ 上限数テーブル
２４ 実行数取得部
２５ ＣＰＵ割り当て制御部
２６ａ カーネルＡ
２６ｂ カーネルＢ
２７ 競合計数部
２８ 設定情報テーブル
２９ 実行待ちキュー
３０ａ，３０ｂ ＯＳ
３１ａ〜３１ｊ スレッド[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a multiprocessor control program and a multiprocessor control method, and more particularly, to a multiprocessor control program and a multiprocessor control method for controlling a plurality of processors that execute a plurality of execution units assigned attributes.
[0002]
[Prior art]
Currently, there are various techniques for improving the data processing capability of a computer. Among such technologies, there is a multi-CPU system that improves data processing capability by sharing data processing by a plurality of CPUs (Central Processing Units) and performing parallel processing.
[0003]
There are the following two methods for causing the multi-CPU system to process data in parallel. The first is a method in which execution units of programs such as processes and threads are executed by a plurality of CPUs, and execution units waiting for execution are successively executed by CPUs that have completed execution. The second is to assign an attribute to an execution unit, determine a plurality of CPUs that execute the execution unit for each attribute, cause the CPU to execute the execution unit, and have an attribute that the CPU can execute in order from the CPU that has finished executing. This is a method for executing execution units waiting for execution.
[0004]
FIG. 12 is a diagram for explaining the operation (part 1) of the conventional multi-CPU system. The multi-CPU system shown in the figure has four CPUs 40 to 43. The CPUs 40 to 43 execute processes 40a to 43a, which are program execution units. Processes 44 and 45 are waiting for execution of CPUs 40-43.
[0005]
If the CPU 41 finishes executing the process 41a, the process 41 waiting for execution is executed by the CPU 41. If the CPU 42 finishes executing the process 42a, the CPU 42 executes the process 45 waiting for execution. In this way, the CPU that ends the execution of the process and disconnects the process sequentially executes the processes waiting for execution.
[0006]
FIG. 13 is a diagram for explaining the operation (part 2) of the conventional multi-CPU system. The multi-CPU system shown in the figure includes CPUs 50 and 51 that execute processes having an attribute “#A”, and CPUs 52 and 53 that execute processes having an attribute “#B”. The CPU 50 and CPU 51 execute processes 50a and 51b having the attribute '#A', and the CPU 52 and CPU 53 execute processes 52a and 53a having the attribute '#B'. Further, the processes 54 and 55 having the attribute “#A” are waiting for the execution of the CPUs 50 and 51, and the processes 56 and 57 having the attribute “#B” are waiting for the execution of the CPUs 52 and 53.
[0007]
If the CPU 50 finishes executing the process 50a, the CPU 50 executes the process 54 having the attribute “#A” waiting for execution. If the CPU 52 finishes executing the process 52 a, the CPU 52 executes the process 56 having the attribute “#B” waiting for execution. In this way, attributes are assigned to processes, the CPU that executes the process is determined for each attribute, and the CPU that ends the process execution and detaches the process executes the processes waiting for execution of the determined attribute in order. I will do it.
[0008]
[Problems to be solved by the invention]
Here, in FIG. 12, it is assumed that the process 40a executed by the CPU 40 uses the exclusive resource. Further, it is assumed that the processes 41a and 42a executed by the CPUs 41 and 42 also try to use exclusive resources. At this time, the CPUs 41 and 42 cannot advance the execution of the processes 41a and 42a until the use of the exclusive resources of the process 40a is completed (exclusive resource conflict). For this reason, only the CPU 43 is in a state where the execution of the process 43a is completed and the processes 44 and 45 waiting for execution can be executed, and the parallel operability deteriorates.
[0009]
As described above, in the method in which the execution units that are waiting for execution are executed one after another by the CPU that has finished executing, there is a problem in that parallel operability deteriorates when the opportunity for exclusive resource contention increases. .
[0010]
Further, in FIG. 13, it is assumed that a conflict of exclusive resources of the processes 50a and 51a having the attribute “#A” occurs. Execution of the processes 52 a and 53 a having the attribute “#B” is ensured by the CPUs 52 and 53. However, even if the execution of the processes 52a, 53a, 56, and 57 having the attribute '#B' by the CPUs 52 and 53 is completed, the processes 54 and 55 having the attribute '#A' waiting for execution remain in the CPUs 52 and 53. The CPU is not used efficiently.
[0011]
As described above, in the method in which the effective unit has an attribute and the execution unit is executed by the CPU for each attribute, the opportunity for exclusive resource contention can be reduced, but there is a problem in that the CPU usage efficiency is lowered. .
[0012]
The present invention has been made in view of these points, and an object of the present invention is to provide a multiprocessor control program that suppresses a decrease in parallel operability of processors and a decrease in use efficiency of processors.
[0013]
[Means for Solving the Problems]
  To solve the above problem,In a multiprocessor control program that controls multiple processors that execute multiple execution units, when the processing functions of any processor are in the open state, the execution unit attributes that are waiting for execution are acquired and executed by the computer. Execution of a processor that executes the execution unit having the same attribute as the acquired attribute, by acquiring the upper limit number corresponding to the acquired attribute from a table in which the upper limit number that can occupy the processor for each unit attribute is registered. When the number is acquired and the upper limit number is larger than the execution number, the execution unit waiting for execution is executed by the processor in the open state without determining a processor that can be executed for each attribute of the execution unit, and the processor For each attribute of the execution unit, obtain the number of times of contention for the exclusive resource of the execution unit executed by According to the acquired competing number, it changes the upper limit number can occupy the processor corresponding to the attribute of the table,It is characterized by having processing executedA multiprocessor control program is provided.
[0014]
  According to such a multiprocessor control program,For each attribute of the execution unit, an upper limit number that the execution unit can occupy the processor is provided, and the execution unit is executed by the processor in the open state without determining the processor that can be executed for each attribute of the execution unit. Further, the number of times of contention for the exclusive resource of the execution unit is acquired for each attribute of the execution unit, and the upper limit number that can occupy the processor is changed according to the number of times of contention acquired for each attribute.
[0015]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a principle diagram illustrating the principle of the present invention.
[0016]
In this figure, the computer 1 has attribute acquisition means 10, upper limit number acquisition means 11, table 12, execution number acquisition means 13, execution means 14, execution units 15a to 15h having attributes, and processors 16a to 16f.
[0017]
The attribute acquisition unit 10 acquires an attribute of an execution unit waiting for execution when the processing function of the processor is in an open state.
The upper limit number acquisition unit 11 acquires from the table 12 the upper limit number that can occupy the processor corresponding to the execution unit attribute waiting for execution acquired by the attribute acquisition unit 10.
[0018]
In the table 12, the upper limit number that can occupy the processor is registered in advance for each attribute of the execution unit.
The execution number acquisition unit 13 acquires the number of executions that is the number of processors that are executing execution units having the same attribute as the attribute of the execution unit waiting for execution acquired by the attribute acquisition unit 10.
[0019]
If the upper limit number that can occupy the processor acquired by the upper limit number acquisition unit 11 is greater than the execution number of the processor acquired by the execution number acquisition unit 13, the execution unit 14 determines whether the processor has an open processing function. Execute the execution unit that was waiting for execution.
[0020]
The execution units 15a to 15h are program execution units executed by the processor. The execution unit 15a has the attribute “# 1”. The execution unit 15b has the attribute “# 1”. The execution unit 15c has the attribute “# 2”. The execution unit 15d has the attribute “# 1”. The execution unit 15e has an attribute “# 2”. The execution unit 15f has an attribute “# 1”. The execution unit 15g has the attribute “# 1”. The execution unit 15h has an attribute “# 2”.
[0021]
The processors 16a to 16f execute execution units assigned by the execution means 14.
The operation of the principle diagram of FIG. 1 will be described below.
[0022]
As shown in FIG. 1, it is assumed that the processor 16a is executing the execution unit 15a. It is assumed that the processor 16b is executing the execution unit 15b. Assume that the processor 16c is executing the execution unit 15c. It is assumed that the processor 16d is executing the execution unit 15d. It is assumed that the processor 16e is executing the execution unit 15e. It is assumed that the processor 16f is executing the execution unit 15f. Further, it is assumed that the execution units 15g and 15h are waiting for execution of the processors 16a to 16f.
[0023]
Here, it is assumed that the processor 16b has finished executing the execution unit 15b. The processor 16b is in a released state, and the attribute acquisition unit 10 acquires the attribute “# 1” of the execution unit 15g waiting for execution.
[0024]
The upper limit number acquisition unit 11 acquires the upper limit number that can occupy the processor corresponding to the attribute # 1 of the execution unit 15g from the table 12. Here, in the table 12, the upper limit number that the execution unit having the attribute “# 1” can occupy the processor is “9999”, and the upper limit number that the execution unit having the attribute “# 2” can occupy the processor is “2”. Suppose that it is registered. Accordingly, the upper limit number acquisition unit 11 acquires the upper limit number “9999” that can be occupied by the execution unit of the attribute “# 1”.
[0025]
Here, the upper limit number '9999' indicates that the processors 16a to 16f can be assigned without being restricted. This is because the computer 1 has only six processors and the maximum number that can occupy the processors is ‘6’.
[0026]
The execution number acquisition unit 13 acquires the execution number of the processor executing the same execution unit as the attribute ‘# 1’ of the execution unit 15g waiting for execution acquired by the attribute acquisition unit 10. Considering that the processor 16b is in an open state, there are three processors 16a, 16d, and 16f that are executing the execution unit of the attribute “# 1”. Get the number '3'.
[0027]
The execution means 14 waits for execution because the upper limit number “9999” that can occupy the processor acquired by the upper limit number acquisition means 11 is larger than the execution number “3” of the processor acquired by the execution number acquisition means 13. The execution unit 15g is executed by the processor 16b.
[0028]
Since the execution unit 15g is assigned to the processor 16b, the execution unit 15h is in a state of waiting for execution in FIG.
Here, it is assumed that the processor 16d has finished executing the execution unit 15d. Then, the processor 16d has the processing function released, and the attribute acquisition unit 10 acquires the attribute “# 2” of the execution unit 15h waiting for execution.
[0029]
The upper limit number acquisition unit 11 acquires from the table 12 the upper limit number that can occupy the processor corresponding to the attribute “# 2” of the execution unit 15 h. As described above, the upper limit number that the execution unit having the attribute “# 1” can occupy the processor is “9999” and the upper limit number that the execution unit having the attribute “# 2” can occupy the processor is “2”. ', And registered. Accordingly, the upper limit number acquisition unit 11 acquires the upper limit number “2” that the execution unit of the attribute “# 2” can occupy the processor.
[0030]
The execution number acquisition unit 13 acquires the number of executions of the processor executing the execution unit acquired by the attribute acquisition unit 10 and having the same attribute as the attribute '# 2' of the execution unit 15h waiting for execution. . Considering that the processor 16d is currently in an open state and that the processor 16b is executing the execution unit 15g of the attribute '# 1' from the above description, the execution unit of the attribute '# 2' There are two processors 16c and 16e, and the execution number acquisition means 13 acquires the execution number '2'.
[0031]
The execution unit 14 waits for execution because the upper limit number “2” that can occupy the processor acquired by the upper limit number acquisition unit 11 is the same as the execution number “2” of the processor acquired by the execution number acquisition unit 13. The processor 16d is not allowed to execute the executed execution unit 15h.
[0032]
In this way, for each attribute of the execution unit, an upper limit number that can occupy the processor is set, the competition opportunity of the execution unit is suppressed, and the processor that has been released can be determined without determining the processor that can be executed for each attribute of the execution unit. Since execution units are executed, it is possible to suppress a decrease in processor parallel operation and usage efficiency.
[0033]
Next, a hardware configuration for realizing the embodiment of the present invention will be described.
FIG. 2 is a hardware configuration example of a computer for realizing the embodiment of the present invention.
[0034]
As shown in the figure, the computer 2 includes CPUs 20a to 20f, RAMs (Random Access Memory) 20aa to 20af connected to the CPUs 20a to 20f, a hard disk drive (HDD) 20g, an input interface 20h, a keyboard 20i, The graphics processing device 20j, the monitor 20k, the communication interface 201, and the bus 20m are included.
[0035]
The RAMs 20aa to 20af temporarily store at least part of programs executed by the CPUs 20a to 20f. The RAMs 20aa to 20af store various data necessary for processing by the CPUs 20a to 20f.
[0036]
The HDD 20g stores a program for controlling the parallel operation of the CPUs 20a to 20f. The CPUs 20a to 20f execute program execution units such as threads in accordance with a program for controlling parallel operations of the HDD 20g.
[0037]
A keyboard 20i is connected to the input interface 20h. The input interface 20h transmits a signal transmitted from the keyboard 20i to the CPUs 20a to 20f via the bus 20m.
[0038]
A monitor 20k is connected to the graphic processing device 20j. The graphic processing device 20j displays an image on the display screen of the monitor 20k in accordance with instructions from the CPUs 20a to 20f.
[0039]
The communication interface 20l is connected to the network 20n. The communication interface 201 enables the computer 2 to communicate with other devices via the network 20n.
[0040]
The bus 20m connects the CPUs 20a to 20f, the HDD 20g, the input interface 20h, the graphic processing device 20j, and the communication interface 20l.
[0041]
In the above description, a hardware configuration in which a RAM is connected to each CPU is shown. However, a hardware configuration in which one RAM is shared for the entire CPU may be used, and a plurality of RAMs smaller than the number of CPUs are used. The hardware configuration may be the same.
[0042]
Next, functions of a computer for realizing the embodiment of the present invention will be described.
FIG. 3 is a functional block diagram of a computer for realizing the embodiment of the present invention.
[0043]
The computer 2 shown in the figure includes a CPU 20a to 20f, an attribute acquisition unit 21, an upper limit number acquisition unit 22, an upper limit number table 23, an execution number acquisition unit 24, a CPU allocation control unit 25, a kernel A 26a, a kernel B 26b, a contention counting unit 27, It includes a setting information table 28, an execution waiting queue 29, an OS (Operating System) 30a, an OS 30b, and threads 31a to 31j having attributes.
[0044]
When the CPUs 20a to 20f are in an open state, the attribute acquisition unit 21 acquires the attributes of threads that are waiting for execution at the head of the execution waiting queue 29 (details will be described later).
The upper limit number acquisition unit 22 acquires, from the upper limit number table 23, the upper limit number that can be occupied by the CPU, corresponding to the attribute of the thread waiting for execution, acquired by the attribute acquisition unit 21.
[0045]
The upper limit number table 23 registers the upper limit number that can occupy the CPU for each attribute of the thread.
The execution number acquisition unit 24 acquires the number of executions, which is the number of CPUs that are executing threads having the same attribute as that of the thread waiting for execution acquired by the attribute acquisition unit 21.
[0046]
When the upper limit number acquired by the upper limit number acquisition unit 22 is larger than the execution number acquired by the execution number acquisition unit 24, the CPU allocation control unit 25 sends the waiting queue to the CPU whose processing function is open. A thread waiting for execution at the head of 29 is allocated. Further, when the upper limit number acquired by the upper limit number acquisition unit 22 is equal to or less than the execution number acquired by the execution number acquisition unit 24, the CPU allocation control unit 25 waits for execution at the head of the execution waiting queue 29. Causes the thread to wait for execution at the end.
[0047]
The kernel A 26a and the kernel B 26b are programs used when a thread realizes a specific process. The kernel A 26a and the kernel B 26b are exclusive resources, and when a certain thread uses the kernel A 26a or the kernel B 26b, other threads cannot use the kernel A 26a and the kernel B 26b, and thread contention. May occur.
[0048]
The contention counting unit 27 counts the number of times of contention per unit time for the kernel A26a and kernel B26b of the thread for each attribute. Further, the contention counting unit 27 refers to the setting information table 28, acquires the upper limit number that can occupy the CPU according to the number of times the thread competes with the kernel A26a and the kernel B26b, and occupies the CPU of the upper limit number table 23. Change the maximum number you can.
[0049]
The setting information table 28 registers the upper limit number that can occupy the CPU corresponding to the number of times the kernel A 26a and the kernel B 26b compete for each thread attribute. The execution queue 29 manages the threads generated from the OSs 30a and 30b so that the CPU allocation control unit 25 processes the threads in the order in which the CPU allocation is necessary. Here, the structure of the execution queue will be described. FIG. 4 shows the structure of the execution queue. As shown in the figure, the waiting queue 29 has a queue management unit 29a. The queue management unit 29a arranges the threads generated from the OSs 30a and 30b in order in the order in which the CPU needs to be allocated. In FIG. 4, a thread 31g is a thread that needs to be assigned a CPU first, and a thread 31h is a thread that needs to be assigned a CPU later. The thread 31g is the head waiting for execution, and the thread 31h is the tail waiting for execution.
[0050]
The OSs 30 a and 30 b generate threads that are program execution units and send them to the execution waiting queue 29. At this time, the OSs 30a and 30b assign 'OS # 1' and 'OS # 2' indicating the types of the OSs 30a and 30b as thread attributes.
[0051]
The threads 31a to 31j are program execution units. The thread 31a has the attribute “OS # 2”. The thread 31b has the attribute “OS # 1”. The thread 31c has the attribute “OS # 1”. The thread 31d has the attribute “OS # 2”. The thread 31e has the attribute “OS # 1”. The thread 31f has the attribute “OS # 1”. The thread 31g has the attribute “OS # 2”. The thread 31h has the attribute “OS # 1”. The thread 31i has the attribute “OS # 2”. The thread 31j has an attribute “OS # 1”.
[0052]
Here, the structure of the thread will be described. FIG. 5 is a diagram showing a thread structure. The thread 31a is divided into a program management area 31aa and a thread management table area 31ab. The program management area 31aa is further divided into a program area 31aaa for storing an application program and a data area 31aab for storing data used by the application program. The thread management table area 31ab is further divided into an attribute area 31aba for storing thread attributes, a register save area 31abb for storing CPU register values, and a data area 31abc for storing data used by the OS. The register save area 31abb stores, for example, CPU register values (for example, CPU register A... Register E values) when the execution of the thread 31a is interrupted. Then, when the thread 31a is executed by the CPU next time, the register value stored in the register save area 31abb is expanded into the CPU register and executed.
[0053]
The processing flow of the functional block diagram of the computer shown in FIG. 3 will be described below.
As shown in FIG. 3, it is assumed that the CPU 20a is executing a thread 31a. It is assumed that the CPU 20b is executing the thread 31b. It is assumed that the CPU 20c is executing the thread 31c. It is assumed that the CPU 20d is executing the thread 31d. It is assumed that the CPU 20e is executing the thread 31e. It is assumed that the CPU 20f is executing the thread 31f. Further, it is assumed that the thread 31g and the thread 31h are waiting for execution in the execution waiting queue 29.
[0054]
Here, it is assumed that the CPU 20b finishes executing the thread 31b and disconnects it. Then, the processing function of the CPU 20b is released. FIG. 6 is a diagram (part 1) for explaining a transition state of thread processing of the CPU. The CPU 20a and the CPUs 20c to 20f execute the thread 31a and the threads 31c to 31f, and the CPU 20b indicates a state where the thread is not executed (open state).
[0055]
When the CPU 20 b is released, the attribute acquisition unit 21 acquires the attribute “OS # 2” of the thread 31 g waiting for execution at the head of the execution queue 29.
The upper limit number acquisition unit 22 acquires from the upper limit number table 23 the upper limit number that can occupy the CPU corresponding to the attribute “OS # 2” of the thread 31g waiting for execution at the head of the execution queue 29. FIG. 7 is a diagram illustrating an example of information registered in the upper limit number table. In the upper limit number table 23 in the figure, “4” is registered as the upper limit number that can occupy the processor corresponding to the attribute “OS # 1”, and “2” is registered as the upper limit number that can occupy the processor corresponding to the attribute “OS # 2”. Has been.
[0056]
From FIG. 7, the upper limit number acquisition unit 22 acquires the upper limit number “2” that can occupy the CPU corresponding to the attribute “OS # 2”.
The execution number acquisition unit 24 acquires the number of CPUs that are executing the thread having the same attribute as the attribute “OS # 2” of the thread 31g waiting for execution, acquired by the attribute acquisition unit 21. In FIG. 6, since the CPUs 20 a and 20 d execute the threads 31 a and 31 d having the attribute “OS # 2”, the execution number acquisition unit 24 acquires the execution number “2”.
[0057]
The upper limit number acquired by the upper limit number acquisition unit 22 is “2”, and the maximum number of threads that can be assigned to the CPU having the attribute “OS # 2” is “2”. The number of executions acquired by the execution number acquisition unit 24 is “2”, and a thread having the attribute “OS # 2” is already assigned to the CPU as “2”. As a result, the CPU allocation control unit 25 does not cause the CPU 20b in the released state to execute the thread 31g waiting for execution.
[0058]
The CPU allocation control unit 25 holds the thread 31g waiting for execution at the head of the execution waiting queue 29 so as to wait for execution in the same order, and goes to see the next thread 31h waiting for execution. .
[0059]
Since the CPU 20b is still in the released state, the attribute acquisition unit 21 acquires the attribute “OS # 1” of the thread 31h waiting for execution in the execution queue 29.
The upper limit number acquisition unit 22 acquires from the upper limit number table 23 the upper limit number that can occupy the CPU corresponding to the attribute “OS # 1” of the thread 31 h waiting for execution in the execution waiting queue 29. From FIG. 7, the upper limit number acquiring unit 22 acquires the upper limit number “4” that can occupy the CPU corresponding to the attribute “OS # 1”.
[0060]
The number-of-execution acquisition unit 24 acquires the number of CPUs that are executing the thread having the same attribute as the attribute “OS # 1” of the thread 31 h that is waiting for execution, acquired by the attribute acquisition unit 21. In FIG. 6, since the CPUs 20 c, 20 e, and 20 f are executing the thread with the attribute “OS # 1”, the execution number acquisition unit 24 acquires the execution number “3”.
[0061]
The upper limit number acquired by the upper limit number acquiring unit 22 is “4”, and the maximum number of threads that can be assigned to the CPU with the attribute “OS # 1” is “4”. The number of executions '3' acquired by the execution number acquisition unit 24, and the thread 31h can be assigned to the CPU 20b in the released state. FIG. 8 is a diagram (part 2) for explaining the transition state of the thread processing of the CPU. As shown in the figure, a thread 31h is assigned to the CPU 20b.
[0062]
Next, the flow of processing for changing the upper limit number in the upper limit number table 23 in the functional block diagram of FIG. 3 will be described.
The contention counting unit 27 counts the number of times the threads 31a to 31f compete with the kernel A26a and the kernel B26b, and refers to the setting information table 28 to change the upper limit number that can occupy the CPU in the upper limit number table 23.
[0063]
FIG. 9 is a diagram illustrating an example of information registered in the setting information table. In the setting information table 28 shown in the figure, if the contention of the thread having the attribute “OS # 1” with respect to the kernel A 26a is 5000 times or more per second, information that the upper limit number that can occupy the CPU is “2” is registered. ing. Similarly, if the competition is 1000 times or more and less than 5000 times per second, the upper limit number is “3”, and if the competition is less than 1000 times per second, the upper limit number is “4”. Further, if the thread having the attribute “OS # 2” competes with the kernel B26b for 7000 times or more per second, the upper limit number that can occupy the CPU is “2”, and if the contention is less than 5000 times per second, the upper limit. The number “3” is registered.
[0064]
Here, it is assumed that the thread 31b, 31c, 31e, 31f having the attribute “OS # 1” illustrated in FIG. 3 competes with the kernel A 26a more than 5000 times per second. The contention counting unit 27 acquires from the setting information table 28 the CPU upper limit number “2” corresponding to the number of times the thread having the attribute “OS # 1” is 5000 times or more, and the upper limit number table 23 shown in FIG. The upper limit number of CPUs corresponding to the attribute “OS # 1” is changed to “2”. Similarly, if the number of times of contention is 1000 times or more and less than 5000 times per second, the contention counting unit 27 obtains the CPU upper limit number “3” from the setting information table 28 and sets the attribute “OS # 1” of the upper limit number table 23. The upper limit number of CPUs corresponding to 'is changed to' 3 '. If it is less than 1000 times, the contention counting unit 27 obtains the CPU upper limit number “4” from the setting information table 28 and sets the upper limit number of CPUs corresponding to the attribute “OS # 1” in the upper limit number table 23 to “4”. Change to
[0065]
Similarly, the contention counting unit 27 counts the number of times the threads 31 a and 31 d having the attribute “OS # 2” for the kernel B 26 b compete, and changes the CPU upper limit number in the upper limit number table 23. If the contention to the kernel B 26b is 7000 times or more per second, the contention counting unit 27 refers to the setting information table 28 and the CPU upper limit number corresponding to the contention number 7000 times or more of the attribute “OS # 2”. 2 is acquired, and the CPU upper limit number corresponding to the attribute “OS # 2” in the upper limit number table 23 is changed to “2”. If it is less than 4000 times, the CPU upper limit number is changed to '3'.
[0066]
If the number of times that the attribute “OS # 2” conflicts with the kernel B 26 b is 4000 times or more and less than 7000 times, the contention counting unit 27 does not change the CPU upper limit number in the upper limit number table 23. A history is given to the change of the upper limit number of CPUs to prevent the upper limit number of CPUs from being changed frequently.
[0067]
Next, the processing flow of the computer 2 will be described using a flowchart.
FIG. 10 is a flowchart showing the thread assignment process of the computer. When this flowchart is started, the following processing is performed.
[0068]
[Step S10] The attribute acquisition unit 21 acquires the attribute of the thread 31g waiting for execution at the head of the execution queue 29 when any of the processing functions of the CPUs 20a to 20f is in the open state.
[0069]
[Step S11] The upper limit number acquisition unit 22 acquires the upper limit number that can occupy the CPUs 20a to 20f corresponding to the attribute of the thread 31g from the upper limit number table 23 that registers the upper limit number that can occupy the CPUs 20a to 20f for each attribute of the thread. To do.
[0070]
[Step S12] The execution number acquisition unit 24 acquires the number of executions of the CPUs 20a to 20f that are executing threads having the same attribute as the thread 31g.
[Step S13] The CPU allocation control unit 25 compares the upper limit number acquired in step S11 with the execution number acquired in step S12. If the upper limit number is larger than the execution number, the process proceeds to step S14. When the upper limit number is equal to or less than the execution number, the process proceeds to step S15.
[0071]
[Step S14] The CPU allocation control unit 25 causes the CPUs 20a to 20f in the released state to execute the thread 31g waiting for execution at the head of the execution waiting queue 29.
[0072]
[Step S15] The CPU allocation control unit 25 causes the thread 31g waiting for execution at the head of the execution queue 29 to wait for execution at the same position in the execution queue 29 and waits for the next execution in the execution queue 29. Go to see the thread 31h that is doing, and return to step S10.
[0073]
FIG. 11 is a flowchart showing processing for changing the upper limit number of processors of a computer. When this flowchart is started, the following processing is performed.
[Step S20] The contention counting unit 27 acquires the number of times the threads 31a to 31f compete with the kernel A 26a and the kernel B 26b for each attribute of the threads 31a to 31f.
[0074]
[Step S21] The contention counting unit 27, from the setting information table 28 in which the upper limit number that the CPUs 20a to 20f can occupy is registered according to the number of times of competition, the upper limit that can occupy the CPUs 20a to 20f corresponding to the number of times of competition acquired in step S20. Get the number.
[0075]
[Step S22] The contention counting unit 27 changes the upper limit number that can occupy the CPUs 20a to 20f in the upper limit number table 23 to the upper limit number that can occupy the CPUs 20a to 20f acquired in Step S21.
[0076]
In this way, because there is an upper limit that can occupy the CPU for each attribute of the thread, there is no increase in exclusive resource contention opportunities, and a reduction in parallel operability can be suppressed. Since a thread is assigned to a CPU that is in an open state without deciding which CPU can be used, it is possible to suppress a decrease in processor use efficiency.
[0077]
In addition, the contention to the kernel, which is an exclusive resource of the thread, is monitored in real time, and if the number of times of contention is high, the upper limit number that can occupy the CPU of the thread is reduced. Since the number is increased, it is possible to control the parallel operability and usage efficiency of the CPU to an optimum state. Further, it is possible to eliminate the need for tuning the number of CPU allocations corresponding to thread attributes.
[0078]
In the above description, the execution unit executed by the CPU is described as a thread. However, a process execution unit such as a process or LWP (Light Weight Process) may be used. Further, although the attribute is the OS type, the attribute may be given depending on the type of application running on the OS. Further, an attribute such as a flag corresponding to the contents of the program execution unit, a specific value, or a name may be added regardless of the type of OS or application. Furthermore, the number of times the thread competes with the exclusive resource is counted, and the upper limit number that can occupy the CPU is changed. However, the thread locks the exclusive resource (a state in which a thread uses the exclusive resource). The upper limit number that can occupy the CPU may be changed according to the locked time. Further, the count of the number of times of competition and the change of the upper limit number that can occupy the CPU may be performed at a constant cycle.
[0079]
Further, the processing contents of the functions that each computer should have can be described in a program recorded on a computer-readable recording medium. By executing this program on a computer, the above processing can be realized on the computer. Examples of the computer-readable recording medium include a magnetic recording device and a semiconductor memory. When distributing to the market, the program is stored and distributed on a portable recording medium such as a CD-ROM or flexible disk, or stored in a storage device of a computer connected via a network. Can also be transferred to other computers. When executed by a computer, the program is stored in a hard disk device or the like in the computer, loaded into the main memory, and executed.
[0080]
(Supplementary Note 1) In a multiprocessor control program for controlling a plurality of processors that execute a plurality of execution units,
On the computer,
When the processing function of the processor is open, get the attribute of the execution unit waiting for execution,
From the table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered, the upper limit number corresponding to the acquired attribute is acquired,
Obtain the number of executions of the processor that is executing the execution unit having the same attribute as the obtained attribute,
If the upper limit is greater than the number of executions, the released processor is caused to execute the execution unit waiting for execution;
A multiprocessor control program for executing a process.
[0081]
(Supplementary Note 2) Obtain the number of times of contention for the exclusive resource of the execution unit being executed by the processor for each attribute of the execution unit,
According to the number of conflicts acquired for each attribute, change the upper limit number that can occupy the processor corresponding to the attribute of the table,
The multiprocessor control program according to appendix 1, wherein the processing is further executed.
[0082]
(Supplementary Note 3) The execution unit waiting for execution is managed by a queue structure, and when the upper limit number is equal to or less than the execution number, the execution unit waiting for execution is executed at the position of the queue structure as it is. The multiprocessor control program according to appendix 1, wherein the processing is executed by an execution unit waiting for execution next to the execution unit waiting for execution.
[0083]
(Supplementary note 4) The multiprocessor control program according to supplementary note 1, wherein the attribute of the execution unit is a type of an operation system.
(Supplementary Note 5) In a multiprocessor control method for controlling a plurality of processors that execute a plurality of execution units,
When the processing function of the processor is open, get the attribute of the execution unit waiting for execution,
From the table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered, the upper limit number corresponding to the acquired attribute is acquired,
Obtain the number of executions of the processor that is executing the execution unit having the same attribute as the obtained attribute,
When the upper limit number is larger than the execution number, the execution unit waiting for the execution is executed to the open processor.
And a multiprocessor control method.
[0084]
(Supplementary Note 6) In a multiprocessor control device that controls a plurality of processors that execute a plurality of execution units,
Attribute acquisition means for acquiring an attribute of an execution unit waiting for execution when the processing function of the processor is in an open state;
An upper limit number acquisition unit that acquires the upper limit number corresponding to the acquired attribute from a table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered;
Execution number acquisition means for acquiring the execution number of a processor executing an execution unit having the same attribute as the acquired attribute;
When the upper limit number is larger than the execution number, execution means for executing the execution unit waiting for the execution in the open processor;
A multiprocessor control device comprising:
[0085]
(Supplementary note 7) In a computer-readable recording medium that records a multiprocessor control program for controlling a plurality of processors that execute a plurality of execution units,
On the computer,
When the processing function of the processor is open, get the attribute of the execution unit waiting for execution,
From the table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered, the upper limit number corresponding to the acquired attribute is acquired,
Obtain the number of executions of the processor that is executing the execution unit having the same attribute as the obtained attribute,
If the upper limit is greater than the number of executions, the released processor is caused to execute the execution unit waiting for execution;
A computer-readable recording medium on which a multiprocessor control program is recorded.
[0086]
【The invention's effect】
  As described above, in the present invention, the computer is provided with an upper limit number of execution units that can occupy the processor for each execution unit attribute, and the computer is in an open state without determining the processor that can be executed for each execution unit attribute. Causes the processor to execute an execution unit. Further, the number of times of contention for the exclusive resource of the execution unit is acquired for each attribute of the execution unit, and the upper limit number that can occupy the processor is changed according to the number of times of contention acquired for each attribute. This, It is possible to suppress degradation of processor parallel operation and use efficiency.In addition, parallel operability and usage efficiency can be controlled to the optimum stateThe
[Brief description of the drawings]
FIG. 1 is a principle diagram illustrating the principle of the present invention.
FIG. 2 is a hardware configuration example of a computer for realizing an embodiment of the present invention.
FIG. 3 is a functional block diagram of a computer for realizing an embodiment of the present invention.
FIG. 4 is a diagram illustrating a structure of an execution queue.
FIG. 5 is a diagram showing the structure of a thread.
FIG. 6 is a diagram (part 1) illustrating a transition state of thread processing of a CPU.
FIG. 7 is a diagram illustrating an example of information registered in an upper limit number table.
FIG. 8 is a diagram (part 2) illustrating a transition state of thread processing of a CPU.
FIG. 9 is a diagram illustrating an example of information registered in a setting information table.
FIG. 10 is a flowchart showing computer thread assignment processing;
FIG. 11 is a flowchart showing processing for changing the upper limit number of processors of a computer.
FIG. 12 is a diagram for explaining an operation (part 1) of a conventional multi-CPU system.
FIG. 13 is a diagram for explaining the operation (part 2) of the conventional multi-CPU system.
[Explanation of symbols]
1,2 computer
10 Attribute acquisition means
11 Upper limit number acquisition means
12 tables
13 Execution number acquisition means
14 Execution means
15a-15h Execution unit
16a-16f processor
20a-20f CPU
21 Attribute acquisition part
22 Upper limit number acquisition part
23 Upper limit number table
24 execution number acquisition part
25 CPU allocation controller
26a Kernel A
26b Kernel B
27 Competition counter
28 Setting information table
29 Waiting queue
30a, 30b OS
31a-31j threads

Claims (4)

複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御プログラムにおいて、
コンピュータに、
いずれかのプロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、
前記上限数が前記実行数より多い場合、実行単位の属性ごとに実行できるプロセッサを決めることなく、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行させ、
プロセッサによって実行されている実行単位の排他資源に対する競合回数を実行単位の属性ごとに取得し、
前記属性ごとに取得した競合回数に応じて、前記テーブルの前記属性に対応するプロセッサを占有できる上限数を変更する、
処理を実行させることを特徴とするマルチプロセッサ制御プログラム。In a multiprocessor control program for controlling a plurality of processors that execute a plurality of execution units,
On the computer,
When the processing function of any processor is in the open state, get the attribute of the execution unit waiting for execution,
From the table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered, the upper limit number corresponding to the acquired attribute is acquired,
Obtain the number of executions of the processor that is executing the execution unit having the same attribute as the obtained attribute,
When the upper limit is greater than the number of executions, without determining the processor that can be executed for each attribute of the execution unit, the processor in the open state executes the execution unit waiting for execution ,
Get the number of times of contention for the exclusive resource of the execution unit being executed by the processor for each attribute of the execution unit,
According to the number of conflicts acquired for each attribute, change the upper limit number that can occupy the processor corresponding to the attribute of the table,
A multiprocessor control program for executing a process. 前記実行待ちをしている実行単位はキュー構造により管理され、前記上限数が前記実行数以下の場合、前記実行待ちをしている実行単位を前記キュー構造のそのままの位置で実行待ちをさせ、前記実行待ちをしている実行単位の次に実行待ちをしている実行単位を前記実行待ちしている実行単位とすることを特徴とする請求項１記載のマルチプロセッサ制御プログラム。The execution unit waiting for execution is managed by a queue structure, and when the upper limit number is less than or equal to the execution number, the execution unit waiting for execution is made to wait for execution at the same position of the queue structure, 2. The multiprocessor control program according to claim 1, wherein an execution unit waiting for execution next to the execution unit waiting for execution is set as the execution unit waiting for execution. 実行単位の属性はオペレーティングシステムの種別であることを特徴とする請求項１記載のマルチプロセッサ制御プログラム。The multiprocessor control program according to claim 1, wherein the attribute of the execution unit is a type of an operating system. 複数の実行単位を実行する複数のプロセッサを制御するマルチプロセッサ制御方法において、In a multiprocessor control method for controlling a plurality of processors that execute a plurality of execution units,
いずれかのプロセッサの処理機能が開放状態のとき、実行待ちをしている実行単位の属性を取得し、  When the processing function of any processor is in the open state, get the attribute of the execution unit waiting for execution,
実行単位の属性ごとにプロセッサを占有できる上限数を登録したテーブルから、前記取得した属性に対応する前記上限数を取得し、  From the table in which the upper limit number that can occupy the processor for each attribute of the execution unit is registered, the upper limit number corresponding to the acquired attribute is acquired,
前記取得した属性と同じ属性を持つ実行単位を実行しているプロセッサの実行数を取得し、  Obtain the number of executions of the processor that is executing the execution unit having the same attribute as the obtained attribute,
前記上限数が前記実行数より多い場合、実行単位の属性ごとに実行できるプロセッサを決めることなく、前記開放状態のプロセッサに前記実行待ちをしている実行単位を実行させ、  When the upper limit is greater than the number of executions, without determining the processor that can be executed for each attribute of the execution unit, the processor in the open state executes the execution unit waiting for execution,
プロセッサによって実行されている実行単位の排他資源に対する競合回数を実行単位の属性ごとに取得し、  Get the number of times of contention for the exclusive resource of the execution unit being executed by the processor for each attribute of the execution unit,
前記属性ごとに取得した競合回数に応じて、前記テーブルの前記属性に対応するプロセッサを占有できる上限数を変更する、  According to the number of conflicts acquired for each attribute, change the upper limit number that can occupy the processor corresponding to the attribute of the table,
ことを特徴とするマルチプロセッサ制御方法。  And a multiprocessor control method.
JP2001384027A 2001-12-18 2001-12-18 Multiprocessor control program and multiprocessor control method Expired - Fee Related JP4127354B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001384027A JP4127354B2 (en) 2001-12-18 2001-12-18 Multiprocessor control program and multiprocessor control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001384027A JP4127354B2 (en) 2001-12-18 2001-12-18 Multiprocessor control program and multiprocessor control method

Publications (2)

Publication Number Publication Date
JP2003186856A JP2003186856A (en) 2003-07-04
JP4127354B2 true JP4127354B2 (en) 2008-07-30

Family

ID=27593866

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001384027A Expired - Fee Related JP4127354B2 (en) 2001-12-18 2001-12-18 Multiprocessor control program and multiprocessor control method

Country Status (1)

Country Link
JP (1) JP4127354B2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9170844B2 (en) * 2009-01-02 2015-10-27 International Business Machines Corporation Prioritization for conflict arbitration in transactional memory management

Also Published As

Publication number Publication date
JP2003186856A (en) 2003-07-04

Similar Documents

Publication Publication Date Title
US10545789B2 (en) Task scheduling for highly concurrent analytical and transaction workloads
US8122451B2 (en) Method and apparatus for dispatching tasks in a non-uniform memory access (NUMA) computer system
CN105579961B (en) Data processing system, operating method and hardware unit for data processing system
US5333319A (en) Virtual storage data processor with enhanced dispatching priority allocation of CPU resources
US6871264B2 (en) System and method for dynamic processor core and cache partitioning on large-scale multithreaded, multiprocessor integrated circuits
CN108549574B (en) Thread scheduling management method and device, computer equipment and storage medium
US7428629B2 (en) Memory request / grant daemons in virtual nodes for moving subdivided local memory space from VN to VN in nodes of a massively parallel computer system
US20050144332A1 (en) Autonomic input/output scheduler selector
US20080148300A1 (en) Providing Policy-Based Operating System Services in a Hypervisor on a Computing System
JPH0640324B2 (en) Multiprocessor system and process synchronization method thereof
US9632842B2 (en) Exclusive access control method prohibiting attempt to access a shared resource based on average number of attempts and predetermined threshold
JP2004252983A (en) System and method for enhancing performance of coprocessor
JP2004272894A (en) Multithread kernel of graphics processing unit
JP2007512632A (en) Managing virtual machines using activity information
JP2015504541A (en) Method, program, and computing system for dynamically optimizing memory access in a multiprocessor computing system
US7765548B2 (en) System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock
CN115981833A (en) Task processing method and device
Gifford et al. Dna: Dynamic resource allocation for soft real-time multicore systems
CN116225686A (en) CPU scheduling method and system for hybrid memory architecture
Wang et al. Adaptive scheduling of multiprogrammed dynamic-multithreading applications
JP3546694B2 (en) Multi-thread computer system and multi-thread execution control method
US20150212859A1 (en) Graphics processing unit controller, host system, and methods
JP4127354B2 (en) Multiprocessor control program and multiprocessor control method
JPH0612395A (en) Task allocating method in multiprocessor system
JP5243822B2 (en) Workload management in a virtualized data processing environment

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20041209

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070403

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070410

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070904

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071026

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: 20080507

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080507

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110523

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4127354

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120523

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130523

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140523

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees