JPH1063568A

JPH1063568A - マルチスレッド環境におけるメモリの割り当て方法及びシステム

Info

Publication number: JPH1063568A
Application number: JP9168426A
Authority: JP
Inventors: Gregory Nakhimovsky; グレゴリー・ナヒモフスキー
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-06-28
Filing date: 1997-06-25
Publication date: 1998-03-06
Also published as: EP0817044A3; DE69715532T2; EP0817044A2; DE69715532D1; EP0817044B1; US6058460A

Abstract

(57)【要約】【課題】システム・メモリ内の多数のメモリ・プール
の１つと対応付けられた、プロセス内で並列に走るスレ
ッドに、マルチスレッド（並列）コンピュータ環境にお
いてメモリを割り当てる方法を提供する。【解決手段】この方法は、システム・メモリにおいて
メモリ・プールを確立するステップと、各スレッドを前
記メモリ・プールの１つにマップするステップと、各ス
レッドについて、対応するメモリ・プールからユーザ・
メモリ・ブロックを動的に割り当てるステップとを含
む。また、前記方法は、既存のあらゆるメモリ管理mall
ocパッケージをも、マルチスレッド・バージョンに変換
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、メモリの割り当て
に関し、更に特定すれば、マルチスレッド（並列）環境
におけるメモリの割り当てに関するものである。

【０００２】

【従来の技術】コンピュータ・プログラムに対してメモ
リを割り当てる際、殆どの古い言語（例えば、FORTRA
N、COBOL）では、プログラムをコンパイルする前に、ア
レイやデータ項目のサイズを宣言しなければならない。
更に、アレイやデータ項目のサイズは、プログラムを変
更し再コンパイルするのでなければ、超過することはで
きなかった。しかしながら、今日、ＣやＣ＋＋を含む最
近のプログラミング言語の殆どでは、ユーザは、実行時
にシステム・メモリからメモリのブロックを要求した
り、プログラムがかかるブロックをもはや必要としない
場合は、メモリ・ブロックをシステム・メモリに開放す
ることが可能となっている。例えば、これら最近の言語
では、データ要素は、次のデータ要素に対するポインタ
を含むフィールドを備えたデータ構造を有する場合が多
い。実行時に、リンク・リストまたはアレイ構造として
多数のデータ要素を割り当てることも可能である。

【０００３】Ｃプログラミング言語は、「メモリ割り当
て」ルーチンとして知られている、１組のライブラリ関
数を、メモリ管理機能に与えている。最も基本的なメモ
リ割り当て関数は、mallocと呼ばれ、要求されたバイト
数を割り当て、割り当てられたメモリの先頭アドレスで
あるポインタを戻す。freeとして知られている別の関数
は、mallocによって既に割り当てられているメモリを返
し、そのメモリが他のルーチンによって再び使用できる
ようにする。

【０００４】

【発明が解決しようとする課題】メモリ割り当てが並列
に発生する、例えば、マルチスレッド・プロセス(multi
thraded process)のようなアプリケーションでは、mall
ocおよびfree関数は、「コード・ロック」させなければ
ならない。コード・ロッキングとは、スレッドを含むプ
ロセスのライブラリ・コードを、グローバル・ロックに
よって保護することを意味する。これによって、１つの
スレッドが全体的な構造(global structure)を修正し、
他のスレッドがそれを読もうとしているという場合に、
データの劣化(corruption)を防止する。コード・ロッキ
ングは、いずれの所与の時刻においても、１つのスレッ
ドのみにmalloc関数のいずれか（例えば、malloc、fre
e、realloc)をコールさせるものであり、他のスレッド
は、当該スレッドがそのメモリ割り当てを終了するま
で、待つことになる。したがって、メモリ割り当て関数
が広く使用されるマルチスレッド・プロセスにおいて
は、システム速度が著しく低下する。

【０００５】

【課題を解決するための手段】概して言えば、一態様に
おいて、本発明は、各々がシステム・メモリ内に対応す
るメモリ・プールを有する複数のスレッドがプロセス内
において並列に走る、マルチスレッド計算機環境におけ
るメモリ割り当て方法を提供する。この方法は、システ
ム・メモリ内にメモリ・プールを確立するステップと、
各スレッドを前記メモリ・プールの１つにマップするス
テップと、各スレッドについて、対応するメモリ・プー
ルからユーザ・メモリ・ブロックを動的に割り当てるス
テップとを含む。各スレッドは、メモリ割り当てルーチ
ン（例えば、malloc)を用いて、それ自体のメモリ・プ
ールを操作することにより、メモリ管理の効率向上を図
る。

【０００６】また、本発明は、既存のメモリ管理malloc
パッケージを、マルチスレッド・バージョンに変換し、
効率を高めてマルチスレッド・プロセスを走らせるよう
にする。その上、本発明は、並列なメモリ管理を必要と
するあらゆるアプリケーションに適用可能であり、特
に、重大な並列メモリ管理を必要とするアプリケーショ
ンにも適用可能である。更に、本発明の使用は、アプリ
ケーション・プログラマの観点からは透明である。何故
なら、ユーザ・インターフェースが標準的なＣライブラ
リ・メモリ管理関数（即ち、malloc、free、realloc）
と同一であるからである。

【０００７】好適実施例では、前記方法は、更に、異な
るスレッドが１つのメモリ・プールに同時にアクセスす
るのを防止するステップを含む。別個のメモリ・プール
を有することにより、異なるスレッドがメモリ・プール
に同時にアクセスするのを、別個のコード・ロッキング
（例えば、mutex locking) によって防止することがで
き、これによって、データの劣化を排除する。並列実行
に適した既存の標準的なメモリ割り当てルーチンでは、
単一のコード・ロックがあるに過ぎない。したがって、
ある所与の時点においてメモリ割り当てルーチンをコー
ルできるのは、単一のスレッドだけである。当該プロセ
スにおいて実行中の他のスレッドは全て、前記スレッド
がそのメモリ割り当て処理を終了するまで、待っていな
ければならない。一方、本発明では、各スレッドがそれ
自体のメモリを操作している限りは、メモリ割り当て処
理は、全く遅延がなく、並列に実行することができる。
別個のコード・ロッキング構造は、スレッドが他のスレ
ッドのメモリ・プールにアクセスしようとした時にのみ
重要となる。当該スレッドには対応付けられていない、
かかるメモリ・プールのメモリ割り当ては、殆ど発生す
ることはない。このように、本発明は、メモリ割り当て
ルーチンのコールに伴う時間遅延を大幅に減少させるこ
とによって、マルチスレッド・プロセスの処理性能の改
善を図るものである。

【０００８】好適実施例では、１つ以上の以下の特徴を
含むことができる。動的にメモリ・ブロックを割り当て
るステップは、割り当てを望むブロック内のバイト数を
指定することを含む。例えば、malloc関数をコールする
ことによって、メモリ・プールの最大サイズまでの必要
なあらゆるバイト数を割り当てる。各スレッドにメモリ
・プールを確立するステップは、予め選択されているサ
イズ（例えば、６４ｋバイト）のメモリ・バッファを割
り当てることを含む。メモリ・プールのサイズを使い果
たした場合、このメモリ・プールのサイズは、バッファ
・メモリの予め選択されているサイズに等しい増加量だ
け、システム・メモリから追加メモリを割り当てること
によって、動的に増加させることができる。更に、前記
方法は、スレッドの１つに、他のスレッドのメモリ・プ
ールから、それ自体のメモリ・プールにメモリを転送さ
せることも含む。

【０００９】各メモリ・プールは、例えば、メモリ・プ
ールの１つに対応付けられたスレッド・インデックスに
よって識別されるスタティック変数のアレイのような、
メモリ・ブロックのデータ構造として維持することがで
きる。このデータ構造は、メモリ・ブロックのサイズ
と、それが対応付けられているメモリ・プール・インデ
ックスとから成るヘッダを含む。ブロック・サイズおよ
びメモリ・プール・インデックスは、双方とも、例えば
４バイトとすることができる。

【００１０】前記方法は、更に、各スレッドに、メモリ
・ブロックの割り当てを解除する、即ち、開放してをメ
モリ・プールに戻させるステップも含むことができる。
アプリケーションには、メモリ・ブロックの開放は、元
々そのメモリ・ブロックを割り当てたスレッドから行わ
なければならないものもある。また、他のアプリケーシ
ョンには、メモリ・ブロックを開放を、元々そのメモリ
・ブロックを割り当てたのではないスレッドから行うこ
とを許すものもある。

【００１１】割り当て解除（解放）したメモリ・ブロッ
クの合体即ち併合を実行し、小さな断片状のブロックを
結合することも可能である。しかしながら、本方法は、
異なるプールからのメモリ・ブロックの合体は防止す
る。

【００１２】メモリ・ブロックのサイズを拡大し、より
多くのデータ要素を格納する必要がある場合、メモリ・
プールによって割り当てられるメモリの割り当て済みブ
ロックのサイズは、reallocルーチンを用いて変更する
ことができる。本方法は、reallocが元のメモリ・プー
ルを保存することを必要とする。

【００１３】概して言えば、別の態様において、本発明
は、プロセス内で、各々システム・メモリへのアクセス
を有する、複数のスレッドが並列に走るマルチスレッド
・コンピュータ環境において、メモリを割り当てるため
のコンピュータ・プログラムを記憶した、コンピュータ
読み取り可能媒体を提供する。記憶されているプログラ
ムは、（１）前記システム・メモリ内に複数のメモリ・
プールを確立するコンピュータ読み取り可能命令と、
（２）各スレッドを前記複数のメモリ・プールの１つに
マップするコンピュータ読み取り可能命令と、（３）各
スレッドについて、対応するメモリ・プールからユーザ
・メモリ・ブロックを動的に割り当てるコンピュータ読
み取り可能命令とを含む。コンピュータ読み取り可能媒
体は、ＲＡＭまたはＲＯＭメモリのような多種多様なメ
モリ媒体、ならびにコンピュータ・ディスクまたはＣＤ
ＲＯＭのような外部のコンピュータ読み取り可能媒体
のいずれかを含む。また、コンピュータ・プログラム
は、ネットワークを通じて、コンピュータの一時的にア
クティブな記憶装置（例えば、ＲＡＭ、出力バッファ）
にダウンロードすることも可能である。例えば、上述の
コンピュータ・プログラムは、インターネットを通じ
て、ウエブ・サイトからコンピュータのメモリにダウン
ロードすることができる。したがって、本発明のコンピ
ュータ読み取り可能媒体は、ネットワークからダウンロ
ードされる上述のコンピュータ・プログラムを格納する
コンピュータのメモリを含むことを意図するものであ
る。

【００１４】本発明の別の態様において、システムは、
一部分が上述のコンピュータ・プログラムを格納するメ
モリと、格納されたコンピュータ・プログラムのコンピ
ュータ読み取り可能命令を実行するプロセッサと、メモ
リおよびプロセッサを接続するバスとを含む。

【００１５】その他の利点および特徴は、以下の好適実
施例の記載および特許請求の範囲から明白となろう。

【００１６】

【発明の実施の形態】図１を参照すると、マルチ処理ネ
ットワーク１０を簡略に表現した図は、システム・バス
１６を通じてシステム・メモリ１４に相互接続されてい
る、同等の能力の個々のプロセッサ１２ａ〜１２ｎを含
む。プロセッサは全て、システム・メモリ、ならびにそ
の他のＩ／Ｏチャネルおよび周辺装置（図示せず）への
アクセスを共有する。各プロセッサは、例えば、アプリ
ケーションのような１つ以上のプロセスを実行するため
に用いられる。

【００１７】図２を参照すると、プロセッサ１２ａ〜１
２ｎ（図１）の１つ以上において走るアプリケーション
２０が示されている。アプリケーション２０は、ここで
は、単一のスレッド２２を含み、このスレッドは、シス
テム・メモリ１４内において割り当てられたメモリの一
部分２４に対するアクセスを有する。このメモリ部分の
ことを、メモリ・プールと呼ぶ。また、アプリケーショ
ン２０は、マルチスレッド部分も含む。マルチスレッド
部分は、ここでは、４つのスレッド３０〜３３を有する
ものとして示されている。４つのスレッドを示すが、ア
プリケーションの実行中には、新たなスレッドが繰り返
し作成され、古いスレッドが消滅していくので、個々の
時点で実行中のスレッドの数は変化し得る。スレッド３
０〜３３の各々は、例えば、プロセッサ１２ａ〜１２ｎ
の内対応する１つにおいて走るようにしてもよい。他の
アプリケーションでは、全てのスレッドまたは多数のス
レッドが単一のプロセッサ上で走ることもあり得る。ス
レッド３０は、単一のスレッドとしてのアプリケーショ
ンによって割り当てられたメモリ部分２４を使用し続け
る、主スレッドであると見なされる。しかしながら、追
加のスレッド３１〜３３は、システム・メモリ１４か
ら、それら自体のメモリ・プール３８〜４０を割り当て
る。したがって、各スレッドは、その処理実行に使用す
るために、１つのメモリ・プールと対応付けられる。こ
れらのスレッド上で走るアプリケーションの実行の間、
各スレッドは、メモリ割り当て関数（即ち、malloc、fr
ee、realloc）を用いて、それに対応するメモリ・プー
ルからのメモリ・ブロックの割り当て、解放、および再
割り当てを繰り返し行う。これについては、以下で詳細
に説明する。更に、通常１つのスレッドを主スレッドと
して指名するが、残りのスレッドのいくつかを、特定の
目的のために指名することも可能である。

【００１８】メモリ・プールの確立メモリ・プールの数(NUM_POOLS)は固定されている。mal
locパッケージ・プログラマはプール数の変更が可能で
あるが、それを行った後、パッケージを再構築しなけれ
ばならない。

【００１９】各スレッドのためのメモリ・プールの確立
は、予め選択されているサイズ（例えば、６４Ｋバイ
ト）のメモリ・バッファを割り当てることを含む。メモ
リ・プールのサイズ使い果たした場合、システムメモリ
から追加のメモリを割り当てることによって、メモリ・
プールのサイズを動的に増加することができる。追加の
メモリを割り当てるには、例えば、Unixシステムのsbrk
()と呼ばれるルーチンを用いればよい。この実施態様で
は、sbrk()をmallocの中から内部的にコールし、バッフ
ァ・メモリの予め選択されているサイズに等しい増加分
だけ、追加メモリを割り当てる。追加のメモリを割り当
てるには、プールをロックし、他のメモリ関数が同時に
実行されるのを防止する必要がある。したがって、メモ
リ・バッファのサイズは、malloc()によって要求される
メモリの平均量に比較して大きく選択することにより、
プール・サイズの増加要求が頻繁には起こらないように
する。

【００２０】各メモリ・プールは、個々のメモリ・ブロ
ックがプールから成る、バイナリ・ツリー・データ構造
として設定することもできる。バイナリ・ツリーは、サ
イズによって順序付けられるが、アドレスによる順序付
けも可能である。あるいは、他のデータ構造（例えば、
リンク・リスト）を用いてもよいが、バイナリ・ツリー
構造は、検索時に高速処理が可能なので好ましい。更
に、バランス・アルゴリズムまたは自己調節アルゴリズ
ムを用いて、検索の効率を高めることも可能である。

【００２１】図３を参照すると、メモリ４０の各ブロッ
クは、データ・オブジェクト４０によって識別される。
データ・オブジェクト４０は、使用される特定のハード
ウエア・アーキテクチャの整合要件に合わせた長さのヘ
ッダ４２を有する。例えば、カリフォルニア州、マウン
テン・ビューのSun Microsystems社が使用するある種の
ハードウエア構成では、SPARCアーキテクチャに合わせ
た整合境界(alignmentboundary)を得るために、ヘッダ
の長さが８バイトでなければならない。ヘッダの最初の
４バイトは、ブロックのサイズを示し、残りの４バイト
はプール番号を示す。

【００２２】メモリ管理関数各スレッド２０〜２３は、標準的なＣライブラリからの
ルーチンと同様の１組のメモリ割り当てルーチンを用い
て、そのメモリ・プールにメモリを割り当てる。メモリ
を割り当てる基本関数はmalloと呼ばれ、以下の構文を
有する。

【００２３】void * malloc (size) sizeは要求されたバイト数を示す。

【００２４】他のメモリ割り当てルーチンにfreeがあ
る。これは、割り当てられた記憶ブロックを、空きメモ
リのプールに解放するもので、以下の構文を有する。

【００２５】void * free (old) oldは解放するメモリのブロックへのポインタである。

【００２６】更に他のメモリ割り当てルーチンにreallo
cがある。これは、mallocによって割り当てられたメモ
リのブロック・サイズを調節するものである。realloc
は以下の構文を有する。

【００２７】void * realloc (old, size) oldは、サイズを変更するメモリのブロックへのポイン
タであり、sizeは、当該ブロックの新たなサイズであ
る。

【００２８】既存のmallocパッケージのマルチスレッド
mallocパッケージへの変換単一のロックを用いる既存のメモリ管理パッケージを、
並列メモリ管理パッケージに変換するためには、上述の
メモリ管理関数において用いられている全てのスタティ
ック変数をスタティック・アレイに変換する。例えば、
メモリ・プールに対応付けられたバイナリ・ツリー構造
は、スタティック・アレイとして格納される。スタティ
ック・アレイの各要素は、そのスレッド・インデックス
によって識別され、所与のメモリ・プールと対応付けら
れる。各アレイには、各プールに対して別個のスタティ
ック・アレイ要素がある。したがって、各スレッドを求
めるための特定のデータ構造（例えば、バイナリ・ツリ
ー）全体の検索は、並列的に実行することができる。

【００２９】したがって、各スレッドは、上述のルーチ
ンのいずれでも繰り返し実行し、それらに対応するメモ
リ・プールのメモリ割り当てを管理することができる。
例えば、再び図２を参照すると、主スレッド３０は、メ
モリ・プール２４内のメモリ・ブロックの割り当て、解
放、および再割り当てを多数回行うプロシージャを実行
することができる。同時に、スレッド３１〜３３は、メ
モリをそれらの各メモリ・プール３８〜４０に割り当て
たりおよび解放するプロシージャを実行することができ
る。

【００３０】スレッドのメモリ・プールへのマッピングメモリ割り当て関数をコールしたときはいつでも、これ
ら関数の各１つの中にあるスレッド識別ルーチンを用い
て、メモリ割り当て要求を行ったスレッドを識別する。
スレッド識別関数は、要求を行ったスレッドのスレッド
・インデックスを返す。例えば、Sun Microsystems社の
製品である、Solarisオペレーティング・システム(Ｏ
Ｓ)は、一実施態様において、thr_self()と呼ばれる関
数を用いる。

【００３１】次に、他のアルゴリズムを用いて、各スレ
ッド・インデックスをメモリ・プール番号にマップす
る。例えば、記載中の実施例は、スレッド・インデック
スを受け取り対応するプール番号を返す、GET_THREAD_I
NDEXとして知られている以下のマクロを用いる。

【００３２】 # define GET_THRED_INDEX (self) ＼ ((self) == 1 ? 0 : 1 + ((self) - 4 % (NUM_POOLS-1) ここで、selfはスレッド・インデックス、およびNUM_PO
OLSはメモリ・プール数である。

【００３３】上述のように、通常１つのスレッドを主ス
レッドとして指定し、残りのスレッドを他の目的のため
に指定する。例えば、SOLARIS OSが用いるスレッド付
番システムは、最初のスレッドを主スレッドとして保存
し、２番目および３番目のスレッドをシステム・スレッ
ドとし、残りのスレッドをユーザ・スレッドとしてい
る。上述のマクロを用いて、メモリ・プールに０からNU
M_POOLS-1まで付番する。上述のマクロの最初の部分（s
elf == 1 ? 0)は、主スレッドが常に最初のプール番号
に対応することを保証する。したがって、selfが１に等
しい（即ち、それが主スレッドである）場合、プール番
号は０となる。その他の場合、マクロの":"の後ろの残
り部分に示すように、スレッド・インデックスから定数
の４を引いたものとNUM_POOLS-1との剰余を番号１に加
算して、プール番号にする。例えば、メモリ・プールが
４つのみであり（即ち、NUM_POOLS=4）、スレッド・イ
ンデックスが４である場合、前記マクロによって返され
る対応するプール番号は１となる。５および６のスレッ
ド・インデックスは、それぞれ、２および３と付番され
た対応するメモリ・プールを有することになる。

【００３４】いずれかの所与の時刻に存在するスレッド
数が、確立したプール数を超過するアプリケーションで
は、追加のスレッドが、あるメモリ・プールに対応付け
られている他のスレッドと、そのプールを共有する。例
えば、図４を参照すると、新たな５番目のスレッド３４
が作成されたアプリケーションを示す。４つのメモリ・
プールしか確立しておかなかったので、上述のマクロを
用いて、元々スレッド３０のみに対応付けられていた第
１メモリ・プール２４に、スレッド３４をマップする。
この状況では、主プール２４に対応するミューテックス
・ロック(mutexlock)が、スレッド２４または３４の一
方がプールを使用している場合に、スレッド２４または
３４の他方によるアクセスを防止する。前章の例では、
マクロGET_THREAD_INDEXは、メモリ・プール＃１に対し
て、４および７のスレッド・インデックスを有するスレ
ッドをマップする。

【００３５】コード・ロッキング・メモリ・プール各メモリ・プール２４および３８〜４０は、それ自体の
相互除外(mutex)ロックによって保護されている。各メ
モリ・プールに対応するデータ構造と同様に、ミューテ
ックス・ロックは、スタティック・アレイに格納され
る。各ミューテックス・ロックは、それ自体のメモリ・
プールから１つ以上のメモリ・ブロックの割り当て、割
り当て解除または再割り当てを行っているスレッドにお
いては、遅延を発生させない。しかしながら、特定のメ
モリ・プールに対応付けられていないスレッドが、当該
プールに対応付けられているスレッドによって既に割り
当てられているメモリ・ブロックにアクセスしようとす
ると、ミューテックス・ロックは、対応付けられていな
いスレッドが、当該プールからメモリ・ブロックの割り
当て解除や再割り当てを行うのを防止する。したがっ
て、ロックは、一度に２つ以上のスレッドによる更新ま
たは使用からメモリを保護することによって、メモリ・
ブロックにおけるデータの劣化を防止する。このような
スレッドに対応付けられていないメモリ・プールからの
メモリ・ブロックに対する割り当て、割り当て解除また
は再割り当ての試みは、比較的頻度が少ない。この特徴
は、単一のミューテックス・ロックを全てのメモリ管理
ルーチンに用いる従来の方式に対して、システムの速度
性能において大幅な改善をもたらすものである。単一の
ミューテックス・ロックの使用では、マルチスレッド型
アプリケーションの性能を大幅に低下させる可能性があ
る。この手法では、一旦スレッドがメモリ管理関数（即
ち、malloc、free、またはrealloc）をコールしたな
ら、他のスレッドは全て、当該スレッドがそのメモリ管
理関数を実行し終わるまで待たなければならない。各メ
モリ・プールに別個のミューテックス・ロックを与える
ことによって、各スレッドは、並列に、それ自体のメモ
リ・プール内でそれ自体のメモリの割り当てや解放を行
うことができ、しかも対応されていないスレッドからの
アクセスを防止する。

【００３６】スレッドによってメモリ・ブロックを繰り
返し割り当て、解放し、そして再割り当てするに連れ
て、メモリ・プールは更に小さなブロックに細分されて
いく可能性がある。隣接する解放メモリ・ブロックの合
体即ち併合を周期的に実行し、スレッドによって再割り
当て可能な、より大きなメモリ・ブロックを形成する。
しかしながら、メモリ・ブロックを隣接するメモリ・ブ
ロックと合体できるようにする前に、記載中の実施例で
は、最初に、これらのブロックが同一プールからのもの
か否かについて判定を行う。同一プールからのものでな
い場合、これらのブロックの合体を行わず、こうしてデ
ータ劣化の可能性を回避する。

【００３７】mallocプールの併合個々のスレッドがメモリ管理を使用する程度には、著し
い変化がある。例えば、再び図２を参照すると、スレッ
ド３１〜３３は、主スレッド３０によって実行されるタ
スクの完了以前に、それらのタスクを完了する場合もあ
る。かかる状況では、主スレッドは、随意選択のインタ
ーフェース関数をコールし、スレッド３１〜３３によっ
て割り当てられたメモリを主スレッド３０に転送するこ
とができる。言い換えれば、マルチスレッド部分の終了
時に、主スレッドによってこの関数をコールし、他のス
レッドによって以前に割り当てられたメモリを主スレッ
ドに統合化することができる。この実施例において用い
たルーチンは、以下のプロトタイプを有する。

【００３８】void merge_malloc_pools (void); 多数のスレッドがアプリケーション全体にわたって重要
なメモリ管理を行うような場合には、かかるアプリケー
ションにはこの関数の使用は不要であろう。

【００３９】図５を参照すると、主スレッド３０および
ユーザ・スレッド３１内で走るアプリケーションの簡略
表現が示されている。ここでは、それぞれスレッド３
０，３１と対応付けられているメモリ・プール２４，３
８（図２）が既に確立されていると仮定する。主スレッ
ド３０に関して、第１のmallocルーチン・コールを実行
し、SIZE#1バイトを有するメモリのブロックを要求す
る。このアプリケーションでは後に、第１のfreeルーチ
ン・コール５２を実行し、ポインタOLDによって識別さ
れるメモリのブロックを返す。この時点で、通常合体を
行い、返されたメモリのブロックを隣接するブロックと
結合するが、これらが双方とも同一メモリ・プールから
来た場合に限る。更に後に、このスレッドにおいて、第
２のmallocルーチン・コール５４を行い、SIZE#2バイト
を有するメモリのブロックを要求する。次に、ポインタ
OLDによって識別されるメモリのブロックをSIZE#3バイ
トにサイズ変更するreallocコール５６が続く。スレッ
ド３１は、スレッド３０と同時にプロシージャを実行す
るものとして示されている。例えば、第１のmallocルー
チン・コール６０を実行した後のある時刻に、第１のfr
eeルーチン・コール６２を実行する。最後に、この例で
は、アプリケーションのマルチスレッド部分の完了後
に、merge_malloc_poolsルーチン６４をコールし、スレ
ッド３１によって割り当てられたメモリ・ブロックを、
主スレッド３０に統合する。

【００４０】［資料］として添付したのは、既存のmall
ocパッケージをマルチスレッド・バージョンのmallocパ
ッケージに変換する方法の一実施態様についての、ソー
ス・コード・ソフトウエアである。このソース・コード
は、The C programming language (B. W. Kerninghan
and D. M. Richie, Prentice Hall (1988))に記載され
ている１組のメモリ割り当てルーチンに基づくプログラ
ムの１バージョンを表わす。

【００４１】他の実施例は、特許請求の範囲に記載する
通りである。

【００４２】［資料］ /* A multithreaded (MT-hot) version of malloc and friends. Based on the malloc package from the Kernighan & Ritchie ANSI C book (page 185), with modifications. By Greg Nakhimovsky Sun Microsystems, Inc. Market Development Engineering January 1996 Changes from the original K&R version: * All malloc routines are made MT-safe. * realloc() is added. * A separate free pool is created for each thread up to NUM_POOLS. NUM_POOLS is currently set to 4 but can be adjusted. * The pool number is stored in the same header. * Increased header size to 16 bytes to make room for pool number. * Each pool is protected by its own mutex lock. * free() returns the freed block to the pool the block was malloc'ed from. * realloc() modifies the block in the original pool. * Coalescing (merging) is only done within the same pool. * A new routine is added for external interface: merge_malloc_pools(). If called by the application from the main thread after the threaded section is over, it transfers all memory blocks fro m the additional pools back to the main pool. This call will eliminate a "memory leak", in a sense that the main thread c an reuse memory used by other threads. * To reduce additional fragmentation, the default block size for sbrk() is increased from 8K to 64K. When multiple treads allocate and deallocate their own memory, they don't wait on their own locks. When one thread tries to free or reallocate memory allocated by another thread, the lock protects the free list from being updated or used by more than one thread at a time. The lock is also used when there are more than NUM_POOLS threads active at the same time. */ #include <stdio.h> #include <thread.h> #include <synch.h> */ number of pools for different threads */ #define NUM_POOLS 4 /* minimum number of 16-byte units to request from system = 64K in this case */ #define NALLOC 4096 #define MAGIC 0x5555 /* to check integrity of pointers to free, realloc */ #ifdef _REENTRANT /* will not compile without _REENTRANT defined */ static mutex_t_pool_locks[NUM_POOLS]; #endif /* _REENTRANT */ #define GET_THREAD_INDEX(self) ((self) == 1) ? 0 : 1 + ((self)- 4)%(NUM_POOLS-1) #ifndef NULL #define NULL (0) #endif typedef double Align; /* increaded the header size to 16 bytes - GN */ union header { struct { union header *ptr; /* next block if on the free list */ unsigned size; /* size of this block */ unsigned pool; /* pool number */ unsigned magic; /* for checking - using 4 extra bytes */ } s; Align x[2]; /* need 16 bytes because of the pool number * / } ; typedef union header Header; static Header base[NUM_POOLS]; /* empty lists to get started */ /* starts of free lists */ static Header *freep[NUM_POOLS] = {NULL, NULL, NULL, NULL}; static void *malloc_locked(unsigned nbytes, unsigned thread_index); static void free_locked(void *ap, unsigned thread_index); static Header *morecore(unsigned nunits, unsigned thread_index); void *malloc(unsigned nbytes) { void *ret; unsigned self, thread_index; self = thr_self(); thread_index = GET_THREAD_INDEX(self); mutex_lock(&_pool_locks[thread_index]); ret = malloc_locked(nbytes, thread_index); mutex_unlock(&_pool_locks[thread_index]); return ret; } static void *malloc_locked(unsigned nbytes, unsigned thread_index) { Header *p, *prevp; unsigned nunits; nunits = (nbytes+sizeof(Header)-1)/sizeof(Header) + 1; if ((prevp = freep[thread_index]) == NULL) { /* no free list yet */ base[thread_index].s.ptr = freep[thread_index] = prevp = &base[thread_index]; base[thread_index].s.size = 0; base[thread_index].s.pool = thread_index; base[thread_index].s.magic = MAGIC; } for (p = prevp->s.ptr; ; prevp = p, p = P->s.ptr) { if (p->s.size >= nunits) { /* big enough */ if (p->s.size == nunits) /* exactly */ prevp->s.ptr = p->s.ptr; else { p->s.size -= nunits; p (= p->s.size; p->s.size = nunits; p->s.pool = thread_index; p->s.magic = MAGIC; } freep[thread_index] = prevp; return (void *)(p(1); } if (p == freep[thread_index]) /* wrapped around free list */ if ((p = morecore(nunits, thread_index)) == NULL) return NULL; /* none left */ } } static Header *morecore(unsigned nu, unsigned thread_index) { char *cp, *sbrk(int); Header *up; if (nu < NALLOC) nu = NALLOC; cp = sbrk(nu * sizeof(Header)); /* sbrk() assumed locked - GN */ if (cp == (char *) -1) /* no space at all */ return NULL; up = (Header *) cp; up->s.size = nu; up->s.pool = thread_index; up->s.magic = MAGIC; free_locked((void *)(up(1), thread_index); return freep[thread_index]; } void free(void *ap) { Header *bp; unsigned thread_index; int i; if(ap == NULL) return; /* free the block of the thread which allocated it */ bp = (Header *)ap - 1; /* point to block header */ if (bp->s.magic != MAGIC) { printf("bogus pointer %x passed to free()\n", ap); abort(); } thread_index = bp->s.pool; mutex_lock(&_pool_locks[thread_index]); free_locked(ap, thread_index); mutex_unlock(&_pool_locks[thread_index]); } static void free_locked(void *ap, unsigned thread_index) { Header *bp, *p; int i; bp = (Header *)ap - 1; /* point to block header */ for (p = freep[thread_index]; !(bp > p && bp < p->s.ptr); p = p->s.ptr) if (p >= p->s.ptr && (bp > p || bp < p->s.ptr)) break; /*freed block at start or end of arena * / if (bp ( bp->s.size == p->s.ptr && bp->s.pool == p->s.pool) { /* join to upper nbr */ bp->s.size (= p->s.ptr->s.size; bp->s.ptr = p->s.ptr->s.ptr; } else bp->s.ptr = p->s.ptr; if (p ( p->s.size == bp && p->s.pool == bp->s.pool) { /* join to lower nbr */ p->s.size (= bp->s.size; p->s.ptr = bp->s.ptr; } else p->s.ptr = bp; freep[thread_index] = p; } void *realloc(void* old, unsigned nbytes) /* Added by GN, since realloc() is not given in the K&R book */ { void *new; Header *bp; unsigned self, thread_index, ncopy; if(old == NULL) return malloc(nbytes); self = thr_self(); thread_index = GET_THREAD_INDEX(self); bp = (Header *)old - 1; /* point to block header */ if (bp->s.magic != MAGIC) { printf("bogus pointer %x passed to realloc\n", old); abort(); } if (bp->s.pool != thread_index) thread_index = bp->s.pool; mutex_lock(&_pool_locks[thread_index]); /* for simplicity, always allocate a new block, copy and free the old one */ if ((new = malloc_locked(nbytes, thread_index)) == NULL) { mutex_unlock(&_pool_locks[thread_index]); return NULL; } if(nbytes > 0) { ncopy = sizeof(Header) * (bp->s.size - 1); if(ncopy > nbytes) ncopy = nbytes; memcpy(new, old, ncopy); } free_locked(old, thread_index); mutex_unlock(&_pool_locks[thread_index]); return new; } /* New externally called function merging all additional pools into the main thread's pool. Should only be called from the main thread. Assumes that only the main thead is active. */ void merge_malloc_pools(void) { int i; Header *p, *prevp; /* skip the main thread's pool (0) */ for (i=1; i<NUM_POOLS; i(() { prevp = freep[i]; if(prevp != NULL) { for (p = prevp->s.ptr; ; prevp = p, p = p->s.ptr) { if(p->s.size > 0) { p->s.pool = 0; /* no need to lock - main thread only */ free_locked((void *)(p(1), 0); } if (p == freep[i]) /* end of list */ break; } freep[i] = NULL; } } }

【図面の簡単な説明】

【図１】本発明と共に使用するのに適した、マルチ処理
コンピュータ・システムのブロック図。

【図２】マルチスレッド・アプリケーションと共有メモ
リとの間の関係を示す図。

【図３】メモリ内のデータ・オブジェクトを示す図。

【図４】マルチスレッド・アプリケーションと、メモリ
・プールより多いスレッドが存在する共有メモリとの間
の関係を示す図。

【図５】あるプロセス内で実行中のスレッドからメモリ
管理関数をコールするアプリケーションの一例を示す
図。

【符号の説明】

１０マルチ処理ネットワーク１２ａ〜１２ｎプロセッサ１４システム・メモリ１６システム・バス２０アプリケーション２２スレッド２４メモリ・プール３０〜３３スレッド３８〜４０メモリ・プール５２第１のfreeルーチン・コール５４第２のmallocルーチン・コール５６ reallocコール６０第１のmallocルーチン・コール６２第１のfreeルーチン・コール６４ merge_malloc_poolsルーチン

───────────────────────────────────────────────────── フロントページの続き (71)出願人 597004720 2550 ＧａｒｃｉａＡｖｅｎｕｅ，ＭＳＰＡＬ１−521，ＭｏｕｎｔａｉｎＶｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，ＵｎｉｔｅｄＳｔａｔｅｓｏｆＡｍｅｒｉｃａ (72)発明者グレゴリー・ナヒモフスキーアメリカ合衆国マサチューセッツ州01880, ウェイクフィールド，フランダース・レーン 22

Claims

【特許請求の範囲】

【請求項１】各々システム・メモリへのアクセスを有す
る複数のスレッドがプロセス内で並列に走る、マルチス
レッド・コンピュータ環境において、メモリを割り当て
る方法であって、前記システム・メモリにおいて複数のメモリ・プールを
確立するステップと、各スレッドを、前記複数のメモリ
・プールの１つにマップするステップと、各スレッドについて、対応するメモリ・プールからのユ
ーザ・メモリ・ブロックを動的に割り当てるステップ
と、から成ることを特徴とする方法。
【請求項２】請求項１記載の方法において、前記メモリ
・ブロックを動的に割り当てるステップは、割り当てを
望むブロックにおけるバイト数を指定するステップを含
むことを特徴とする方法。
【請求項３】請求項１記載の方法であって、更に、異な
るスレッドによる、１つのメモリ・プールへの同時アク
セスを防止するステップを含むことを特徴とする方法。
【請求項４】請求項１記載の方法において、各スレッド
にメモリ・プールを確立するステップは、予め選択され
ているサイズのメモリ・バッファを割り当てるステップ
を含むことを特徴とする方法。
【請求項５】請求項４記載の方法であって、更に、前記
バッファ・メモリの予め選択されているサイズに等しい
増加分だけ、前記システム・メモリから追加メモリを割
り当てることによって、前記メモリ・プールのサイズを
動的に増加させるステップを含むことを特徴とする方
法。
【請求項６】請求項４記載の方法において、前記バッフ
ァの予め選択されているサイズは６４Ｋバイトであるこ
とを特徴とする方法。
【請求項７】請求項１記載の方法であって、更に、前記
スレッドの１つが、前記スレッドの他のもののメモリ・
プールから、当該スレッドのメモリ・プールにメモリを
転送するステップを含むことを特徴とする方法。
【請求項８】請求項１記載の方法において、前記各メモ
リ・プールは、メモリ・プールに対応付けられたスレッ
ド・インデックスによって識別されるスタティック変数
のアレイによって定義されることを特徴とする方法。
【請求項９】請求項８記載の方法において、前記各メモ
リ・プールは、メモリ・ブロックのデータ構造として維
持されることを特徴とする方法。
【請求項１０】請求項９記載の方法において、各メモリ
・ブロックは、当該メモリ・ブロックのサイズと、それ
が対応付けられているメモリ・プール・インデックスと
を含むヘッダを備えていることを特徴とする方法。
【請求項１１】請求項１０記載の方法において、前記ブ
ロックのサイズおよび前記メモリ・プール・インデック
スは各々４バイトであることを特徴とする方法。
【請求項１２】請求項１記載の方法であって、更に、各
スレッドがメモリ・ブロックの割り当てを解除し、前記
メモリ・プールに返すステップを含むことを特徴とする
方法。
【請求項１３】請求項１２記載の方法において、元々前
記メモリ・ブロックを割り当てたスレッドが、該メモリ
・ブロックの割り当てを解除し、前記スレッドに対応す
るメモリ・プールに返すことを特徴とする方法。
【請求項１４】請求項１２記載の方法であって、更に、
割り当て解除されたメモリ・ブロックを合体し、異なる
プールからのメモリ・ブロックの合体を防止するステッ
プを含むことを特徴とする方法。
【請求項１５】請求項１記載の方法であって、更に、メ
モリ・プールによって割り当てられたメモリの割り当て
済みブロックのサイズを変更するステップを含むことを
特徴とする方法。
【請求項１６】メモリを含むコンピュータ上で実行可能
なコンピュータ・プログラムを記憶するコンピュータ読
み取り可能媒体であって、前記コンピュータ・プログラ
ムは、各々システム・メモリへのアクセスを有する複数
のスレッドがプロセス内で並列に走る、マルチスレッド
・コンピュータ環境において、メモリを割り当てるもの
であり、前記記憶されているプログラムは、前記システム・メモリにおいて複数のメモリ・プールを
確立するコンピュータ読み取り可能命令と、各スレッドを、前記複数のメモリ・プールの１つにマッ
プするコンピュータ読み取り可能命令と、各スレッドについて、対応するメモリ・プールからのユ
ーザ・メモリ・ブロックを動的に割り当てるコンピュー
タ読み取り可能命令と、から成ることを特徴とするコン
ピュータ読み取り可能媒体。
【請求項１７】請求項１６記載のコンピュータ読み取り
可能媒体において、前記記憶されているプログラムは、
更に、異なるスレッドによる、１つのメモリ・プールへ
の同時アクセスを防止するコンピュータ命令を含むこと
を特徴とするコンピュータ読み取り可能媒体。
【請求項１８】請求項１６記載のコンピュータ読み取り
可能媒体において、前記記憶されているプログラムは、
更に、前記スレッドの１つに、該スレッドの他のものの
メモリ・スレッドから、それ自体のメモリ・プールにメ
モリを転送させるコンピュータ命令を含むことを特徴と
するコンピュータ読み取り可能媒体。
【請求項１９】請求項１６記載のコンピュータ読み取り
可能媒体において、各メモリ・プールは、メモリ・プー
ルに対応付けられたスレッド・インデックスによって識
別される、スタティック変数のアレイによって定義され
ることを特徴とするコンピュータ読み取り可能媒体。
【請求項２０】請求項１６記載のコンピュータ読み取り
可能媒体において、前記記憶されているプログラムは、
更に、割り当て解除されたメモリ・ブロックを合体し、
異なるプールからのメモリ・ブロックの合体を防止する
コンピュータ命令を含むことを特徴とするコンピュータ
読み取り可能媒体。
【請求項２１】システムであって、各スレッドがメモリへのアクセスを有する、複数のスレ
ッドがプロセス内で並列に走る、マルチスレッド・コン
ピュータ環境において、メモリを割り当てるコンピュー
タ・プログラムをその一部に記憶するメモリであって、
前記記憶されているプログラムが、前記メモリにおいて複数のメモリ・プールを確立するコ
ンピュータ読み取り可能命令と、各スレッドを、前記複数のメモリ・プールの１つにマッ
プするコンピュータ読み取り可能命令と、各スレッドについて、対応するメモリ・プールからのユ
ーザ・メモリ・ブロックを動的に割り当てるコンピュー
タ読み取り可能命令と、から成る前記メモリと、前記コンピュータ読み取り可能命令を実行するプロセッ
サと、前記メモリを前記プロセッサに接続するバスと、から成
ることを特徴とするシステム。