JP3797402B2 - 情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 - Google Patents
情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP3797402B2 JP3797402B2 JP27097897A JP27097897A JP3797402B2 JP 3797402 B2 JP3797402 B2 JP 3797402B2 JP 27097897 A JP27097897 A JP 27097897A JP 27097897 A JP27097897 A JP 27097897A JP 3797402 B2 JP3797402 B2 JP 3797402B2
- Authority
- JP
- Japan
- Prior art keywords
- calculation
- priority
- calculation process
- threads
- information processing
- 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
- 230000010365 information processing Effects 0.000 title claims description 33
- 238000003672 processing method Methods 0.000 title claims description 7
- 238000004364 calculation method Methods 0.000 claims description 266
- 238000000034 method Methods 0.000 claims description 223
- 230000008569 process Effects 0.000 claims description 206
- 238000012545 processing Methods 0.000 claims description 72
- 230000008859 change Effects 0.000 claims description 13
- 230000007423 decrease Effects 0.000 claims description 5
- 230000015654 memory Effects 0.000 description 25
- 238000010586 diagram Methods 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 5
- 238000011156 evaluation Methods 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000006798 recombination Effects 0.000 description 1
- 238000005215 recombination Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、大量の情報を計算処理することを支援する情報処理システムに関連する。例えば、スワップ、オプションといった金融派生商品（デリバティブ）取引のディーリングを支援する金融情報処理システムが代表的な例として挙げられる。
【０００２】
【従来の技術】
デリバティブのような金融派生商品取引では、ディーラーは、顧客の現在の資産価値はいくらなのか、あるいは資産価値の増減はどの程度なのか等、業務に伴うリスクを迅速かつ正確に把握するために、取引に係わる情報をデータベース化し、さまざまな計算をコンピュータを用いて処理している。
【０００３】
【発明が解決しようとする課題】
通常、主に金利や為替レートのような市況データと、約定データを用いて、一定の計算式によって資産価値や資産価値の増減を評価しているが、計算対象となる約定は、一般には数千から数万という膨大な件数であり、場合によっては計算処理に何十分もかかることがある。しかし、ディーリングのような迅速な意思決定が求められる業務においては、このように長い時間がかかっていては致命的であり、処理時間の短縮が望まれている。
【０００４】
本発明は、上記事情に基づいてなされたものであり、資産価値等を評価するための約定データの計算処理等、大量の情報を扱う計算を短時間で行うことができる情報処理装置、情報処理方法及び情報処理プログラムを記録した記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の目的を達成するために、請求項１記載の発明である情報処理システムは、複数の端末と接続され、前記複数の端末から要求された計算処理を実行するための情報処理装置であって、
データが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいて計算要求毎に計算プロセスを生成する計算プロセス生成手段と、
他の計算プロセスの実行状況、或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する優先度変更手段と、を備え、
前記計算プロセスは、
前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて、前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出し、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせ、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる、
処理を行うことを特徴とする。
【０００６】
請求項４記載の発明である情報処理方法は、複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理方法であって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する工程と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する工程と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する工程と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる工程と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる工程と、
を具備することを特徴とする。
【０００７】
請求項７記載の発明であるコンピュータ読み取り可能な記憶媒体は、複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理プログラムであって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する機能と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する機能と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する機能と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる機能と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる機能と、
を実現するための情報処理プログラムを記録したものである。
【００１２】
【発明の実施の形態】
以下に図面を参照して本発明の実施形態について説明する。
図１は、本発明の一実施形態の金融情報処理システムの全体的な構成を示す図である。同図に示すように、本実施形態の金融情報処理システムは、ネットワーク１０上に、複数のディーラ端末１１と、ネットワークの中央部に位置する複数の計算サーバ１２が接続されている。ディーラ端末１１は、ディーラが取引業務を行うディーリングルームに設置され、計算サーバ１２は、例えば別室に設置されている。両者の間では、プロセス間通信が行われる。計算サーバ１２は並列コンピュータであり、この内部では、ディーラからの指示に基づいて、後述の計算を行う並列プログラムが稼働する。
【００１３】
図２は、ディーラ端末１１と計算サーバ１２を１台ずつ示している。ディーラ端末１１には、ディスプレイ１３及びキーボード１４が接続されている。ディスプレイ１３には、計算の実行状況や計算結果などが表示される。キーボード１４は、ディーラがこれを用いて計算対象となる約定を特定するＩＤ及び優先度を指定する場合等に使用される。ディーラ端末１１の内部では、ネットワークを介しての計算要求の計算サーバ１２への送信、計算の実行状況の受信、計算結果の受信などを行う金融デリバティブ資産価値評価用アプリケーョンソフトウェア１５（以下単に「クライアントアプリケーション」という）が稼働している。
【００１４】
ディーラ端末１１上のクライアントアプリケーション１５が、計算サーバ１２に対して送信する計算要求には、約定データを特定するＩＤと、優先度が含まれている。優先度は、約定データファイルに対応して予め決められていてもよいし、ディーラが指定してもよい。以下は、ディーラが計算要求の都度指定する場合について説明する。ディーラ端末１１上では、クライアントアプリケーション１５の他にも、デリバティブ取引のリスク管理を行う種々のアプリケーションプログラムが稼働している。ディーリング業務中、当システムで提供される計算をさせようと思ったときには、ディーラ端末１１上でその旨の指示を、約定データのＩＤ及び優先度とともにキーボードなどから打ち込むと、クライアントアプリケーション１５がこれを受け取り、計算サーバ１２へ送信する。計算サーバ１２がこれらのデータを受け取ると、実際に計算を開始する。この具体的な計算内容については、後述する。
【００１５】
計算サーバ１２上では、制御プロセス１６と計算プロセス１７が稼働している。図２では、このうち制御プロセス１６のみを示している。制御プロセス１６は、計算サーバ１２上に常に一つだけが常駐していて、ディーラ端末１１からの要求を待っている。制御プロセス１６は、ディーラ端末１１から必要な情報が送られてくると、必要に応じて計算プロセス１７を立ち上げる。計算プロセス１７は、制御プロセス１６の制御のもとで、ディーラ端末１１から送られてきた情報と、約定データに基づいて、実際の計算を行う。
【００１６】
本実施形態の金融情報処理システムが主として計算の対象とするのは、デリバティブ取引に関連する約定データである。デリバティブ取引とは、原資産の価格に応じ、その価値が決定される商品（デリバティブ商品）を取引するもので、実際の決済は先のことになる。約定データというのは、過去に行ったデリバティブ商品の取引の内容を記録したデータのことである。
【００１７】
ディーラは、今現在保有しているデリバティブ商品が、将来的にどれだけの価値を持つに至るのか、すなわち、将来の決済時点で損をすることになるのか得になるのかを、現時点で迅速に評価する必要がある。新たに取引の引き合いがあったときに、ディーラは、その引き合いを受けるべきかどうかを短時間に判断するためにも、自分が現在どれだけの資産を所有しているかを短時間に知る必要がある。加えて、その資産が、将来のある時点において、どの程度変動している可能性があるかという評価も行う必要がある。
【００１８】
しかしながら、約定データに記述されるデリバティブの価値は、前述のように、実際の金銭の集積ではなく、変動金利、原資産価値に連動して変化する。しかも、一般的に、その評価には数学理論に基づく高度な計算処理が必要で、約定数も非常に多くなると、約定データを用いた資産の評価は、コンピュータで行う必要がある。この約定データを使って、現在の自分の資産を評価する計算が、計算サーバ１２によって行われる。
【００１９】
約定は、多い場合には数千から数万という数に達するが、これらはある程度グループ化されており、それぞれのグループごとに識別用のＩＤが付されている。実際の約定データは、計算サーバ１２の内部、あるいは別の場所に備えられたハードディスク等にデータベースとして蓄えられており、ディーラ端末１１からＩＤが送られてくると、そのＩＤに対応する約定データがデータベースから計算サーバ１２の主メモリ上に読み出される。
【００２０】
図３は、計算サーバ１２上における、制御プロセス１６と計算プロセス１７との関係を示した図である。同図では、ディーラ端末１１上で稼働している３つのクライアントアプリケーション１５1 、１５2 、１５3 のそれぞれが、計算サーバ１２上の制御プロセス１６に対して計算要求１、２、３を出している状況を示している。制御プロセス１６とその下に示した三つの計算プロセス１７1 、１７2 、１７3 は、実際には一つの計算サーバ１２の中で稼働しているプロセスである。後述のように、計算サーバには多数のＣＰＵが装備されている。
【００２１】
図３には、クライアントアプリケーション１５1 、１５2 、１５3 が示してあるが、これはディーラが３人いて、それぞれが計算サーバに対して計算を要求した状況に対応する。しかし、実際の状況では、これよりも多くのディーラが存在することができる。制御プロセス１６は、複数のディーラ端末から計算要求を一括して受け取り、後述のようにして、それぞれのディーラ向けに計算プロセス１７を生成し、立ち上げて、複数のＣＰＵによる並列演算処理を行わせる。
【００２２】
図４は、図３に示した計算プロセス１７1 、１７2 、１７3 が、実際に計算を実行している状況を示した図である。各計算プロセス１７は、計算処理の状況を、制御プロセス１６を介して、ネットワーク上で対応するディーラ端末のクライアントアプリケーション１５に定期的に通知する。その内容は、当該計算プロセスが抱えている全ての約定件数のうち既に処理が済んだ約定件数の割合などであり、この割合はディーラ端末の画面にグラフと数値で表示される。
【００２３】
優先度は、元々ディーラによって指定されるものであるが、本実施形態では、制御プロセス１６が各クライアントアプリケーション１５からディーラの指定した優先度を受け取った場合、制御プロセス１６は、そのときの状況を見て、必要に応じて優先度の変更を行い、その変更後の優先度を各計算プロセス１７に対して通知する。各計算プロセス１７は、この優先度に基づいて設定しようとするスレッドの数を決める。スレッドとは、備えられているＣＰＵの数に対応して分割された処理の単位であり、計算プロセス１７によってソフトウェア的に設定されるものである。すなわち、このスレッドの数が、その計算プロセス１７が専有するＣＰＵの数となる。また、各計算プロセスは、常時、処理状況を制御プロセス１６に通知している。制御プロセス１６は、これを各クライアントアプリケーション１５にも送信し、その端末のディスプレーに表示するほか、後述のように、他の計算プロセスに対してもその処理状況を通知する。
【００２４】
図５は、計算サーバ１２内において計算プロセス１７1 、計算プロセス１７2 が生成され、これらが８個のＣＰＵ２０1 〜２０8 を用いて、どのように計算を行うかを示した図である。制御プロセス１６が、計算プロセスを生成して計算要求に基づく演算を実行させようとするときに、ＣＰＵがいくつ存在するかが重要となる。図５の場合には、８個のＣＰＵ２０1 〜２０8 があり、したがって並列度８の処理が可能となる。
【００２５】
図５において、制御プロセス１６から、まず計算プロセス１７1 が生成され、その優先度が１に設定されていたとする。このとき、計算プロセス１７1 においては、８個のスレッド３０1 〜３０8 がソフトウェア的に設定され、これらの一つ一つが８個のＣＰＵで同時に処理されることによって、並列度８の並列演算処理が実行されている。この状況のもとで、制御プロセス１６によって、計算プロセス１７2 が生成され、これを計算しなければならなくなったとする。このとき、仮に、計算プロセス１７2 の優先度が上と同じく１で設定されているとすると、並列度が８のプログラムが二つ存在することになる。この場合、ＣＰＵは８個しかないから、１６個の処理が８個のＣＰＵを取り合うことになる。その結果、先に処理が要求されている計算プロセス１７1 の処理が遅くなり、当初の予定よりも時間が余計にかかることになる。
【００２６】
そこで、図５の例では、次のような考え方を採用している。ある計算プロセスが既に存在しているときに、ディーラによってその計算プロセスと同じ優先度が指定された計算要求があった場合には、制御プロセス１６は、後からなされた計算要求の優先度を一つ下げる。図５の例では、計算プロセス１７1 の優先度は１であり、計算プロセス１７2 の優先度は、当初は１であったが、その優先度を一つ下げて２とされている。前述のように、各計算プロセスは、優先度のみによって設定するスレッドの数を決定する。具体的には、
スレッドの数 ＝ （ＣＰＵの数）／２N-1 （１）
という式に基づいてスレッドの数を決定する。ここで、Ｎは優先度の値である。例えば、ＣＰＵの数が８個で優先度が１であれば、スレッドの数は８個、ＣＰＵの数が８個で優先度が２であれば、スレッドの数は４個、ＣＰＵの数が４個で優先度が１であれば、スレッド数は４個、ＣＰＵの数が４個で優先度が２であれば、スレッド数は２個となる。
【００２７】
図５の例では、ＣＰＵの数は８個であるから、優先度Ｎ＝１である計算プロセス１７1 のスレッドの数は８個，優先度Ｎ＝２である計算プロセス１７2 のスレッド数は４個となる。計算プロセス１７2 のスレッド３１1 〜３１4 の数は、このようにして決められたものである。
このように、８個のＣＰＵを、スレッド数８の計算プロセス１７1 と、スレッド数４の計算プロセス１７2 が協調して並列処理を行うが、スレッド数が多い計算プロセス１７1 の方の処理がより速く進められる。その一方で、計算プロセス１７2 についても、計算プロセス１７1 の処理がすべて終了するまで処理が全く行われないというのではなく、計算プロセス１７1 の処理が終わるまでに、ある程度処理が進められることになる。
【００２８】
また、スレッド数は、計算プロセスの各スレッドのプログラムが決定するようにしてもよい。計算プロセスが全く生成されていない場合は、上述のように、計算プロセスが最初のスレッド数を決定する。しかし、ある計算プロセスが既に存在しているときは、その後の変更された優先度を各スレッドが受け、各スレッドのプログラムがスレッド数の増減を決定するようにしてもよい。
【００２９】
図６は、図５とは異なる考え方で、優先度を決めている例である。ここでは、ＣＰＵの数は、２１1 〜２１4 の４個であり、最初は（ａ）に示すように、優先度が１の計算プロセス１７1 のみが生成されていたとする。スレッドの数は、（１）式に基づいて４となり、４つのスレッド３５1 〜３５4 が設定され、並列度４の並列処理が行なわれている。
【００３０】
その後、別の計算要求があり、ディーラが指定したその優先度も同じく１だったとする。制御プロセス１６は、この計算要求に基づいて計算プロセス１７2 を生成するが、このとき制御プロセス１６は、図５の場合の考え方とは異なり、両方の優先度を２に下げる。その結果、（１）より、両者のスレッド数はいずれも２となり、各計算プロセス１７1 、１７2 は、スレッドの組み換えを行い、計算プロセス１７1 はスレッド３６1 、３６2 を再設定し、計算プロセス１７2 はスレッド３７1 、３７2 を設定する。
【００３１】
その後更に、計算プロセス１の処理が終了すると、制御プロセス１６は、計算プロセス１７2 の優先度を１に上げる。その結果、計算プロセス１７2 は、再度スレッドの組み換えを行い、スレッド３８1 〜３８4 を再設定する。
図６のようにすると、複数の計算要求があって、それらの優先度が等しい場合には、両方を平等に取り扱って処理が実行される。また、優先度に基づいてスレッド数を決定することにより、制御プロセスが優先度を変更すると、計算プロセスが処理を実行している最中であっても、状況に応じて、動的にスレッドの数を変えて適切な状況を設定することができる。
【００３２】
図７は、ある計算プロセス１７の動作を模式的に示した図である。図７において、入力側の共有メモリ４０は、計算サーバ１２に備えられたＲＡＭ等からなる主メモリである。共有メモリ４０には、この計算プロセスが抱えている約定データが記憶され、一つのファイルとされる。図７の例では、ｎ件の約定データ４１1 〜４１n が記憶されている。約定データは、元々計算サーバ１２の内部又は外部に設けられたハードディスク等の記録装置にデータベースとして蓄えられており、これを計算プロセスが引き出して、入力側の共有メモリ４０に記憶させる。共有メモリ４０に記憶された約定データの全体を、「約定テーブル」又は「約定テーブルファイル」ともいう。
【００３３】
実際に計算を行う場合には、計算プロセスは、まずデータベースから約定データを取ってきて、共有メモリ４０上に書き込んで、約定データファイルとする。その後、ソフトウェア的にスレッドを設定する。図７では、一例として、四つのスレッド４３1 、４３2 、４３3 、４３4 が設定されている。一つのスレッドが、一つのＣＰＵを使って独立に処理を行う単位となるので、四つのスレッドがそれぞれ一つずつ、共有メモリ４０から約定データを読み出して、合計四つのＣＰＵを使って並列度４の並列処理を行っている。
【００３４】
この約定データの読み出しの際には、ロック機構４２の排他制御によって、あるスレッドが共有メモリ４０から約定データを読み出している間は、他のスレッドが約定データの読み出しを行うことができないようになっている。また、同じ約定データを複数のスレッドで処理することのないように、一度あるスレッドによって読み出された約定データは、他のスレッドからは読み出されないようにしている。なお、ロック機構４２は、後述するように、実際にはロックファイルと、各スレッドがこのロックファイルを見に行ってアクセスできるかどうかを判断することによって実現される。
【００３５】
図７の例では、ｎ件の約定が一つずつ順番に処理されるのではなく、四つのＣＰＵが協調しながらｎ件の約定を処理する。このように並列的な処理を行うことによって、処理に要する時間が短縮される。
各スレッドごとにＣＰＵによって計算されたデータは、出力側の共有メモリ４５に、例えばマトリックス形式のデータとして書き込まれる。この共有メモリ４５も、計算サーバ１２の主メモリである。このとき、各スレッドが無秩序にデータを書き込むと、データ全体の整合がとれないという問題が生じるので、この場合も、ロック機構４４が働いて、あるスレッドが共有メモリ４５にデータを書き込んでいるときには、他のスレッドがデータの書き込みを行うことができないような排他制御を行う。
【００３６】
図８は、図７に示した入力側の共有メモリ４０上に展開されている約定テーブルファイルを示している。このテーブルの各行に約定テーブルが置かれており、各行の右端には、１ビットの処理済フラグが設けられている。各スレッドは、自分が処理を実行している約定データには処理済フラグ「１」をセットし、その約定データは既に処理が済んでいることを表示する。他のスレッドは、このテーブルを見るときに、処理済フラグ「１」がセットされている約定データはスキップし、処理済フラグが「０」の約定データを探して読み出す。このとき、本実施形態では、処理済フラグが「０」の約定データのうち、一番上にある約定データをポインタが指し示すようにしている。スレッドは、このポインタを探して読み出すべきデータを見つけ出す。こうすることによって、スレッドが簡単に読み出すべき約定データを探しだせるようにしている。但し、ポインタを用いずに、スレッドが処理済フラグをスキャンして、「０」のものを見つけ次第それを読み出すようにしてもよい。
【００３７】
図９は、一つの計算プロセスにおいて行われる処理の手順を示したフローチャートである。この処理は、制御プロセス１６が、計算プロセス１７を立ち上げたときに開始される。計算プロセスが立ち上がり、約定データがデータベースから読み出され、入力側の共有メモリ４０に記憶されると、この計算プロセスにおいて図９に示す処理手順が開始される。
【００３８】
図９の処理手順が開始されると、まず、図５、図６又は図７に示すように、スレッドが設定される（Step１０）。スレッドの数の決定は、前述のように、制御プロセス１６から出てくる優先度に基づいてなされる。一方、仮に、既に別の計算プロセスが立ち上がっている場合には、制御プロセス１６が、予め定められたアルゴリズムに基づいて、必要に応じてディーラによって指定された優先度を変更する。この優先度に応じて所定数のスレッドが設定される。
【００３９】
次に、他のスレッドが参照すべきロックファイルを生成する（Step１１）。他のスレッドは、このロックファイルを参照することによって、図７に示した共有メモリ４０及び４５が排他状態か否かを判断する。
Step１１においてロックファイルが生成されたあとは、本来の目的である演算が並列処理によって実行される（Step１２）。すなわち、スレッドの数に対応したＣＰＵによって、同時に演算が実行される。なお、計算プロセス自体を動作させるメインのＣＰＵは、実際の計算を実行するＣＰＵとは別に設けられている。並列処理が終了すると、ロックファイルを解除し（Step１３）、スレッドを消去して（Step１４）、この計算プロセス自身も消滅する。以上で、一つの計算プロセスの処理が終了する。
【００４０】
図１０は、図９に示した処理手順のうちStep１２の部分の処理手順を詳しく示したフローチャートである。Step２０では、まず、図７に示したロック機構４２がロック状態であるかどうか、すなわち別のスレッドがロック機構４２をロック状態にしているかどうかを判断する。ロックがされておらず、自分が共有メモリ４０から約定データを読み出せる状態であれば、他のスレッドが読み出しを行うことができないように、ロック機構４２のロックをかける（Step２１）。次に、スレッドは、約定データの中から、図８に示すようにポインタが指し示している処理済フラグが「０」の約定データを探して、それをフェッチするという処理を行い（Step２２）、そして、その約定データの処理済フラグに「１」をセットする（Step２３）。このスレッドが約定データを読み出して、その約定データの処理済フラグに「１」をセットすると、共有メモリ４０へのアクセスを排除する必要がなくなるのでロックを解除し（Step２４）、その後、実際の計算処理に移行する（Step２５）。計算が終わると、その結果を出力側の共有メモリ４５へ書き込む（Step２６）。Step２７では、未処理の約定データがあるかどうかを判断する。未処理のものがある場合には、上で説明したのと同様の処理を繰り返し、一方、未処理の約定データがなくなった場合には、処理を終了する。
【００４１】
図１１は、計算プロセスと制御プロセス１６との間で実行する処理の手順を示したフローチャートである。
図１１において、現在存在する計算プロセスの数に変化があったかどうかを検出している（Step３０）。例えば、現在ある計算プロセスが生成されているときに、ディーラ端末１１から新たな計算要求があった場合には、制御プロセス１６が新たな計算プロセスを生成するので、計算プロセスの数は増加する。一方、ある計算プロセスの処理が終了し、計算プロセスが消滅すると、計算プロセスの数は減少する。Step３０において、制御プロセスは、計算プロセスの生成あるいは終了を検知すると、プロセス数を確認し、Step３１において、各計算プロセスに通知する。制御プロセス１６は、各計算プロセスの優先度を見直し、必要に応じて優先度を変更して、各計算プロセスに通知する。各計算プロセスは、変更後の優先度に応じて、前述の（１）式に基づいてスレッドの数を決定し、既にあるスレッドを消去した上で、スレッドを再設定する（Step３２）。
【００４２】
このように、本実施形態では、各計算プロセスの内部におけるスレッドの数を、計算要求の有無に応じて、動的に変化させる。このスレッドの数を変える際に基礎となるのは、前述のように優先度だけである。このように、実際に並列処理が実行されている途中においても、計算要求の有無に応じて、スレッドの数を動的に変化させることによって、効率的で無駄の少ない処理が可能となる。また、この際、基礎とするのが優先度だけなので、処理内容が簡素化される。
【００４３】
なお、上述したように、計算プロセスの各スレッドのプログラムによってスレッド数を変更するようにしてもよい。その場合、優先度に応じて、各スレッドが自らを終了させるか、新しいスレッドを生成することによって、スレッド数を適正値に収束させるようにしてもよい。
図１２は、ある一つの計算プロセスの処理手順全体を示したフローチャートであり、したがって、図１０で説明した処理を含んでいる。
【００４４】
図１２の処理手順がスタートすると、まずStep４０で、図７に示したロック機構４２がロック状態であるかどうか、すなわち別のスレッドがロック機構４２をロック状態にしているかどうかを判断する。ロックがされておらず、自分が共有メモリ４０から約定データを読み出せる状態であれば、他のスレッドが読み出しを行うことができないように、ロック機構４２のロックをかける（Step４１）。次に、スレッドは、約定データの中から、図８に示すようにポインタが指し示している処理済フラグが「０」の約定データを探して、それをフェッチするという処理を行い（Step４２）、そして、その約定データの処理済フラグに「１」をセットする（Step４３）。このスレッドが約定データを読み出して、その約定データの処理済フラグに「１」をセットすると、共有メモリ４０へのアクセスを排除する必要がなくなるのでロックを解除し（Step４４）、その後、実際の計算処理に移行する（Step４５）。計算が終わると、その結果を出力側の共有メモリ４５へ書き込む（Step４６）。ここまでは、図１０に示した処理手順と同じである。
【００４５】
次に、この計算プロセスは、他の計算プロセスの実行状況に変化があったかどうかを見る（Step４７）。他の計算プロセスの実行状況に変化があったか否かは、制御プロセス１６に問い合わせることによって知ることができる。他の計算プロセスの実行状況に変化がなければ、更に、未処理データがあるかどうか見て（Step４８）、なければ処理を終了し、未処理データがある場合には、最初に戻って同様の処理を繰り返す。
【００４６】
Step４７において、他の計算プロセスの実行状況に変化があった場合には、既に設定してあるスレッドを消去する必要があるかどうかを判断する（Step５０）。ここでいうスレッドの消去とは、スレッドの再設定のことは含まない、完全に消去し、処理を終了することを意味している。スレッドを消去する場合とは、例えば、その計算プロセスに通知されている優先度よりも高い優先度の別の計算プロセスが生成され、当該別の計算プロセスの処理を優先して実行するように設定されている場合に、一度その計算プロセスのスレッドを消去し、当該別の計算プロセスの処理が終了したあとに再度スレッドを設定するといった場合が該当する。但し、この場合にスレッドは消去されも、計算プロセスそのものは存続している。
【００４７】
スレッドを消去してよい場合には、Step７０において、スレッドを消去し、処理を終了する。一方、スレッドを消去しない場合には、スレッド数が増加するかどうかを判断する（Step５１）。スレッド数が増加しない場合には、未処理データがあるかどうかを判断し（Step５２）、なければ処理を終了し、未処理データがある場合には、最初に戻って同様の処理を繰り返す。
【００４８】
一方、Step５１で、スレッド数が増加する場合にも、同じく未処理データがあるかどうかを判断し（Step６０）、なければ処理を終了し、未処理データがある場合には、未処理として残っているデータが所定数を超えているかどうかを判断する（Step６１）。未処理データが当該所定数を超えていれば、予定どおりスレッドを増加し（Step６２）、最初に戻って処理を行うが、未処理データが当該所定数を超えていなければ、スレッドの数を増やすまでもないので、そのまま最初に戻って処理を行う。
【００４９】
図１３は、計算プロセスの各スレッドのプログラムが、所定の演算により自らを終了させ、あるいは新たなスレッドを発生させて、最終的に適正なスレッド数に収束させる場合の処理手順全体を示したフローチャートであり、したがって図１２と同様に、図１０で説明した処理を含んでいる。
図１３のStep１４０からStep１４６までは、図１２のStep４０からStep４６までと同様であるので、説明を省略する。この例では、優先度の値データは、計算プロセスとスレッドのプログラム両者によって参照されるため、共有領域にあり、両者による参照を可能とするための排他制御が行われる。すなわち、Step１４７で、優先度データの共有メモリがロック状態（参照不可状態）か否かを判断し、ロック状態でなければロックし（Step１４８）、優先度Ｎの変化を判断する（Step１４９）。変化がなければ、ロックを解除し（Step１７０）、未処理データがあれば、Step１４０へ戻る。
【００５０】
Step１４９で、優先度Ｎに変化があったときは、Step１５０において、全体のスレッド数Ｍが、計算して求めたスレッド数より大きいかが判断される。Ｍはそのときに存在しているスレッド数であって、共有領域に記載されている。Ｍが計算されたスレッド数より大きければ、Ｍを一つ減少させ（Step１５１）、ロックが解除され（Step１７２）、スレッドは消去される（Step１７３）。
【００５１】
また、Ｍが計算値よりも小さければ、未処理データがあるか否かを判断し（Step１６０）、なければStep１７２へ進み、ロックを解除する。未処理データがあれば、残りデータ数が所定値以上か否かを判断し（Step１６１）、所定値以上であればスレッドを生成し（Step１６２）、Ｍを一つ増加し（Step１６３）、ロックを解除する（Step１６４）。
【００５２】
このように、優先度に基づくスレッド数よりも、プロセス内のスレッド数が多い場合には、多い分のスレッドが自らを終了してゆき、全体としては、最終的に適正なスレッド数に収束することになる。また、増加するときも適正なスレッド数に徐々に近づき、結果的に収束することになる。
なお、本発明は、上記実施形態に限定されるものではなく、その要旨の範囲内で種々の変更が可能である。たとえば、上記実施形態では、ＣＰＵが８つの場合と４つの場合について説明したが、ＣＰＵの数はこれらに限定されるものではなく、任意の数のＣＰＵを用いて並列処理を行う場合にも適用できる。
【００５３】
【発明の効果】
以上説明したように、本発明によれば、例えば、デリバティブ取引の際に資産価値や資産価値の増減を評価するために行う約定データの計算を、複数のＣＰＵを用いて並列処理によって実行させるので、迅速な処理が可能となり、結果が出るまでの時間を短縮させることができる。更に、計算プロセスが設定するスレッドの数を、他の計算プロセスの実行状況を見て動的に変化させることにより、並列処理の効率を向上させることができるので、より迅速な処理が可能となり、結果が出るまでの時間を更に短縮させることが可能となる情報処理システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の金融情報処理システムの全体的な構成を示す図である。
【図２】図１に示すシステムのうち、ディーラ端末１１と計算サーバ１２を１台ずつ示した図である。
【図３】計算サーバ１２上における、制御プロセス１６と計算プロセス１７との関係を示した図である。
【図４】図３に示した計算プロセス１７1 、１７2 、１７3 が、実際に計算を実行している状況を示した図である。
【図５】計算サーバ１２内において計算プロセス１７1 、計算プロセス１７2 が生成され、これらが８個のＣＰＵ２０1 〜２０8 を用いて、どのように計算を行うかを示した図である。
【図６】二つの計算プロセス１７が生成されたときに、動的にスレッドが再設定される様子を示した図である。
【図７】計算プロセス１７の動作を模式的に示した図である。
【図８】図７に示した入力側の共有メモリ４０上に展開されている約定テーブルファイルを示した図である。
【図９】一つの計算プロセスにおいて行われる処理の手順を示したフローチャートである。
【図１０】図９に示した処理手順の一部の処理手順を詳しく示したフローチャートである。
【図１１】計算プロセスが制御プロセスとの間で実行する処理の手順を示したフローチャートである。
【図１２】ある一つの計算プロセスの処理手順全体を示したフローチャートである。
【図１３】他の一つの計算プロセスの処理手順全体を示したフローチャートである。
【符号の説明】
１０ ネットワーク
１１ ディーラ端末
１２ 計算サーバ
１３ ディスプレー
１４ キーボード
１５ クライアントアプリケーション
１６ 制御プロセス
１７ 計算プロセス
２０，２１ ＣＰＵ
３０，３１，３５，３６，３７，３８，４３ スレッド
４０ 入力側共有メモリ
４１ 約定データ
４２，４４ ロック機構
４５ 出力側共有メモリ
【発明の属する技術分野】
本発明は、大量の情報を計算処理することを支援する情報処理システムに関連する。例えば、スワップ、オプションといった金融派生商品（デリバティブ）取引のディーリングを支援する金融情報処理システムが代表的な例として挙げられる。
【０００２】
【従来の技術】
デリバティブのような金融派生商品取引では、ディーラーは、顧客の現在の資産価値はいくらなのか、あるいは資産価値の増減はどの程度なのか等、業務に伴うリスクを迅速かつ正確に把握するために、取引に係わる情報をデータベース化し、さまざまな計算をコンピュータを用いて処理している。
【０００３】
【発明が解決しようとする課題】
通常、主に金利や為替レートのような市況データと、約定データを用いて、一定の計算式によって資産価値や資産価値の増減を評価しているが、計算対象となる約定は、一般には数千から数万という膨大な件数であり、場合によっては計算処理に何十分もかかることがある。しかし、ディーリングのような迅速な意思決定が求められる業務においては、このように長い時間がかかっていては致命的であり、処理時間の短縮が望まれている。
【０００４】
本発明は、上記事情に基づいてなされたものであり、資産価値等を評価するための約定データの計算処理等、大量の情報を扱う計算を短時間で行うことができる情報処理装置、情報処理方法及び情報処理プログラムを記録した記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の目的を達成するために、請求項１記載の発明である情報処理システムは、複数の端末と接続され、前記複数の端末から要求された計算処理を実行するための情報処理装置であって、
データが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいて計算要求毎に計算プロセスを生成する計算プロセス生成手段と、
他の計算プロセスの実行状況、或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する優先度変更手段と、を備え、
前記計算プロセスは、
前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて、前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出し、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせ、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる、
処理を行うことを特徴とする。
【０００６】
請求項４記載の発明である情報処理方法は、複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理方法であって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する工程と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する工程と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する工程と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる工程と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる工程と、
を具備することを特徴とする。
【０００７】
請求項７記載の発明であるコンピュータ読み取り可能な記憶媒体は、複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理プログラムであって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する機能と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する機能と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する機能と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる機能と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる機能と、
を実現するための情報処理プログラムを記録したものである。
【００１２】
【発明の実施の形態】
以下に図面を参照して本発明の実施形態について説明する。
図１は、本発明の一実施形態の金融情報処理システムの全体的な構成を示す図である。同図に示すように、本実施形態の金融情報処理システムは、ネットワーク１０上に、複数のディーラ端末１１と、ネットワークの中央部に位置する複数の計算サーバ１２が接続されている。ディーラ端末１１は、ディーラが取引業務を行うディーリングルームに設置され、計算サーバ１２は、例えば別室に設置されている。両者の間では、プロセス間通信が行われる。計算サーバ１２は並列コンピュータであり、この内部では、ディーラからの指示に基づいて、後述の計算を行う並列プログラムが稼働する。
【００１３】
図２は、ディーラ端末１１と計算サーバ１２を１台ずつ示している。ディーラ端末１１には、ディスプレイ１３及びキーボード１４が接続されている。ディスプレイ１３には、計算の実行状況や計算結果などが表示される。キーボード１４は、ディーラがこれを用いて計算対象となる約定を特定するＩＤ及び優先度を指定する場合等に使用される。ディーラ端末１１の内部では、ネットワークを介しての計算要求の計算サーバ１２への送信、計算の実行状況の受信、計算結果の受信などを行う金融デリバティブ資産価値評価用アプリケーョンソフトウェア１５（以下単に「クライアントアプリケーション」という）が稼働している。
【００１４】
ディーラ端末１１上のクライアントアプリケーション１５が、計算サーバ１２に対して送信する計算要求には、約定データを特定するＩＤと、優先度が含まれている。優先度は、約定データファイルに対応して予め決められていてもよいし、ディーラが指定してもよい。以下は、ディーラが計算要求の都度指定する場合について説明する。ディーラ端末１１上では、クライアントアプリケーション１５の他にも、デリバティブ取引のリスク管理を行う種々のアプリケーションプログラムが稼働している。ディーリング業務中、当システムで提供される計算をさせようと思ったときには、ディーラ端末１１上でその旨の指示を、約定データのＩＤ及び優先度とともにキーボードなどから打ち込むと、クライアントアプリケーション１５がこれを受け取り、計算サーバ１２へ送信する。計算サーバ１２がこれらのデータを受け取ると、実際に計算を開始する。この具体的な計算内容については、後述する。
【００１５】
計算サーバ１２上では、制御プロセス１６と計算プロセス１７が稼働している。図２では、このうち制御プロセス１６のみを示している。制御プロセス１６は、計算サーバ１２上に常に一つだけが常駐していて、ディーラ端末１１からの要求を待っている。制御プロセス１６は、ディーラ端末１１から必要な情報が送られてくると、必要に応じて計算プロセス１７を立ち上げる。計算プロセス１７は、制御プロセス１６の制御のもとで、ディーラ端末１１から送られてきた情報と、約定データに基づいて、実際の計算を行う。
【００１６】
本実施形態の金融情報処理システムが主として計算の対象とするのは、デリバティブ取引に関連する約定データである。デリバティブ取引とは、原資産の価格に応じ、その価値が決定される商品（デリバティブ商品）を取引するもので、実際の決済は先のことになる。約定データというのは、過去に行ったデリバティブ商品の取引の内容を記録したデータのことである。
【００１７】
ディーラは、今現在保有しているデリバティブ商品が、将来的にどれだけの価値を持つに至るのか、すなわち、将来の決済時点で損をすることになるのか得になるのかを、現時点で迅速に評価する必要がある。新たに取引の引き合いがあったときに、ディーラは、その引き合いを受けるべきかどうかを短時間に判断するためにも、自分が現在どれだけの資産を所有しているかを短時間に知る必要がある。加えて、その資産が、将来のある時点において、どの程度変動している可能性があるかという評価も行う必要がある。
【００１８】
しかしながら、約定データに記述されるデリバティブの価値は、前述のように、実際の金銭の集積ではなく、変動金利、原資産価値に連動して変化する。しかも、一般的に、その評価には数学理論に基づく高度な計算処理が必要で、約定数も非常に多くなると、約定データを用いた資産の評価は、コンピュータで行う必要がある。この約定データを使って、現在の自分の資産を評価する計算が、計算サーバ１２によって行われる。
【００１９】
約定は、多い場合には数千から数万という数に達するが、これらはある程度グループ化されており、それぞれのグループごとに識別用のＩＤが付されている。実際の約定データは、計算サーバ１２の内部、あるいは別の場所に備えられたハードディスク等にデータベースとして蓄えられており、ディーラ端末１１からＩＤが送られてくると、そのＩＤに対応する約定データがデータベースから計算サーバ１２の主メモリ上に読み出される。
【００２０】
図３は、計算サーバ１２上における、制御プロセス１６と計算プロセス１７との関係を示した図である。同図では、ディーラ端末１１上で稼働している３つのクライアントアプリケーション１５1 、１５2 、１５3 のそれぞれが、計算サーバ１２上の制御プロセス１６に対して計算要求１、２、３を出している状況を示している。制御プロセス１６とその下に示した三つの計算プロセス１７1 、１７2 、１７3 は、実際には一つの計算サーバ１２の中で稼働しているプロセスである。後述のように、計算サーバには多数のＣＰＵが装備されている。
【００２１】
図３には、クライアントアプリケーション１５1 、１５2 、１５3 が示してあるが、これはディーラが３人いて、それぞれが計算サーバに対して計算を要求した状況に対応する。しかし、実際の状況では、これよりも多くのディーラが存在することができる。制御プロセス１６は、複数のディーラ端末から計算要求を一括して受け取り、後述のようにして、それぞれのディーラ向けに計算プロセス１７を生成し、立ち上げて、複数のＣＰＵによる並列演算処理を行わせる。
【００２２】
図４は、図３に示した計算プロセス１７1 、１７2 、１７3 が、実際に計算を実行している状況を示した図である。各計算プロセス１７は、計算処理の状況を、制御プロセス１６を介して、ネットワーク上で対応するディーラ端末のクライアントアプリケーション１５に定期的に通知する。その内容は、当該計算プロセスが抱えている全ての約定件数のうち既に処理が済んだ約定件数の割合などであり、この割合はディーラ端末の画面にグラフと数値で表示される。
【００２３】
優先度は、元々ディーラによって指定されるものであるが、本実施形態では、制御プロセス１６が各クライアントアプリケーション１５からディーラの指定した優先度を受け取った場合、制御プロセス１６は、そのときの状況を見て、必要に応じて優先度の変更を行い、その変更後の優先度を各計算プロセス１７に対して通知する。各計算プロセス１７は、この優先度に基づいて設定しようとするスレッドの数を決める。スレッドとは、備えられているＣＰＵの数に対応して分割された処理の単位であり、計算プロセス１７によってソフトウェア的に設定されるものである。すなわち、このスレッドの数が、その計算プロセス１７が専有するＣＰＵの数となる。また、各計算プロセスは、常時、処理状況を制御プロセス１６に通知している。制御プロセス１６は、これを各クライアントアプリケーション１５にも送信し、その端末のディスプレーに表示するほか、後述のように、他の計算プロセスに対してもその処理状況を通知する。
【００２４】
図５は、計算サーバ１２内において計算プロセス１７1 、計算プロセス１７2 が生成され、これらが８個のＣＰＵ２０1 〜２０8 を用いて、どのように計算を行うかを示した図である。制御プロセス１６が、計算プロセスを生成して計算要求に基づく演算を実行させようとするときに、ＣＰＵがいくつ存在するかが重要となる。図５の場合には、８個のＣＰＵ２０1 〜２０8 があり、したがって並列度８の処理が可能となる。
【００２５】
図５において、制御プロセス１６から、まず計算プロセス１７1 が生成され、その優先度が１に設定されていたとする。このとき、計算プロセス１７1 においては、８個のスレッド３０1 〜３０8 がソフトウェア的に設定され、これらの一つ一つが８個のＣＰＵで同時に処理されることによって、並列度８の並列演算処理が実行されている。この状況のもとで、制御プロセス１６によって、計算プロセス１７2 が生成され、これを計算しなければならなくなったとする。このとき、仮に、計算プロセス１７2 の優先度が上と同じく１で設定されているとすると、並列度が８のプログラムが二つ存在することになる。この場合、ＣＰＵは８個しかないから、１６個の処理が８個のＣＰＵを取り合うことになる。その結果、先に処理が要求されている計算プロセス１７1 の処理が遅くなり、当初の予定よりも時間が余計にかかることになる。
【００２６】
そこで、図５の例では、次のような考え方を採用している。ある計算プロセスが既に存在しているときに、ディーラによってその計算プロセスと同じ優先度が指定された計算要求があった場合には、制御プロセス１６は、後からなされた計算要求の優先度を一つ下げる。図５の例では、計算プロセス１７1 の優先度は１であり、計算プロセス１７2 の優先度は、当初は１であったが、その優先度を一つ下げて２とされている。前述のように、各計算プロセスは、優先度のみによって設定するスレッドの数を決定する。具体的には、
スレッドの数 ＝ （ＣＰＵの数）／２N-1 （１）
という式に基づいてスレッドの数を決定する。ここで、Ｎは優先度の値である。例えば、ＣＰＵの数が８個で優先度が１であれば、スレッドの数は８個、ＣＰＵの数が８個で優先度が２であれば、スレッドの数は４個、ＣＰＵの数が４個で優先度が１であれば、スレッド数は４個、ＣＰＵの数が４個で優先度が２であれば、スレッド数は２個となる。
【００２７】
図５の例では、ＣＰＵの数は８個であるから、優先度Ｎ＝１である計算プロセス１７1 のスレッドの数は８個，優先度Ｎ＝２である計算プロセス１７2 のスレッド数は４個となる。計算プロセス１７2 のスレッド３１1 〜３１4 の数は、このようにして決められたものである。
このように、８個のＣＰＵを、スレッド数８の計算プロセス１７1 と、スレッド数４の計算プロセス１７2 が協調して並列処理を行うが、スレッド数が多い計算プロセス１７1 の方の処理がより速く進められる。その一方で、計算プロセス１７2 についても、計算プロセス１７1 の処理がすべて終了するまで処理が全く行われないというのではなく、計算プロセス１７1 の処理が終わるまでに、ある程度処理が進められることになる。
【００２８】
また、スレッド数は、計算プロセスの各スレッドのプログラムが決定するようにしてもよい。計算プロセスが全く生成されていない場合は、上述のように、計算プロセスが最初のスレッド数を決定する。しかし、ある計算プロセスが既に存在しているときは、その後の変更された優先度を各スレッドが受け、各スレッドのプログラムがスレッド数の増減を決定するようにしてもよい。
【００２９】
図６は、図５とは異なる考え方で、優先度を決めている例である。ここでは、ＣＰＵの数は、２１1 〜２１4 の４個であり、最初は（ａ）に示すように、優先度が１の計算プロセス１７1 のみが生成されていたとする。スレッドの数は、（１）式に基づいて４となり、４つのスレッド３５1 〜３５4 が設定され、並列度４の並列処理が行なわれている。
【００３０】
その後、別の計算要求があり、ディーラが指定したその優先度も同じく１だったとする。制御プロセス１６は、この計算要求に基づいて計算プロセス１７2 を生成するが、このとき制御プロセス１６は、図５の場合の考え方とは異なり、両方の優先度を２に下げる。その結果、（１）より、両者のスレッド数はいずれも２となり、各計算プロセス１７1 、１７2 は、スレッドの組み換えを行い、計算プロセス１７1 はスレッド３６1 、３６2 を再設定し、計算プロセス１７2 はスレッド３７1 、３７2 を設定する。
【００３１】
その後更に、計算プロセス１の処理が終了すると、制御プロセス１６は、計算プロセス１７2 の優先度を１に上げる。その結果、計算プロセス１７2 は、再度スレッドの組み換えを行い、スレッド３８1 〜３８4 を再設定する。
図６のようにすると、複数の計算要求があって、それらの優先度が等しい場合には、両方を平等に取り扱って処理が実行される。また、優先度に基づいてスレッド数を決定することにより、制御プロセスが優先度を変更すると、計算プロセスが処理を実行している最中であっても、状況に応じて、動的にスレッドの数を変えて適切な状況を設定することができる。
【００３２】
図７は、ある計算プロセス１７の動作を模式的に示した図である。図７において、入力側の共有メモリ４０は、計算サーバ１２に備えられたＲＡＭ等からなる主メモリである。共有メモリ４０には、この計算プロセスが抱えている約定データが記憶され、一つのファイルとされる。図７の例では、ｎ件の約定データ４１1 〜４１n が記憶されている。約定データは、元々計算サーバ１２の内部又は外部に設けられたハードディスク等の記録装置にデータベースとして蓄えられており、これを計算プロセスが引き出して、入力側の共有メモリ４０に記憶させる。共有メモリ４０に記憶された約定データの全体を、「約定テーブル」又は「約定テーブルファイル」ともいう。
【００３３】
実際に計算を行う場合には、計算プロセスは、まずデータベースから約定データを取ってきて、共有メモリ４０上に書き込んで、約定データファイルとする。その後、ソフトウェア的にスレッドを設定する。図７では、一例として、四つのスレッド４３1 、４３2 、４３3 、４３4 が設定されている。一つのスレッドが、一つのＣＰＵを使って独立に処理を行う単位となるので、四つのスレッドがそれぞれ一つずつ、共有メモリ４０から約定データを読み出して、合計四つのＣＰＵを使って並列度４の並列処理を行っている。
【００３４】
この約定データの読み出しの際には、ロック機構４２の排他制御によって、あるスレッドが共有メモリ４０から約定データを読み出している間は、他のスレッドが約定データの読み出しを行うことができないようになっている。また、同じ約定データを複数のスレッドで処理することのないように、一度あるスレッドによって読み出された約定データは、他のスレッドからは読み出されないようにしている。なお、ロック機構４２は、後述するように、実際にはロックファイルと、各スレッドがこのロックファイルを見に行ってアクセスできるかどうかを判断することによって実現される。
【００３５】
図７の例では、ｎ件の約定が一つずつ順番に処理されるのではなく、四つのＣＰＵが協調しながらｎ件の約定を処理する。このように並列的な処理を行うことによって、処理に要する時間が短縮される。
各スレッドごとにＣＰＵによって計算されたデータは、出力側の共有メモリ４５に、例えばマトリックス形式のデータとして書き込まれる。この共有メモリ４５も、計算サーバ１２の主メモリである。このとき、各スレッドが無秩序にデータを書き込むと、データ全体の整合がとれないという問題が生じるので、この場合も、ロック機構４４が働いて、あるスレッドが共有メモリ４５にデータを書き込んでいるときには、他のスレッドがデータの書き込みを行うことができないような排他制御を行う。
【００３６】
図８は、図７に示した入力側の共有メモリ４０上に展開されている約定テーブルファイルを示している。このテーブルの各行に約定テーブルが置かれており、各行の右端には、１ビットの処理済フラグが設けられている。各スレッドは、自分が処理を実行している約定データには処理済フラグ「１」をセットし、その約定データは既に処理が済んでいることを表示する。他のスレッドは、このテーブルを見るときに、処理済フラグ「１」がセットされている約定データはスキップし、処理済フラグが「０」の約定データを探して読み出す。このとき、本実施形態では、処理済フラグが「０」の約定データのうち、一番上にある約定データをポインタが指し示すようにしている。スレッドは、このポインタを探して読み出すべきデータを見つけ出す。こうすることによって、スレッドが簡単に読み出すべき約定データを探しだせるようにしている。但し、ポインタを用いずに、スレッドが処理済フラグをスキャンして、「０」のものを見つけ次第それを読み出すようにしてもよい。
【００３７】
図９は、一つの計算プロセスにおいて行われる処理の手順を示したフローチャートである。この処理は、制御プロセス１６が、計算プロセス１７を立ち上げたときに開始される。計算プロセスが立ち上がり、約定データがデータベースから読み出され、入力側の共有メモリ４０に記憶されると、この計算プロセスにおいて図９に示す処理手順が開始される。
【００３８】
図９の処理手順が開始されると、まず、図５、図６又は図７に示すように、スレッドが設定される（Step１０）。スレッドの数の決定は、前述のように、制御プロセス１６から出てくる優先度に基づいてなされる。一方、仮に、既に別の計算プロセスが立ち上がっている場合には、制御プロセス１６が、予め定められたアルゴリズムに基づいて、必要に応じてディーラによって指定された優先度を変更する。この優先度に応じて所定数のスレッドが設定される。
【００３９】
次に、他のスレッドが参照すべきロックファイルを生成する（Step１１）。他のスレッドは、このロックファイルを参照することによって、図７に示した共有メモリ４０及び４５が排他状態か否かを判断する。
Step１１においてロックファイルが生成されたあとは、本来の目的である演算が並列処理によって実行される（Step１２）。すなわち、スレッドの数に対応したＣＰＵによって、同時に演算が実行される。なお、計算プロセス自体を動作させるメインのＣＰＵは、実際の計算を実行するＣＰＵとは別に設けられている。並列処理が終了すると、ロックファイルを解除し（Step１３）、スレッドを消去して（Step１４）、この計算プロセス自身も消滅する。以上で、一つの計算プロセスの処理が終了する。
【００４０】
図１０は、図９に示した処理手順のうちStep１２の部分の処理手順を詳しく示したフローチャートである。Step２０では、まず、図７に示したロック機構４２がロック状態であるかどうか、すなわち別のスレッドがロック機構４２をロック状態にしているかどうかを判断する。ロックがされておらず、自分が共有メモリ４０から約定データを読み出せる状態であれば、他のスレッドが読み出しを行うことができないように、ロック機構４２のロックをかける（Step２１）。次に、スレッドは、約定データの中から、図８に示すようにポインタが指し示している処理済フラグが「０」の約定データを探して、それをフェッチするという処理を行い（Step２２）、そして、その約定データの処理済フラグに「１」をセットする（Step２３）。このスレッドが約定データを読み出して、その約定データの処理済フラグに「１」をセットすると、共有メモリ４０へのアクセスを排除する必要がなくなるのでロックを解除し（Step２４）、その後、実際の計算処理に移行する（Step２５）。計算が終わると、その結果を出力側の共有メモリ４５へ書き込む（Step２６）。Step２７では、未処理の約定データがあるかどうかを判断する。未処理のものがある場合には、上で説明したのと同様の処理を繰り返し、一方、未処理の約定データがなくなった場合には、処理を終了する。
【００４１】
図１１は、計算プロセスと制御プロセス１６との間で実行する処理の手順を示したフローチャートである。
図１１において、現在存在する計算プロセスの数に変化があったかどうかを検出している（Step３０）。例えば、現在ある計算プロセスが生成されているときに、ディーラ端末１１から新たな計算要求があった場合には、制御プロセス１６が新たな計算プロセスを生成するので、計算プロセスの数は増加する。一方、ある計算プロセスの処理が終了し、計算プロセスが消滅すると、計算プロセスの数は減少する。Step３０において、制御プロセスは、計算プロセスの生成あるいは終了を検知すると、プロセス数を確認し、Step３１において、各計算プロセスに通知する。制御プロセス１６は、各計算プロセスの優先度を見直し、必要に応じて優先度を変更して、各計算プロセスに通知する。各計算プロセスは、変更後の優先度に応じて、前述の（１）式に基づいてスレッドの数を決定し、既にあるスレッドを消去した上で、スレッドを再設定する（Step３２）。
【００４２】
このように、本実施形態では、各計算プロセスの内部におけるスレッドの数を、計算要求の有無に応じて、動的に変化させる。このスレッドの数を変える際に基礎となるのは、前述のように優先度だけである。このように、実際に並列処理が実行されている途中においても、計算要求の有無に応じて、スレッドの数を動的に変化させることによって、効率的で無駄の少ない処理が可能となる。また、この際、基礎とするのが優先度だけなので、処理内容が簡素化される。
【００４３】
なお、上述したように、計算プロセスの各スレッドのプログラムによってスレッド数を変更するようにしてもよい。その場合、優先度に応じて、各スレッドが自らを終了させるか、新しいスレッドを生成することによって、スレッド数を適正値に収束させるようにしてもよい。
図１２は、ある一つの計算プロセスの処理手順全体を示したフローチャートであり、したがって、図１０で説明した処理を含んでいる。
【００４４】
図１２の処理手順がスタートすると、まずStep４０で、図７に示したロック機構４２がロック状態であるかどうか、すなわち別のスレッドがロック機構４２をロック状態にしているかどうかを判断する。ロックがされておらず、自分が共有メモリ４０から約定データを読み出せる状態であれば、他のスレッドが読み出しを行うことができないように、ロック機構４２のロックをかける（Step４１）。次に、スレッドは、約定データの中から、図８に示すようにポインタが指し示している処理済フラグが「０」の約定データを探して、それをフェッチするという処理を行い（Step４２）、そして、その約定データの処理済フラグに「１」をセットする（Step４３）。このスレッドが約定データを読み出して、その約定データの処理済フラグに「１」をセットすると、共有メモリ４０へのアクセスを排除する必要がなくなるのでロックを解除し（Step４４）、その後、実際の計算処理に移行する（Step４５）。計算が終わると、その結果を出力側の共有メモリ４５へ書き込む（Step４６）。ここまでは、図１０に示した処理手順と同じである。
【００４５】
次に、この計算プロセスは、他の計算プロセスの実行状況に変化があったかどうかを見る（Step４７）。他の計算プロセスの実行状況に変化があったか否かは、制御プロセス１６に問い合わせることによって知ることができる。他の計算プロセスの実行状況に変化がなければ、更に、未処理データがあるかどうか見て（Step４８）、なければ処理を終了し、未処理データがある場合には、最初に戻って同様の処理を繰り返す。
【００４６】
Step４７において、他の計算プロセスの実行状況に変化があった場合には、既に設定してあるスレッドを消去する必要があるかどうかを判断する（Step５０）。ここでいうスレッドの消去とは、スレッドの再設定のことは含まない、完全に消去し、処理を終了することを意味している。スレッドを消去する場合とは、例えば、その計算プロセスに通知されている優先度よりも高い優先度の別の計算プロセスが生成され、当該別の計算プロセスの処理を優先して実行するように設定されている場合に、一度その計算プロセスのスレッドを消去し、当該別の計算プロセスの処理が終了したあとに再度スレッドを設定するといった場合が該当する。但し、この場合にスレッドは消去されも、計算プロセスそのものは存続している。
【００４７】
スレッドを消去してよい場合には、Step７０において、スレッドを消去し、処理を終了する。一方、スレッドを消去しない場合には、スレッド数が増加するかどうかを判断する（Step５１）。スレッド数が増加しない場合には、未処理データがあるかどうかを判断し（Step５２）、なければ処理を終了し、未処理データがある場合には、最初に戻って同様の処理を繰り返す。
【００４８】
一方、Step５１で、スレッド数が増加する場合にも、同じく未処理データがあるかどうかを判断し（Step６０）、なければ処理を終了し、未処理データがある場合には、未処理として残っているデータが所定数を超えているかどうかを判断する（Step６１）。未処理データが当該所定数を超えていれば、予定どおりスレッドを増加し（Step６２）、最初に戻って処理を行うが、未処理データが当該所定数を超えていなければ、スレッドの数を増やすまでもないので、そのまま最初に戻って処理を行う。
【００４９】
図１３は、計算プロセスの各スレッドのプログラムが、所定の演算により自らを終了させ、あるいは新たなスレッドを発生させて、最終的に適正なスレッド数に収束させる場合の処理手順全体を示したフローチャートであり、したがって図１２と同様に、図１０で説明した処理を含んでいる。
図１３のStep１４０からStep１４６までは、図１２のStep４０からStep４６までと同様であるので、説明を省略する。この例では、優先度の値データは、計算プロセスとスレッドのプログラム両者によって参照されるため、共有領域にあり、両者による参照を可能とするための排他制御が行われる。すなわち、Step１４７で、優先度データの共有メモリがロック状態（参照不可状態）か否かを判断し、ロック状態でなければロックし（Step１４８）、優先度Ｎの変化を判断する（Step１４９）。変化がなければ、ロックを解除し（Step１７０）、未処理データがあれば、Step１４０へ戻る。
【００５０】
Step１４９で、優先度Ｎに変化があったときは、Step１５０において、全体のスレッド数Ｍが、計算して求めたスレッド数より大きいかが判断される。Ｍはそのときに存在しているスレッド数であって、共有領域に記載されている。Ｍが計算されたスレッド数より大きければ、Ｍを一つ減少させ（Step１５１）、ロックが解除され（Step１７２）、スレッドは消去される（Step１７３）。
【００５１】
また、Ｍが計算値よりも小さければ、未処理データがあるか否かを判断し（Step１６０）、なければStep１７２へ進み、ロックを解除する。未処理データがあれば、残りデータ数が所定値以上か否かを判断し（Step１６１）、所定値以上であればスレッドを生成し（Step１６２）、Ｍを一つ増加し（Step１６３）、ロックを解除する（Step１６４）。
【００５２】
このように、優先度に基づくスレッド数よりも、プロセス内のスレッド数が多い場合には、多い分のスレッドが自らを終了してゆき、全体としては、最終的に適正なスレッド数に収束することになる。また、増加するときも適正なスレッド数に徐々に近づき、結果的に収束することになる。
なお、本発明は、上記実施形態に限定されるものではなく、その要旨の範囲内で種々の変更が可能である。たとえば、上記実施形態では、ＣＰＵが８つの場合と４つの場合について説明したが、ＣＰＵの数はこれらに限定されるものではなく、任意の数のＣＰＵを用いて並列処理を行う場合にも適用できる。
【００５３】
【発明の効果】
以上説明したように、本発明によれば、例えば、デリバティブ取引の際に資産価値や資産価値の増減を評価するために行う約定データの計算を、複数のＣＰＵを用いて並列処理によって実行させるので、迅速な処理が可能となり、結果が出るまでの時間を短縮させることができる。更に、計算プロセスが設定するスレッドの数を、他の計算プロセスの実行状況を見て動的に変化させることにより、並列処理の効率を向上させることができるので、より迅速な処理が可能となり、結果が出るまでの時間を更に短縮させることが可能となる情報処理システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の金融情報処理システムの全体的な構成を示す図である。
【図２】図１に示すシステムのうち、ディーラ端末１１と計算サーバ１２を１台ずつ示した図である。
【図３】計算サーバ１２上における、制御プロセス１６と計算プロセス１７との関係を示した図である。
【図４】図３に示した計算プロセス１７1 、１７2 、１７3 が、実際に計算を実行している状況を示した図である。
【図５】計算サーバ１２内において計算プロセス１７1 、計算プロセス１７2 が生成され、これらが８個のＣＰＵ２０1 〜２０8 を用いて、どのように計算を行うかを示した図である。
【図６】二つの計算プロセス１７が生成されたときに、動的にスレッドが再設定される様子を示した図である。
【図７】計算プロセス１７の動作を模式的に示した図である。
【図８】図７に示した入力側の共有メモリ４０上に展開されている約定テーブルファイルを示した図である。
【図９】一つの計算プロセスにおいて行われる処理の手順を示したフローチャートである。
【図１０】図９に示した処理手順の一部の処理手順を詳しく示したフローチャートである。
【図１１】計算プロセスが制御プロセスとの間で実行する処理の手順を示したフローチャートである。
【図１２】ある一つの計算プロセスの処理手順全体を示したフローチャートである。
【図１３】他の一つの計算プロセスの処理手順全体を示したフローチャートである。
【符号の説明】
１０ ネットワーク
１１ ディーラ端末
１２ 計算サーバ
１３ ディスプレー
１４ キーボード
１５ クライアントアプリケーション
１６ 制御プロセス
１７ 計算プロセス
２０，２１ ＣＰＵ
３０，３１，３５，３６，３７，３８，４３ スレッド
４０ 入力側共有メモリ
４１ 約定データ
４２，４４ ロック機構
４５ 出力側共有メモリ
Claims (7)
- 複数の端末と接続され、前記複数の端末から要求された計算処理を実行するための情報処理装置であって、
データが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいて計算要求毎に計算プロセスを生成する計算プロセス生成手段と、
他の計算プロセスの実行状況、或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する優先度変更手段と、を備え、
前記計算プロセスは、
前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて、前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出し、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせ、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる、
処理を行うことを特徴とする情報処理装置。 - 前記計算プロセスが決定するスレッド数は、
前記優先度の値が大きくなるほど、前記スレッド数が少なくなる演算式を用いてスレッド数を算出することを特徴とする請求項１記載の情報処理装置。 - 前記優先度変更手段は、
前記優先度が他の端末から先に受信した計算要求の優先度と同値であった場合、後から受信した計算要求の優先度を下げる、或は、両方の優先度を同数下げ、計算プロセスに変更後の優先度を通知することを特徴とする請求項１又は２の何れか１項に記載の情報処理装置。 - 複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理方法であって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する工程と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する工程と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する工程と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる工程と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる工程と、
を具備することを特徴とする情報処理方法。 - 前記計算プロセスが決定するスレッド数は、前記優先度の値が大きくなるほど、前記スレッド数が少なくなる演算式を用いることを特徴とする請求項４記載の情報処理方法。
- 前記計算プロセスについて、前記優先度が他の端末から先に受信した計算要求の優先度と同値であった場合、後から受信した計算要求の優先度を下げる、或は、両方の優先度を同数下げ、計算プロセスに変更後の優先度を通知することを特徴とする請求項４又は５の何れか１項に記載の情報処理方法。
- 複数の端末と接続された情報処理装置において、前記複数の端末から要求された計算処理を実行するための情報処理プログラムであって、
計算プロセス生成手段によってデータが記述されたデータファイルについての前記複数端末から受信した計算要求に基づいた計算プロセスを生成する機能と、
優先度変更手段によって、前記生成された計算プロセスについて、他の計算プロセスの実行状況或は新たに端末から受信した計算要求の優先度に基づいて現在設定されている計算要求の優先度を自動的に変更し、前記計算プロセスに変更後の優先度を通知する機能と、
前記計算プロセスによって、前記優先度或は前記優先度変更手段で変更された優先度、及び要求された計算処理を実行する演算手段の数に基づいて前記演算手段に計算処理させる処理単位数であるスレッド数を自動的に算出する機能と、
前記計算プロセスのスレッドに、算出したスレッド数に基づいて自らのスレッドの消滅、或は、新たなスレッドの生成を行わせる機能と、
前記各スレッドについて、対応する前記演算手段に、前記データファイルから読み出されたデータに対する並列演算処理を実行させる機能と、
を実現するための情報処理プログラムを記録したコンピュータ読み取り可能な記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27097897A JP3797402B2 (ja) | 1997-10-03 | 1997-10-03 | 情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27097897A JP3797402B2 (ja) | 1997-10-03 | 1997-10-03 | 情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11110452A JPH11110452A (ja) | 1999-04-23 |
| JP3797402B2 true JP3797402B2 (ja) | 2006-07-19 |
Family
ID=17493696
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27097897A Expired - Fee Related JP3797402B2 (ja) | 1997-10-03 | 1997-10-03 | 情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3797402B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001014324A (ja) | 1999-06-28 | 2001-01-19 | Sony Corp | ユーザ情報処理装置、ユーザ情報処理システム、端末装置、情報提供装置及び方法 |
| JP4586873B2 (ja) * | 2008-03-28 | 2010-11-24 | セイコーエプソン株式会社 | ソケット管理装置及び方法 |
-
1997
- 1997-10-03 JP JP27097897A patent/JP3797402B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11110452A (ja) | 1999-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10372723B2 (en) | Efficient query processing using histograms in a columnar database | |
| US7975268B2 (en) | Grid computing system, management server, processing server, control method, control program and recording medium | |
| CN110806933B (zh) | 一种批量任务处理方法、装置、设备和存储介质 | |
| US8707308B1 (en) | Method for dynamic management of system resources through application hints | |
| US8224813B2 (en) | Cost based analysis of direct I/O access | |
| US20070024898A1 (en) | System and method for executing job step, and computer product | |
| CN109240946A (zh) | 数据的多级缓存方法及终端设备 | |
| US7529892B2 (en) | File readahead method with the use of access pattern information attached to metadata | |
| US7444477B2 (en) | System and method for efficiently performing memory intensive computations including a bidirectional synchronization mechanism for maintaining consistency of data | |
| JP4536833B2 (ja) | 金融情報処理システム | |
| CN109871181A (zh) | 一种对象存取方法及装置 | |
| WO2020238860A1 (zh) | 分布式文件批处理方法、装置、与可读存储介质 | |
| US8539492B1 (en) | Managing data dependencies among multiple jobs using separate tables that store job results and dependency satisfaction | |
| US9405786B2 (en) | System and method for database flow management | |
| US20110093688A1 (en) | Configuration management apparatus, configuration management program, and configuration management method | |
| CN113010376A (zh) | 一种对存储训练数据的云存储系统的监测方法及装置 | |
| JP3797402B2 (ja) | 情報処理システム、情報処理方法及び情報処理プログラムを記録した記録媒体 | |
| CN115774621B (zh) | 一种请求处理方法、系统、设备及计算机可读存储介质 | |
| US11816020B2 (en) | Online query execution using a big data framework | |
| CN109308310B (zh) | 一种用于资产管理平台的子系统数据互联处理方法 | |
| US11870706B2 (en) | Method and system for allocating and managing cloud resources | |
| US20230137673A1 (en) | Systems and methods for dynamically scaling remote resources | |
| JP2012514272A (ja) | リアルタイム取引予測 | |
| CN107705089B (zh) | 业务处理方法、装置及设备 | |
| CN113190332B (zh) | 用于处理元数据的方法、设备和计算机程序产品 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051201 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060130 |
|
| 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: 20060329 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060411 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090428 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |