JP2008102847A - マルチスレッドプログラム処理方法及び装置 - Google Patents

マルチスレッドプログラム処理方法及び装置 Download PDF

Info

Publication number
JP2008102847A
JP2008102847A JP2006286497A JP2006286497A JP2008102847A JP 2008102847 A JP2008102847 A JP 2008102847A JP 2006286497 A JP2006286497 A JP 2006286497A JP 2006286497 A JP2006286497 A JP 2006286497A JP 2008102847 A JP2008102847 A JP 2008102847A
Authority
JP
Japan
Prior art keywords
stack
thread
shared
threads
stream
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.)
Withdrawn
Application number
JP2006286497A
Other languages
English (en)
Inventor
Takeshi Fujiyoshi
猛 藤吉
Koichi Sato
浩一 佐藤
Yoji Ueno
洋史 上野
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2006286497A priority Critical patent/JP2008102847A/ja
Publication of JP2008102847A publication Critical patent/JP2008102847A/ja
Withdrawn legal-status Critical Current

Links

Images

Abstract

【課題】多数のスレッドを同時に実行するマルチスレッドプログラムにおいて、 スタック領域のために消費されるメモリ量を節約する。
【解決手段】全スレッドに割り当てられる複数のスレッド個別スタック7と、 該個別スタックの数より少なく、前記スレッド間で共有される複数の共有スタック8を使用し、
外部イベント待ちに至る可能性のあるスレッド(処理経路)では個別スタック7を使用し、それ以外のスレッドでは共有スタック8を使用することによりメモリ使用量を節約することを特徴とするマルチスレッドプログラム処理方法。
【選択図】図1

Description

本発明は、マルチスレッドプログラムにおけるスタック管理技術に関し、 特にスタック領域により消費されるメモリ量を節約する技術に関する。
ソフトウェアのプログラム構成としてマルチスレッドが用いられることが多い。具体例としてネットワークのトラフィックを処理するアプリケーションは1つのセッション(またはフロー、ストリーム)に対して1つのスレッドを割り当て、1つのプロセッサ上で同時並行に実行する。マルチスレッドプログラムでは、同時に実行される全てのスレッドに対して個別のスタック領域が必要でありそのサイズはプログラムの構造によって異なる。
規模の大きなプログラムではスタック使用量が大きくなる傾向にあり、同時に実行するスレッド数が多くなるとスタック領域のためにメモリが圧迫される。 1つのセッションに1つのスレッドを割り当てると、より多くのセッションを同時に処理できるようにするためにはより多くのメモリが必要となる。この問題を解決するための従来技術として特許文献1がある。該従来技術はスレッド(タスク)実行時は共有スタックを使用しスリープするときに共有スタックの内容を別領域に退避することにより、メモリ使用量の効率化を計るものである。この方式の問題点は、スタック内の使用中の領域のサイズが増加するとスタック内の使用中領域のサイズが増加するとスタックの退避/復旧のためのメモリコピー時間も増加することであり、この方法を使わない場合に比べ性能が著しく劣化する恐れがある。
特開2005-71141
本発明の目的は、多数のスレッドを同時に実行するマルチスレッドプログラムにおいて、スタック領域のために消費されるメインメモリ量の節約を可能とするマルチスレッドプログラム処理方法および装置を提供することである。
さらに、本発明の他の目的はメインメモリを用いてより多くのスレッドの同時実行を可能にするマルチスレッドプログラム処理方法および装置を提供することである。
さらに、本発明の他の目的は各共有スタックのメモリサイズを各スレッド個別スタックに比べて遙かに大きくすることによりプログラマーの注意力をスレッド個別スタックの使用量にのみ集中させ、これによりプログラマーの負担を軽減させるマルチスレッドプログラム処理方法および装置を提供することである。
さらに、本発明の他の目的はスタック使用量が増加しても性能低下が発生しないマルチスレッドプログラム処理方法および装置を提供することである。
第一の観点に基づく本発明のマルチスレッドプログラム処理方法は複数のスレッドに対し1対1の関係で複数のスレッド個別スタックを割り当て、
前記個別スタックの数より少なくかつ各のメモリサイズが各スレッド個別スタックのメモリサイズよりも大きい複数の共有スタックを設け、外部イベント待ちに至る可能性のあるスレッドでは前記スレッド個別スタックを使用し、それ以外のスレッドでは前記共有スタックを使用することにより前記複数の共有スタックを前記スレッド間で共有することを特徴とする。
更に、第二の観点に基づく本発明のマルチスレッドプログラム処理装置は複数のスレッド全てに対して1対1の関係で割り当てられる複数のスレッド個別スタックと、前記個別スタックの数より少なくかつ各のメモリサイズが各スレッド個別スタックのメモリサイズよりも大きい複数の共有スタックと、外部イベント待ちに至る可能性のあるスレッドでは前記スレッド個別スタックを使用し、それ以外のスレッドでは前記共有スタックを使用することにより前記複数の共有スタックを前記スレッド間で共有する処理手段と具備することを特徴とする。
本発明の第1の効果は、外部イベント待ちに至る経路以外でのスタック領域の個数はスレッド数に比べて少数であるため、外部イベント待ち経路のスタック使用量を少なくすれば、全体としてスタック領域によるメモリ使用量を削減することができる。
第2の効果は、従来はスタック使用量節約のためプログラム全域に亘りスタックの使用状況に注意してプログラムを組む必要があったが、
本発明の方式では外部イベント待ち経路では個別スタックより数の少ない共有スタックを使用し、かつ1つの共有スタック領域のメモリサイズをスレッド個別スタックに比べて遙かに大きくすれば、プログラマはスレッド個別スタックを使用する処理においてのみスタック使用量にのみ注意すればよく、共有スタックの使用量に注意する必要がない。
第3の効果は、共有スタックを用いることによりスレッド個別スタックのためのメモリ使用量を小さくできるため、限られた量のメモリを用いてより多くのスレッドを同時に実行することが可能であり、殊にネットワーク処理を行うアプリケーションではより多くのセッションを同時に処理することが可能となる。
第4の効果は、 特許文献1のようにスタック内のデータを別領域へ退避させる必要がないためスタック使用量が増加してもメモリコピーによる性能低下が発生しない。
図1は本発明の基本構成を示し、メインメモリ4に格納されアプリケーションプログラム1と、スレッド管理部2とスタック管理部3とからなり、該プログラムを実行するCPU5を含みアプリケーション実行環境を構成する。
アプリケーションプログラム1はスレッド管理部2が提供するルーチンを用いてスレッドの生成、切り換えを行うマルチスレッド型のプログラムである。現在実行中のスレッドがイベント待ち状態に入ったとき、外部イベント源10または内部イベント源11から通知されるイベントに基いてスレッドを切り換える。また、スタック管理部3が提供するルーチンを用いて複数のスレッド個別スタック7と該個別スタックの数より少ない複数の共有スタック8の間の切り換えを行う。
スレッド管理部2はスレッドの生成およびスレッドの切り換えを行い生成した各スレッドに対してスレッド管理情報6とスレッド個別スタック7の領域をメインメモリ4内に割り当てる。また、スレッド切り換え時には、現在実行中のスレッドのスレッド管理情報6の中にCPU5の現在のコンテキスト9を保存し、新しく実行するスレッドのスレッド管理情報6に保存されたコンテキスト9をCPU5にロードする。
スタック管理部3は共有スタック8の割当、解放及び個別スタック7と共有スタック8の切り換えを行う。このスタック切り換えは、現在のスタックポインタの内容をスレッド管理情報6の中に保存し、新しいスタックのアドレスをスタックポインタ(SP)にロードすることにより行なわれる。
スレッド管理情報6はスレッドごとに割り当てられる固定サイズの領域であり、この領域には、現在実行していない(待ち状態の)スレッドのコンテキスト9が保存される。また、ある共有スタック8を使用中のスレッドは該共有スタックに切り換える直前に指定していたスレッド個別スタック7のスタックポインタの内容を保存する。
外部イベント源10は外部イベントを生成しアプリケーションプログラム1へ通知する。 外部イベントはシステム外部の要因により生成されるイベントであり、例えば、ネットワーク処理の場合は外部からのデータ受信が外部イベントとなる。
内部イベント源11は内部イベントを生成しアプリケーションプログラム1へ通知する。内部イベントは、アプリケーションプログラム1が発行した処理要求に対して何らかの処理が行われた結果として生成されるイベントであり、アプリケーションプログラム1が処理要求を発行してから比較的短い所定時間内に必ず発生する。
スレッド個別スタック7と共有スタック8はプログラム1の実行に必要となる スタック領域であり、各領域は連続するアドレス空間の中に確保される。スレッド個別スタック7は1スレッドに1つずつ割当てられるスタック領域であり、同時に実行される可能性のあるスレッド数分だけ存在する。また、スレッド個別スタック7は外部イベント待ちに至る可能性のある処理経路(スレッド)において使用される。外部イベントはいつ発生するか分からないため、全スレッドが同時に外部イベント待ち状態に入る可能性がある。そのため、プログラムの最上位ルーチンから外部イベント待ち状態に至るまでの状態はスレッド個別スタック7に保存される。
共有スタック8は複数のスレッド間で共有されるスタック領域であり、その個数はスレッド数よりも少なく、各のサイズはスレッド個別スタック7よりも大きく、外部イベント待ちに至る可能性のない処理経路において使用される。
上述のごとく、内部イベントはプログラム1が内部イベント源11に対して処理要求を発行してから一定時間以内にイベント発生するためスレッドが最初に外部イベントを受けた後、内部イベント待ちを何回か行い再び外部イベント待ちに戻るまでの時間も一定時間以内である。これは、共有スタック8は割り当てられてから必ず一定時間以内に解放されることを意味する。また、同時に内部イベント待ち状態に入れるスレッド数は共有スタックの数に制限されることを意味する。
図2に示すごとく本システムのハードウェアはメインメモリを含むCPU20、ストリーム受信器21、ストリームバッファ22、パターン検索器23、ログストレージ24とから構成される。ストリーム受信器21は外部ネットワークから入力されるトラフィックからストリームを抽出しストリームバッファに保存する。
CPU20から特定ストリームに対する「受信要求」を受けると未通知の受信済みデータが存在するか否かを調べ、存在する場合「受信通知」(外部イベント)としてCPU20に知らせる。
未通知の受信済みデータが存在しない場合は次のデータを受信してから受信通知をCPU20に送る。
ストリームバッファ22はストリーム受信器21が抽出したストリームを 保存しCPU20からの読み出し要求を受ける。該読み出し要求において、CPU20はストリームバッファ22内の特定ストリームのデータ読み出し範囲と転送先のメモリ領域を指定する。ストリームバッファ22は該読み出し要求が指定する範囲のデータを読み出し、これを指定されたメモリ領域に転送し、転送が終了すると「読出し完了通知(内部イベント)」をCPU20に返送する。
パターン検索器23はCPU20から「検索要求」を受けると該検索要求が指定するストリーム、データ範囲、文字列パターンを検索キーとしてストリームバッファ22を検索し、
指定された文字列パターンが指定されたストリームの指定された範囲のデータ中に含まれている場合はその文字列パターンのバイト位置を「検索結果通知」としてCPU20に通知する。
ログストレージ24はCPU20から「ログ保存要求」を受けると該保存要求が指定するデータのログを保存する。本要求に対する応答はない。
ストリーム受信器に入力される各ストリームは連続する複数のメッセージからなり、各メッセージは1つのヘッダとそれに続く1つのボディから構成される。ボディ長はヘッダ内の特定のフィールドが指定する。
CPU20はマルチスレッドアプリケーションプログラム1に基づきストリーム受信部21が受信したストリーム中の各メッセージの1行目を抽出しログストレージ24に出力し1つのストリームに対して1つのスレッドを実行する。
図3はアプリケーションプログラム1の構成を示す。 楕円で示す部分は処理ルーチンを表わし、各楕円の中の文字列はルーチンの名称、
括弧内の数字はそのルーチンで使用するスタックのバイトサイズを示している。
各ルーチン間を結ぶ実線および破線の矢印はサブルーチン呼出しの関係を表 わしている。実線の矢印はスレッド個別スタック7を使用する処理経路におけるサブルーチン呼出しを示し、破線の矢印は共有スタック8を使用する処理経路におけるサブルーチン呼出しを示す。星印はサブルーチン呼出し時に個別スタック7から共有スタック8への切り換え、サブルーチンから呼出し元への復帰時に共有スタック8から個別スタック7への切り換えを行うポイントを示している。
以下に各処理ルーチンの概要を説明する。
ThreadMain 30はスレッドの最上位ルーチンでありHeaderProc 31を用いてヘッダ受信、ログ出力とボディ長の取得を1つのメッセージについて行った後、
BodyProc 32を用いてボディ全体を受信するまで待つ。この処理をストリームが終了するまで繰り返す。
HeaderProc 31はストリーム内の各メッセージのヘッダを受信し、その1行目をログストレージ24へ出力し受信したヘッダからホディ長を検出する。
HeaderProc 31は最初にStrmRecvWait 33を用いて次のデータの受信を待ちEoHdrCheck 34を用いて過去に受信したデータを検査しヘッダ全体を受信し終わったか否かを判定する。まだヘッダ全体の受信が終わっていなければ再びStrmRecvWait 33を用いて次のデータの受信を待つ。ヘッダ全体を受信し終わったら、次にLogProc 35を用いてヘッダの1行目をログストレージ24に格納する。最後に、BodyLenGet 36を用いてヘッダの中からボディ長を抽出する。
BodyProc 32はヘッダに続くホディ全体を受信し終えるまで待つ。
本ルーチンは最初にStrmRecvWait33を継続して用いて次のデータを受信するのを待つ。 ボディの最後まで受信し終えたら処理終了する。
StrmRecvWait
33はストリームの次のデータを受信するまで待ちStrmRecvReq 37を用いてストリーム受信器21に対して受信要求を発行し、次にEventWait 38を用いてストリーム受信器21からの受信通知を待つ。
EventWait 38は次の外部イベントまたは内部イベントを検出するまで待ち
新しいイベントを検出したらスレッド管理部2のルーチンを使用してそのイベントに対応するスレッドに実行を切り替える。切り替え元のスレッドはそのスレッドに対応するイベントを検出するまでEventWait 38に留まる。本ルーチンはアプリケーションプログラム1において唯一スレッド切り替えを行う箇所である。現在実行中のスレッド以外のスレッドは初期状態を除いてEventWait38に留まる。
EoHdrCheck 34は現在受信しているメッセージにおいてヘッダの最後、即ち空行が含まれているか否かを検査するルーチンである。本ルーチンはPattSearch39を用いて受信済みストリームの中から空行を探す。
PattSearch39は受信済みストリーム中の特定のバイト範囲のデータに特定のパターンが含まれているか否かを検査し、含まれている場合そのパターンのストリーム上のバイト位置を返信する。本ルーチンは、PattSearchReq40を用いてパターン検索器23に検索要求を発行し、EventWait41を用いてパターン検索器23からの検索結果通知を待つ。
BodyLenGet
36は受信したヘッダの中に格納されたボディ長を取得する。 最初にPattSearch39を用いヘッダからボディ長を含むフィールドのバイト位置を検索し、次にStrmBuffRead42を用いそのフィールド全体のデータをストリームバッファ22からメインメモリの指定された場所に転送する。最後に、そのフィールドからボディ長を抽出する。なお、この転送を実行する際、StrmBuffRead42はStrmBuffReadReq43を用いストリームバッファ22に読出し要求を発行し、EventWait 41を用いストリームバッファ22からの読出し完了通知を待つ。
LogProc 35は受信済みヘッダの1行目をログストレージ24に保存する。
本ルーチンは、最初にStrmBuffRead 42を用いヘッダの最初の特定バイト数の データをストリームバッファ22からメインメモリに読み込み、LogWrite 44を用いログストレージ24に対してログ書込み要求を発行しメインメモリ上で指定された前記データの先頭から最初の改行までを書き込む
図3のスタックは次のように切り替えられる。スレッド開始時、アプリケーションプログラム1はスレッド個別スタック7を使用して動作し図中の星印のサブルーチン呼出しの直前で共有スタックを割り当て、スタックポインタを割り当てた共有スタックに切り替える。また、該サブルーチンから呼出し元ルーチンに戻ってきた直後に共有スタック8から個別スタック7へスタックポインタを切り替え、該共有スタック8を解放する。
ここで、共有スタック8の割り当て、解放及びスタックポインタの切り替えはアプリケーションプログラム1がスタック管理部3からルーチンを呼出すことにより行われる。
スレッド切り替えポイント(図3の星印)はつぎのように決められる。アプリケーションプログラム1は外部イベント待ち、即ちストリーム受信待ち (図3のEventWait 38)に至る可能性のある処理経路上(図中の実線の矢印)ではスレッド個別スタック7を利用し、それ以外の処理経路上(図中の破線の矢印)では共有スタック8を使用する。
ストリームの受信はいつ発生するのか分からないため、 イベントが発生するまで長時間待たされる可能性がある。 そのため、実行中の全てのスレッドがストリーム受信待ち状態 (EventWait 38)に入る可能性がある。このため、スレッドの先頭(ThreadMain
30)から外部イベント待ち(EventWait 38)までのスタックの状態は全てのスレッドについて保存する必要がある。これが、スレッド個別スタック7を使用する理由である。
一方、パターン検索器23による検索結果通知やストリームバッファ22による読出し完了通知などの内部イベントは、処理要求を発行してから比較的短い時間内に必ず発生することが保証されているため、
これらのイベント待ち状態に同時に入るスレッド数は限られている。 このため、スレッド個別スタック7を使用する必要はなく領域の容量に余裕のある共有スタック8を使用する
イベント待ち以外でスレッド切り替えは行われないためいずれのイベント待ち状態にも到達しない処理経路上では領域の容量に余裕のある共有スタック8を使用する。
図4はスタックの切り換えを伴わない通常のサブルーチン呼出し時のスタックの変化の状態を示す。これは、図3で星印の付いていないサブルーチン呼出しに該当する。但し、スタックの使用方法は使用するCPU、OS、コンパイラなどに依存する。本実施例はその一例を示す。BP(ベースポインタ)とSP(スタックポインタ)は、それぞれCPUが持つレジスタであり、スタック領域内のアドレスを保持する。BPは現在実行中のルーチンにおけるスタックフレームの底部を指し、相対参照を行う際のベースレジスタとして使用される。SPは現在のスタックポインタであり、スタックへのプッシュ/ポップ操作が行われると参照/更新される。
各ルーチン内で使用する内部変数はスタックの中に確保されている。
(A1)はサブルーチンを呼び出す前の呼出し元ルーチンにおけるスタックの状態を示している。
(A2)はサブルーチンを呼び出す直前のスタックが引数を準備する状態を示す。即ち、サブルーチンを呼出す前、呼び出し元ルーチンは該サブルーチンに渡す引数をスタックにプッシュする。
(A3)は前記サブルーチンを呼び出した直後のスタックの状態を示す。
前記サブルーチンを呼出した瞬間、呼出し元ルーチンにおけるプログラムの次の命令のアドレス(図中の戻りInstruction address Pointer)がスタックにプッシュされる。
(A4)は呼出された前記サブルーチンにおいてスタックが初期化された後の状態を示す。各サブルーチンは呼出された直後、現在のベースポインタ(BP)の値をスタックにプッシュし、そのときのスタックポインタの値をBPに代入し、スタック内に内部変数に必要な領域を確保しその分だけスタックポインタの値を進める。
1つのサブルーチンの実行が終了し呼出し元に戻る過程は(A5)、(A6)、(A7)の順にスタックの状態が変化する。
図5と図6はスタック切り換えを伴うサブルーチン呼出しにおけるスタックの状態の変化を示す。これは図3で星印の付いているサブルーチン呼出しに該当する。サブルーチンを呼出す前のスタックの状態は図4の(A1)と同じである。
呼出し元ルーチンでは、サブルーチンを呼出す前にスタック管理部3のルーチンを用いて、共有スタック8の割り当てと個別スタック7から共有スタック8への切り換えを行なう。(B1)はこのときの状態を示す。具体的には、スタック管理部3が先ず現在のスタックポインタ(SP)が保持しているスタックのアドレスをスレッド管理情報6の変数OSPに保存する。次に、未使用の共有スタック8を実行中のスレッドに割り当て、SPにその共有スタック8の底部アドレスをロードする。このときSPは共有スタックを指しているため、これ以降の処理はスタック切り換えを伴わないサブルーチン呼出しの場合と同一である。
(B2)はサブルーチンを呼び出す直前の個別スタック7と共有スタック8の状態を示している。
サブルーチンを呼出す前、呼び出し元ルーチンはサブルーチンに渡す引数を共有スタック8にプッシュする。
(B3)はサブルーチンを呼び出した直後の個別スタック7と共有スタック8の状態を示している。
サブルーチンを呼出した瞬間、呼出し元ルーチンにおけるプログラムの 次の命令のアドレス(図中の戻りIP)が、共有スタックにプッシュされる。
(B4)は呼出されたサブルーチンにおいて共有スタック8を初期化した後の
個別スタック7と共有スタック8の状態を示す。各ルーチンは呼出された直後、現在のBPの値をスタックにプッシュし、 そのときのSPの値をBPに代入し、共有スタック8内に内部変数に必要な領域を確保しその分だけSPを進める。
サブルーチンの実行が終了し呼出し元に戻る過程で個別スタックと共有スタックの状態は (B5)、(B6)、(B7)の順に変化する。
最後に、スタック管理部3のルーチンを用いて、共有スタック8から個別スタック7への復旧と共有スタック8の解放を行う。個別スタック7への復旧はスレッド管理情報6の変数OSPに保存された個別スタック7のアドレスをSPにロードすることで行われる。
図7は図3のプログラムをマルチスレッドで実行しているときのある瞬間における各スレッドにおけるスタックの状態を示している。図の上段は共有スタック8、下段はスレッド個別スタック7を示している。各スタックの図にそのスタックを使用しているルーチン名と括弧内にそのルーチンが消費しているスタックのバイト数を示す。
スレッド#1はThreadMain 30、HeaderProc 31、LogProc 35の各ルーチンを経由してLogWrite 44を現在実行中である。最初はスレッド個別スタック7を使用し、LogProc
35を呼び出す時点で共有スタック8を使用する。
スレッド#2はThreadMain 30、HeaderProc 31、BodyLenGet 36、PattSearch 39の各ルーチ ンを経由し、現在EventWait 41で内部イベント待ち状態にある。最初は個別スタック7を使用しBodyLenGet 36を呼び出す時点で共有スタック8を使用する。
スレッド#3はThreadMain 30、HeaderProc 31、EoHdrCheck 34、PattSearch 39の各ルーチ ンを経由し、現在EventWait 41で内部イベント待ち状態にある。最初は個別スタック7を使用しEoHdrCheckを呼び出す時点で共有スタック8を使用する。
スレッド#4はThreadMain 30、BodyProc 32、StrmRecvWait 33の各ルーチンを経由し、現在EventWait 38で外部イベント待ち状態にあり、個別スタック7を使用している。
スレッド#5はThreadMain 30、HeaderProc 31、StrmRecvWait 33の各ルーチンを経由し
現在EventWait 38で外部イベント待ち状態にあり、個別スタック7を使用している。
なお、ここに示したスレッド以外にもスレッドが存在するかも知れないが、 現在実行中のスレッドはスレッド1のみであり、他のスレッドは内部イベント 待ちまたは外部イベント待ちの状態である。
図3と図7を用いて、本発明の方式を用いることでタック領域に必要なメモリ量を削減できることを説明する。
最初に、通常の方式に従いスレッド個別スタック7のみを使用する場合を考える。図3のプログラムにおいてスタック領域を最も大量に使用する処理経路 はThreadMain
30、HeaderProc 31、LogProc 35、StrmBuffRead 42を経由してEventWait 41に至る場合であり、272バイトが消費される。即ち、1つのスレッドに対して個別スタック7のために272バイト以上のメモリ領域を確保するため、同時スレッド数をNとすると、272×Nバイト以上のメモリが必要となる。
次に、図3において個別スタック7と共有スタック8を使用する場合を考える。
スレッド固有スタック7の領域を最も大量に使用する処理経路は、Thread Main 30、HeaderProc 31、StrmRecvWait 33を経由しEventWait 38に至る場合とThreadMain 30、BodyProc 32、StrmRecvWait 33を経由しEventWait 38に至る場合であり、160バイトが使用される。また、共有スタック8の領域を最も大量に使用する処理経路はLogProc 35、StrmBuffRead 42を経由してEventWait 41に至る場合であり、192バイトが使用される。同時スレッド数をN、共有スタックの数をMとすると、160×N+192×Mバイト以上のメモリが必要になる。
上記従来例(特許文献1)との比較から、本発明のスレッド数Nが共有スタック数(M)の1.8倍以上であれば従来例よりメモリ消費量を少なくすることができる。
本発明のアプリケーション実行環境の基本構成図 本発明のハードウェア構成と入力データ形式を示す図 本発明のマルチスレッドアプリケーションプログラムの構成図 スタックの切り換えを伴わないサブルーチン呼出しのスタックの変化を示す図 スタックの切り換えを伴うサブルーチン呼出しのスタックの変化の一部を示す図 スタックの切り換えを伴うサブルーチン呼出しのスタックの変化のその他の部を示す図 図3のマルチスレッドプログラムを実行中の各スレッドのスタックの状態を示す図
符号の説明
1 アプリケーションプログラム
2 スレッド管理部
3 スタック管理部
4 メインメモリ
5 CPU
6 スレッド管理情報
7 スレッド個別スタック
8 共有スタック
10 外部イベント
11 内部イベント
21 ストリーム受信部
22 ストリームバッファ
23 パターン検索器
24 ログストレージ

Claims (4)

  1. 複数のスレッドに対し1対1の関係で複数のスレッド個別スタックを割り当て、
    前記個別スタックの数より少なくかつ各のメモリサイズが各スレッド個別スタックのメモリサイズよりも大きい複数の共有スタックを設け、外部イベント待ちに至る可能性のあるスレッドでは前記スレッド個別スタックを使用し、それ以外のスレッドでは前記共有スタックを使用することにより前記複数の共有スタックを前記スレッド間で共有することを特徴とするマルチスレッドプログラム処理方法。
  2. 複数のスレッド全てに対して1対1の関係で割り当てられる複数のスレッド個別スタックと、
    前記個別スタックの数より少なくかつ各のメモリサイズが各スレッド個別スタックのメモリサイズよりも大きい複数の共有スタックと、
    外部イベント待ちに至る可能性のあるスレッドでは前記スレッド個別スタックを使用し、それ以外のスレッドでは前記共有スタックを使用することにより前記複数の共有スタックを前記スレッド間で共有する処理手段と具備することを特徴とするマルチスレッドプログラム処理装置。
  3. 請求項2または3において、前記処理手段は
    スレッド管理部と、
    スタック管理部と、
    マルチスレッド型アプリケーションプログラムと、
    該プログラムを実行するCPUとからなり、
    前記アプリケーションプログラムは前記スレッド管理部が提供するルーチンを用いてスレッドの生成と切り換えを行い現在実行中のスレッドがイベント待ち状態に入り、外部イベント源または内部イベント源から通知されるイベントに基いてスレッドを切り換え、前記スタック管理部が提供するルーチンを用いて前記スレッド個別スタックと前記共有スタックの間の切り換えを行うことを特徴とするマルチスレッドプログラム処理装置。
  4. 請求項3において、前記処理手段は
    ストリーム受信器と、
    ストリームバッファと、
    パターン検索器とを有し、
    該ストリーム受信器は外部ネットワークから入力されるトラフィックからストリームを抽出しストリームバッファに保存し、前記CPUから特定ストリームに対する受信要求を受けると未通知の受信済みデータが存在するか否かを調べ、存在する場合は前記外部イベントとして前記CPUに通知し、未通知の受信済みデータが存在しない場合は次のデータを受信したとき前記外部イベントとしてCPUに通知し、
    前記ストリームバッファは前記ストリーム受信器が抽出したストリームを 保存し、特定ストリームのデータ読み出し範囲と転送先のメモリ領域を指定する読み出し要求を前記CPUから受けると該指定された範囲のデータを該転送先に転送し、前記内部イベントとして前記CPUに通知し、
    前記パターン検索器は前記CPUから検索要求を受けると該検索要求が指定するストリーム、データ範囲、文字列パターンを検索キーとして前記ストリームバッファを検索し、
    指定された文字列パターンが指定されたストリームの指定された範囲のデータ中に含まれている場合はその文字列パターンのバイト位置を検索結果通知として前記CPUに通知することを特徴とするマルチスレッドプログラム処理装置。
JP2006286497A 2006-10-20 2006-10-20 マルチスレッドプログラム処理方法及び装置 Withdrawn JP2008102847A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006286497A JP2008102847A (ja) 2006-10-20 2006-10-20 マルチスレッドプログラム処理方法及び装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006286497A JP2008102847A (ja) 2006-10-20 2006-10-20 マルチスレッドプログラム処理方法及び装置

Publications (1)

Publication Number Publication Date
JP2008102847A true JP2008102847A (ja) 2008-05-01

Family

ID=39437113

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006286497A Withdrawn JP2008102847A (ja) 2006-10-20 2006-10-20 マルチスレッドプログラム処理方法及び装置

Country Status (1)

Country Link
JP (1) JP2008102847A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8392932B2 (en) 2008-06-25 2013-03-05 Panasonic Corporation Information processing device for causing a processor to context switch between threads including storing contexts based on next thread start position
JP2014182799A (ja) * 2013-03-15 2014-09-29 Intel Corp システムコールのためのロバスト且つ高性能な命令
JP2014191468A (ja) * 2013-03-26 2014-10-06 Hitachi Ltd プロセスの待ち行列を共有する複数のプロセッサを有する計算機、及び、プロセスディスパッチ処理方法
US9448844B2 (en) 2009-11-13 2016-09-20 Samsung Electronics Co., Ltd. Computing system and method controlling memory of computing system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8392932B2 (en) 2008-06-25 2013-03-05 Panasonic Corporation Information processing device for causing a processor to context switch between threads including storing contexts based on next thread start position
US9448844B2 (en) 2009-11-13 2016-09-20 Samsung Electronics Co., Ltd. Computing system and method controlling memory of computing system
JP2014182799A (ja) * 2013-03-15 2014-09-29 Intel Corp システムコールのためのロバスト且つ高性能な命令
JP2014191468A (ja) * 2013-03-26 2014-10-06 Hitachi Ltd プロセスの待ち行列を共有する複数のプロセッサを有する計算機、及び、プロセスディスパッチ処理方法

Similar Documents

Publication Publication Date Title
US10698690B2 (en) Synchronisation of execution threads on a multi-threaded processor
JP5789072B2 (ja) マルチコアアーキテクチャにおけるリソース管理
US7493436B2 (en) Interrupt handling using simultaneous multi-threading
US7904704B2 (en) Instruction dispatching method and apparatus
US8533716B2 (en) Resource management in a multicore architecture
EP2423808B1 (en) Arithmetic device
US7941643B2 (en) Multi-thread processor with multiple program counters
US20100082848A1 (en) Increasing available fifo space to prevent messaging queue deadlocks in a dma environment
JP2007079789A (ja) 計算機システム及びイベント処理方法
JP2008527558A (ja) タスクスケジューリングのデータ処理システム及び方法
JP2007317171A (ja) マルチスレッド計算機システム、マルチスレッド実行制御方法
US8631086B2 (en) Preventing messaging queue deadlocks in a DMA environment
WO2009074946A1 (en) Data processing system and method of interrupt handling
JP2008102847A (ja) マルチスレッドプログラム処理方法及び装置
JP2008522277A (ja) 優先度の付けられたタスク間の効率的な切り換え
JP2005050208A (ja) マルチタスクシステムにおけるメモリ管理方式およびタスク制御装置
US9841994B2 (en) Implementation of multi-tasking on a digital signal processor with a hardware stack
US7711925B2 (en) Information-processing device with transaction processor for executing subset of instruction set where if transaction processor cannot efficiently execute the instruction it is sent to general-purpose processor via interrupt
AU714853B2 (en) Job scheduling for instruction processor
Dolan et al. Effectively tackling the awkward squad
JP5859472B2 (ja) プロセスの待ち行列を共有する複数のプロセッサを有する計算機、及び、プロセスディスパッチ処理方法
US7320044B1 (en) System, method, and computer program product for interrupt scheduling in processing communication
JP2013134670A (ja) 情報処理装置及び情報処理方法
Hori et al. SCore
Ostheimer Parallel Functional Computation on STAR: DUST—

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Effective date: 20090804

Free format text: JAPANESE INTERMEDIATE CODE: A7421

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090915

A761 Written withdrawal of application

Effective date: 20100419

Free format text: JAPANESE INTERMEDIATE CODE: A761