JP5401676B2 - マルチスレッドアプリケーション用のハッシュテーブルのコンカレントリハッシュの実行 - Google Patents

Description

ハッシュテーブルは、データベース、サーチエンジン、統計処理、および動的スクリプト言語等、多岐にわたるアプリケーションの基本的な構築ブロックである。ハッシュテーブルは、鍵と値とを関連付けるコンテナ群である。ハッシュテーブルは、テーブルのエントリに格納されているアイテムの位置の配置（バケット）を、そのハッシュ値とコンテナの現在の容量とを利用して計算する。しかし、コンテナは通常、その容量を動的に増加させる必要があり、これは、再割り当て、またはさらなるメモリの部分の割り当てを意味する。従って、増加した容量により、アイテムの配置が無効になり、アイテムを新たな位置に移す必要がでてくることもあり、この処理は通常、リハッシュと称されている。

ハッシュテーブルの既知のコンカレントアルゴリズムでは、スレッドがコンテナのサイズを変更すると決定すると、一部の（あるいは全ての場合もある）並列処理をブロック（一時停止）して、サイズ変更とリハッシュ処理の両方が終わるのを待つ。これにより、並列性能ひいては性能が落ちる。また別の問題として、サイズ変更におけるランタイムおよび処理の複雑性は、サイズ変更を行わない同じ処理とかなり異なってしまうことがある。

本発明の一実施形態におけるハッシュテーブルを更新する方法のフロー図である。 本発明の一実施形態におけるバケットのブロック図である。 本発明の一実施形態における新たなバケットの割り当てを示すブロック図である。 本発明の別の実施形態における新たなバケットの割り当てを示すブロック図である。 本発明の一実施形態においてルックアップ／リハッシュを行う方法のフロー図である。 本発明の一実施形態におけるシステムのブロック図である。

実施形態は、マルチプロセッサシステム（例えば１以上のマルチコアプロセッサを有するシステム等）の１以上のコアを実行することのできる１以上のスレッドによりアクセスされる共有メモリである並列ハッシュテーブルをコンカレントにサイズ変更する、および、オンデマンドバケットごとにリハッシュするために利用することができる。バケットにアイテムセットを格納可能なハッシュテーブルに適用可能である。簡潔性のために、テーブルの初期容量を２の累乗とする。あるアイテムのハッシュ値を容量で除算した余剰は、そのアイテムを格納するバケットのインデックスを示す。簡潔性のために、一部の実施形態では、バケットインデックスを式１：バケット＿ｉｄｘ＝ハッシュ＆（容量−１）により計算することができる。本式において、ハッシュとは、鍵をハッシュ関数に当てはめてハッシュ値を得るハッシュ計算により得られるハッシュ値であり、「＆」は、二進表現のビット積ＡＮＤを示す。一実施形態では、容量は、ハッシュテーブルのバケット数の単位で示されるが、本発明の範囲はこの点に限定はされない。

容量を増やすという観点から、本発明の一実施形態におけるアルゴリズムは、既存のバケットと同数のバケットを割り当てて、既存のバケットも維持することで、バケット数を二倍にすることができる。各新たなバケットは、値が１である最高ビットを除いて、新たなバケットのインデックスと同じ値（つまりビットセット）を持つインデックスを有する既存のバケット（親）へと論理的にマッピングされる。例えばバケットのインデックスが二進法表記で００１０１１０１である場合、親バケットのインデックスは００００１１０１となる。つまり、親のバケットのインデックスは式２：親＿ｉｄｘ＝バケット＿ｉｄｘ＆（１＜＜└Ｌｏｇ２（バケット＿ｉｄｘ）┘）−１）から得ることができる。本式において、＜＜は、二進左オペランドを、右オペランドが指定するビット数だけシフトすることを示す。

多くの実装例では、新たなバケットが他の新たなバケットを親とする、ということができる。後述するが一部の実装例では、そのための割り当てを単一のメモリ要求に組み合わせることができる。

図１は、本発明の一実施形態におけるハッシュテーブルを更新する方法のフロー図である。図１を参照すると、方法１０は、ハッシュテーブルでスペースの増加が必要であると決定されることにより始められてよい（ブロック２０）。本発明の範囲はこの点に限定はされないが、このような決定は、テーブルの負荷率（load factor）に基づき、ハッシュテーブルに格納されているデータ量が所定の閾値（例えばテーブル全量の一定のパーセント）に達したときの新たなデータ対の挿入処理の時点で、例えばシステムソフトウェアが行うことができる。もちろん、他の実施形態では、スペースの増加が必要であるという決定は他の様々な方法で行うことができる。例えばユーザは、ある呼び出しにおけるバケット数をリザーブ処理用に指定することもできる。

増加の決定が行われると、制御をブロック３０に渡し、新たなバケットを割り当ててよい。より具体的には、ハッシュテーブルの現在のバケット数に対応する数のバケットを割り当ててよい。このようにして、テーブルに割り当てるバケット数を二倍にすることができる。一実施形態では、アロケータを呼び出して、必要なメモリ量を得て、バケットを新たな空のバケットとして初期化する。そして、この新たなスペースを公開することができる（ブロック４０）。本発明の範囲はこの点に限定はされないが、公開は、容量の値を含む変数に更新することにより行うことができる。一実施形態では、この更新は、「容量」変数に対する、解放とともに行う格納処理（あるいは、アトミック・ライト）により行ってよい。または、このような更新を、容量から１を差し引いた値に対応するマスクに対して行うこともできる。従って新たなバケットを割り当て、この新たなスペースを公開することにより、割り当ては、元のバケットに存在しているデータを新たなバケットへと、完全リハッシュをする必要なく完了する。つまり、割り当ては、リハッシュとは独立して行われ、新たなスペースの公開で終了する。公開される新たなスペース内の各バケットは、最初は、リハッシュがなされていないものとしてマーキングされている。

図２Ａは、本発明の一実施形態におけるバケットのブロック図である。図２Ａに示すように、バケット１００は、データ、つまり鍵およびアイテムの対を含むデータ部分１１０（ここでは概してデータ対と称される）を含んでよい。データ部分１１０は、オプションとして、直接に（埋め込みにより）または間接に、例えばポインタにより、限られた対のセット（アレイ）を含むことができる。加えて、制御情報１２０が存在している。制御情報１２０には、ミューテックス等の同期オブジェクト（ａ）、フラグ、カウンタ等の様々な情報を含みうる制御フィールド（ｂ）、および、所与のバケットがリハッシュされたかを示す様々な情報およびリハッシュされたレベルの数を含んでよい、リハッシュ状態フィールド（ｃ）を含む様々な情報が含まれてよい（これを一対多の方法で利用することができることは後述する）。

図２Ｂは、本発明の一実施形態における新たなバケットの割り当てを示すブロック図である。図２Ｂに示すように、複数の既存のバケット２００_ａ−２００_ｎが存在している。これら各バケットは、一例としては図２Ａのバケット１００に基づいている。再割り当て処理においては、新たなバケットを親バケットに論理的にマッピングして、新たな空のバケットのセット２１０_ａ−２１０_ｎを生成する。このように、割り当ては、既存のバケットと同じ数だけ行われる。これら新たなバケットはそれぞれ、親バケットのいずれかに論理的にマッピングされて、例えば図２Ａに示すリハッシュフィールド（ｃ）等の制御情報１２０内に、リハッシュがなされていないものとしてマーキングされる。

また、新たなバケットのうち少なくとも幾つかを、図２Ｃに示す他の新たなバケットにマッピングすることもできる。従って図２Ｃは図２Ｂのサブセットであり、（１）親バケットもリハッシュされていない、および、（２）割り当て同士の組み合わせ、という２つの別個の可能性を示す。このように、新たな空のバケット２１０_ａ−２１０_ｎを、既存のバケット２００_ａ−２００_ｎにマッピングする。そしてさらなる新たな空のバケット２２０_ａ−２２０_ｎも、既存のバケット２００_ａ−２００_ｎにマッピングする。加えて、他の新たな空のバケット２３０_ａ‐２３０_ｎを、新たな空のバケット２１０_ａ‐２１０_ｎにマッピングする。バケット２１０_ａから始まり２３０_ｎで終わる新たな空のバケットを、組み合わせられた割り当てが連続したスペースとして、バケット数を一度で数倍にすることができる（例えば、バケット数を４倍にすることができる）。

新たな容量の値の割り当ておよび公開が終わると、ルックアップ処理により、新たな容量の値を利用してバケットインデックスを計算する。新たな容量を公開した後で、新たなバケットを探す処理は、先ず、親バケット（１または複数）を探して、オプションとして（しかし最終的には）そのコンテンツを新たなバケット（１または複数）へとリハッシュする。従って、コンテナ内で、リハッシュ処理を延期したり分割したりすることができる。新たな容量の値を利用して計算されたインデックスは、リハッシュがなされていないものとしてマーキングされているバケットを示している可能性がある。その場合には、リハッシュされたバケットまたは要求されている鍵を発見するために、先ず、親バケット、次に祖父母バケットを探す、というようにルックアップ処理を続ける。所望の情報が見つかると、ルックアップの結果を要求者に戻す。さらには、バケットごとのリハッシュ（処理済のバケットのリハッシュ）も行うことができる。このタイプのリハッシュは、再割り当て時に全テーブルの完全なリハッシュを行う時間とコストをかけるのではなく、ルックアップ要求に応じて個々のバケットをリハッシュ（オンデマンドにより）する処理であり、レイジー・リハッシュと称される場合がある。このタイプのリハッシュは、また、外部の（ユーザによる）要求に従って行うこともできる。

従ってオプションとして（しかし最終的には）、途上にある全てのアイテムを、データ対を（これに属していうる場合）新たなバケットに移動させることにより、リハッシュすることができる。このために異なる方法を利用することも可能である。一例としては、２状態を利用してバケットを、リハッシュされているものか、リハッシュされていないものかを識別する。この実装例では、専用オーナーをリハッシュ処理に割り当てる。こうするために、スレッドは、相互排他的な同期を利用してバケットをロックして、他のスレッドが処理中にアクセスできないようにして待たせる。

第３の状態である「部分的リハッシュ」と称される状態を加えて、他のスレッドが、リハッシュされた新たなバケットにコンカレントにアクセスしたり、同じ親バケットのリハッシュに参加したりすることがないようにすることもできる。３状態の実装の主な目的は、バケットが別のスレッドによりリハッシュされるまで待たなければならないスレッドのロックを解除することである。

２状態のロジックについては、２つのバケット（親および次の後継バケット）の間の再帰的なリハッシュを行うことができ、あるいは、親を全てのリハッシュされていない後続するものにリハッシュする一対多の方法を利用することができる。２状態の再帰的なリハッシュアルゴリズムにおいては、１つの状態変数（例えば図２Ａの制御情報１２０に存在するもの等）が、ＮＥＷ（空のリハッシュされていないもの）、ＥＭＰＴＹ（しかしリハッシュされているもの）、およびＦＩＬＬＥＤ（リハッシュされているもの）という状態をとることができる。例えば、データ対へのポインタは、そのデータのことを表しつつ、且つ、全ての３つの状態を表すことができる。一対多の実装では、あるバケットのリハッシュされたレベル（容量）の数を表すバケットデータ構造のさらなる部材が利用される点に留意されたい。

図３は、本発明の一実施形態においてルックアップ／リハッシュを行う方法のフロー図である。このフロー図は、一対一（再帰的）および一対多の方法両方に対応する高レベル図を示すことを目的としており、そのいずれをも実装可能であり、両方を以下に詳述する。ルックアップ要求は、発見のみ又は挿入処理（find-only or insert operations）についてのものであってよい。説明の便宜上、発見処理について説明する。図３に示すように、方法３００は、ルックアップ要求のバケットインデックスおよびアドレスを計算することから始められてよい（ブロック３０５）。例えば、要求されたデータ対に関連付けられている鍵をハッシュ関数に導入してハッシュ値を生成して、これをハッシュテーブルの容量とともに利用して、インデックス、ひいてはメモリのアドレスを得ることができる。次に、ルックアップ要求が、リハッシュされていない空のバケットに対するものであるかを判断する（ダイアモンド３１０）。ルックアップ要求がリハッシュされていないバケットに対するものではないと判断された場合には、インデックスされたバケットにアクセスしてルックアップを行い、データ対を要求者に提供する（ブロック３１５）。同期、バケット内の検索、レース条件のチェック、およびオプションとして全ルックアップ処理の再開（レースが検知された場合）等の追加的な処理をこのステップ中に行うこともできる、これらに関しては後述する。

ルックアップ要求がリハッシュされていないバケットに対するものであると判断された場合には、制御をブロック３２０に渡す。ブロック３２０では、親バケットに対してインデックスおよびアドレスを計算することができる。上述したように、一部の実装例では、これらのインデックスは、式２に従って計算することができる。計算されたインデックスは、親バケットに対するアクセスに利用することができる。アクセスされたバケットをチェックして、リハッシュされたものであるか、または、要求されているデータ対を含んでいるか、を判断する（ダイアモンド３３０）。この判断は、一部にバケットのリハッシュ状態に基づいて行われてよい。リハッシュされたバケットが発見された場合、バケット同士を同期して（ブロック３４０）、データ対を要求者に戻すことができる（ブロック３５０）。発見されない場合には、制御はブロック３２０に戻されて、このループをさらに繰り返す。ブロック３４０の同期には、検索またはリハッシュ処理を実行する前に、対象となるバケットをロックする処理が含まれてよい。ブロック３５０におけるリハッシュするか否かの判断は、所与のアルゴリズム（オンデマンドのリハッシュ、部分的なリハッシュ、または専用スレッドによるリハッシュ等）に基づいていてよい。リハッシュを実行する場合、１以上のバケットのリハッシュ状態を、リハッシュが実行されたときに更新してよい。一対多の方法においては、親および全ての新たなバケットの状態を変更する。リハッシュ後のこの点においては、親バケットから一部の対を取り出して、後継バケットに移す（また、一対多の方法では変更された状態も移す）。

バケットは割り当てを解除されたりコンカレントに移動させられたりしないので、ブロックしない、またはロックフリーのアルゴリズム（non-blocking or lock-free algorithms）のなかには、バケットおよび埋め込みデータにアクセスするために利用可能なものもある。このようにして、ハッシュテーブルを利用するアプリケーションの性能およびスケーラビリティを増加させることができる。

多数のスレッドが、共有リソースである１つのハッシュテーブルにアクセスするケースでは、リハッシュ・ルックアップ・レース条件が生じることがある。鍵が発見されない場合には、バケットのリハッシュ中に一緒に移動された可能性がある。鍵が存在しないことを確かめるには、現在の容量を、バケットインデックスを計算する際に利用した初期容量と比較する。これら同士が等しくない場合には、次に、これら値で計算したバケットインデックスが異なっているかを判断する（両方の比較は最後のものに還元することができる）。異なっている場合には、直近の後継バケットがリハッシュされた、またはされている最中の場合、ルックアップを再開するべきである（鍵が存在しないことを確かめる目的で）。容量が２を超える数で乗算された場合には、後継バケットが１つではない可能性がある。レース条件の一例として、並列環境において可能な以下のシーケンスがある。
＜表１＞
１．スレッド１：現在の容量を取得して、ルックアップ処理用にバケットインデックス（Ｘ）を計算する。
２．スレッド２：新たなバケットの割り当てを終了して、新たな容量を公開する。
３．スレッド３：新たな容量の値を取得して、バケット（Ｘ）の新たなスペース（Ｙ）へのリハッシュを開始する。
４．スレッド１：アイテムについてのバケット（Ｘ）を検索して、結果、発見できなかった。しかしこれは、全テーブルアイテムが存在しない、ということを示しているわけではない、というのも、コンカレント成長（２）およびリハッシュ（３）により（Ｙに）移動される可能性もあるからである。

表２は、本発明の一実施形態におけるレース条件の存在を判断する擬似コードの例（つまり、リハッシュ衝突が起こりうるかをチェックするアルゴリズムの一例）を示す。

一実施形態では、３つの関数を有する、２状態の再帰的なリハッシュアルゴリズムが利用可能であり、３つの関数とはつまり、ルックアップ関数、同期と呼び出しとを第３の関数であるリハッシュ関数に行うバケット取得関数、および、リハッシュ関数である。表３は、このような２状態の再帰的なリハッシュアルゴリズムの擬似コードを示す。
＜表３＞
ルックアップ：
１．所与の鍵に対してハッシュ値を計算する
２．現在の容量の値を取得して、バケットインデックスを計算する（ハッシュおよび容量を利用して）
３．読み出し用のバケット取得を呼び出す
４．バケットから鍵を検索する
ａ．発見された場合：バケットを解放して、実行するデータを戻す
５．発見されなかった場合：リハッシュレースをチェックする（表２に基づいて）
ａ．レースがない場合：「挿入処理を実行することができる、または」バケットを解放して戻る
ｂ．レースが検知された：バケットを解放して（２）に移行する
バケット取得（読み書きロックについて実装する）：
１．バケットアドレスを計算／取得
２．バケットの状態を取得する
ａ．ＮＥＷ（リハッシュされていない）である場合：バケットに対する排他的なアクセス件を取得しようとする（一部のスレッドでは成功するはずである）
失敗した場合は、（３）に移行する
ｂ．取得された：バケット状態がまだＮＥＷであるときには（ダブルチェック）、バケットリハッシュを呼び出して戻る、を呼び出す
３．バケットへの所定のアクセスを取得する
バケット取得（相互排他的ロックのみの実装）：
１．ハッシュおよび容量の値を利用してバケットアドレスを計算する
２．バケットへの（排他的な）アクセスを取得する
３．バケットの状態を取得する。
ａ．ＮＥＷ（リハッシュされていない）である場合：バケットリハッシュを呼び出す。
バケットリハッシュ：（「バケット取得」アルゴリズムにより排他的なロックにおいて行われる）
１．新たなバケットをリハッシュされたものとしてマーキングする
２．親バケットのインデックスを計算する
３．読み出し用の親バケット取得を呼び出す
４．親バケットの各データアイテムについて、
ａ．ハッシュ値を計算する
ｂ．アイテムを新たなバケットに移動すべきかをチェックして、結果がイエスであった場合、
ｉ．必要に応じて、親バケットを排他的アクセスにアップグレードする（アップグレード中にロックが遮断された場合、（４）から再開する）
ｉｉ．親バケットから新たなバケットへアイテムを移動させる

バケットリハッシュ関数およびバケット取得関数が相互参照されているということから、このアルゴリズムが再帰的であることが分かる。さらに、本発明の一実施形態における並列リハッシュアルゴリズムは、同期レベルを述べているだけであり、特定のロックアルゴリズムを必要としない。例えば、「読み出し用のバケット取得」とは、排他的なロック、共有（リーダ）ロック、またはバージョンカウンタのみ（ブロックしない読み取り処理）の利用、を実際に利用することを意味することができる。また別の実施形態では、一対多の方法を利用することもできる。表４は、一対多のアルゴリズムの擬似コード表現である。
＜表４＞
ルックアップ：
１．所与の鍵についてハッシュ値を計算する
２．現在の容量の値を取得して、バケットインデックス（ハッシュおよび容量を利用して）およびアドレスを計算する
３．バケットの状態を取得して、
リハッシュされていない場合（新たな場合）：
ａ．直近のリハッシュされたルート（親／祖父母等）バケットを発見する
ｂ．取得されるまで、または新たなバケットの状態が「リハッシュされた」と変更されるまで、ルートバケットへの排他的なアクセスを取得しようと努め、状態が変更された場合には、必要に応じてロックを解除して、（４）に移る、
ｃ．バケットリハッシュを呼び出す
４．バケットへの所定のアクセスを取得する
５．バケットから鍵を探す
ｄ．発見された場合：バケットを解放して、実行するデータを戻す
６．発見されなかった場合：リハッシュレースをチェックする（表２に基づいて）
ｅ．レースがない場合：「挿入処理を実行することができる、または」バケットを解放して戻る
ｆ．レースが検知された：バケットを解放して（２）に移行する
バケットリハッシュ（相互排他的ロックにおいて実行）：
１．ルーとバケットおよびその後継バケットそれぞれ全てについて、
ａ．容量の値を格納して、レベルフィールドをリハッシュする（従ってバケットをリハッシュされているものとしてマーキングする）
２．ルートバケットの各データアイテムについて、
ｂ．ハッシュ値を計算する
ｃ．アイテムを新たなバケットに移動すべきかをチェックして、結果がイエスであった場合、
ｉ．親バケットから適切な新たなバケットへアイテムを移動させる

一実施形態では、図書館の連想コンテナのコードに実装することができる。従って、様々な実施形態では、全コンテナ（またはコンテナの一部）をロックして更新する代わりに、割り当てによって、既存のものと同数のバケットを割り当てて、古いほうのバケットも維持することで、バケット数を二倍にすることも可能である。各新たなバケットをリハッシュされていないものとしてマーキングして、既存のバケットに同じインデックスで論理的にマッピングする。一部の実施形態では、割り当てをさらにある公開に組み合わせて、単一のメモリ要求を利用することもできる。従って本発明の一実施形態におけるサイズ変更は、既存のバケットの無効化またはロックのいずれをも行わないので、並列性を脅かさない。

実施形態は数多くの異なるシステムタイプで実装可能である。図４は、本発明の一実施形態におけるシステムのブロック図である。図４に示すように、マイクロプロセッサシステム５００はポイントツーポイントシステムであり、ここでは第１のプロセッサ５７０と第２のプロセッサ５８０とがポイントツーポイントインターコネクト５５０により連結されている。図４に示す各プロセッサ５７０および５８０はマルチコアプロセッサであってよく、第１および第２のプロセッサコアを含むが（つまり、プロセッサコア５７４ａおよび５７４ｂ、並びに、プロセッサコア５８４ａおよび５８４ｂ）、これ以外にも多くのコアが本プロセッサ内に存在している可能性が高い。プロセッサコアは、少なくとも一部の変換済みコードを実行してパフォーマンスを向上させる、および／または、コアのマイクロアーキテクチャがサポートしない命令を処理することができるよう、部分的なエミュレーションモデルを実装することができる。

さらに図４を参照すると、第１のプロセッサ５７０はさらにメモリコントローラハブ（ＭＣＨ）５７２と、ポイントツポイント（Ｐ−Ｐ）インタフェース５７６および５７８とを含む。同様に、第２のプロセッサ５８０は、ＭＣＨ５８２と、Ｐ−Ｐインタフェース５８６および５８８とを含む。図４示すように、ＭＣＨ５７２および５８２は、プロセッサをメモリそれぞれ（つまり、メモリ５３２およびメモリ５３４）に連結し、これらはメインメモリ（例えばプロセッサそれぞれにローカルにアタッチされるＤＲＡＭ）の一部であってよい。第１のプロセッサ５７０および第２のプロセッサ５８０は、Ｐ−Ｐインターコネクト５５２および５５４をそれぞれ介してチップセット５９０に連結されてよい。図４に示すように、チップセット５９０はＰ−Ｐインタフェース５９４および５９８を含む。

さらにチップセット５９０は、チップセット５９０と高性能グラフィックスエンジン５３８とを、Ｐ−Ｐインターコネクト５３９により連結するインタフェース５９２を含む。そしてチップセット５９０は、インタフェース５９６を介して第１のバス５１６に連結されてよい。図３に示すように、第１のバス５１６を第２のバス５２０に連結するバスブリッジ５１８とともに、様々な入出力（Ｉ／Ｏ）デバイス５１４が第１のバス５１６に連結されてよい。例えば一実施形態では、キーボード／マウス５２２、通信デバイス５２６、および、コード５３０を含みうるデータ格納ユニット５２８（例えば、ディスクドライブその他の大容量記憶デバイス）を含む様々なデバイスが第２のバス５２０に連結されてよい。さらにオーディオＩ／Ｏ５２４が第２のバス５２０に連結されてよい。

実施形態は、コードで実装されて、システムをプログラムして命令を行わせるのに利用されうる命令を格納する記憶媒体上に格納されてよい。記憶媒体には、これらに限定はされないが、フロッピー（登録商標）ディスク、光ディスク、固体ドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、および光磁気ディスク、半導体デバイス（ＲＯＭ、ＤＲＡＭ等のＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ（登録商標）、磁気カードまたは光学カード等）、および、電子命令を格納するのに適した他の種類の媒体が含まれてよい。

本発明を限られた数の実施形態を参照して記載してきたが、当業者には数多くの変形例および変更例が可能であることが明らかである。添付請求項はこれら全ての変形例および変更例を本発明の真の精神および範囲に含むことを意図している。

Claims (15)

1. 複数のスレッドによりコンカレントに共有され、第１の数のバケットを有するハッシュテーブルに前記第１の数と少なくとも等しい第２の数のバケットを割り当てる段階と、
   前記第１の数のバケットおよび前記第２の数のバケットを含む前記ハッシュテーブルの更新された容量を公開する段階と、
   前記第１の数のバケットの第１のバケットの内容を、後で前記第１のバケットに存在するデータ対についてルックアップ処理を実行するときに、前記第２の数のバケットの第２のバケットにリハッシュする段階と
   を備え、
   前記第２の数のバケットの各々は、前記第１の数のバケットまたは前記第２の数のバケットの対応する親に論理的にマッピングされ、
   前記割り当てる段階は、前記第１の数のバケットの内容をリハッシュすることなく前記更新された容量を公開することで完了する、方法。
2. リハッシュが必要であるかを判断するためにバケットをロックせずにチェックを実行する段階をさらに備える請求項１に記載の方法。
3. 前記更新した容量を利用してバケットインデックスを計算して、前記バケットインデックスを利用してバケットにアクセスして、前記バケットがリハッシュされていないと判断した場合、前記更新された容量を利用して前記バケットを論理的にマッピングした親バケットの親バケットインデックスを、リハッシュされたルートバケットが発見されるまで再帰的に計算する段階をさらに備える請求項１又は２に記載の方法。
4. ルックアップ要求のデータ対を検索するとき、またはその前に、前記バケットに前記リハッシュされたルートバケットの内容の少なくとも一部をリハッシュする段階をさらに備える請求項１から３のいずれか一項に記載の方法。
5. 前記ルートバケットの前記内容の一部のみをリハッシュするときに、部分的なリハッシュインジケータを設定する段階をさらに備える請求項４に記載の方法。
6. 前記バケットからルックアップ要求のデータ対を探して、前記データ対を戻して、前記バケットの内容をリハッシュしない段階をさらに備える請求項１から５のいずれか一項に記載の方法。
7. 第１のスレッドによるルックアップ処理に応じて、要求されているデータ対を前記第１の数のバケットの第１のバケットに発見しない場合、前記ハッシュテーブルの容量の現在の値を、前記ルックアップ処理についてのバケットインデックスの決定に利用した前記ハッシュテーブルの容量の値と比較して、当該値が前記現在の値と異なっている場合に、直近の後継バケットのインデックスを計算して、前記直近の後継のバケットにアクセスして、前記直近の後継のバケットのリハッシュ状態を判断する段階をさらに備える請求項１から６のいずれか一項に記載の方法。
8. 前記リハッシュ状態がリハッシュされていない新たな状態を示していない場合、前記ルックアップ処理を再開する段階をさらに備える請求項７に記載の方法。
9. コンピュータに、
   複数のスレッドによりコンカレントに共有されるハッシュテーブルにルックアップ処理を行う段階であって、前記ハッシュテーブルの第１の容量の値を利用して、前記ハッシュテーブルの第１のバケットについてのバケットインデックスを計算して、前記バケットインデックスを利用して前記第１のバケットにアクセスして、前記第１のバケットが前記ルックアップ処理のデータ対を含まないと判断することを含む段階と、
   前記ハッシュテーブルの容量の現在の容量の値を、前記第１の容量の値と比較して、前記現在の容量の値が前記第１の容量の値と異なっている場合に、前記現在の容量の値を利用して、更新されたバケットインデックスを計算する段階と、
   前記更新されたバケットインデックスが前記バケットインデックスと異なっている場合に、次のバケットインデックスを計算して、前記更新されたバケットインデックスに対応する次のバケットにアクセスして、前記次のバケットのリハッシュ状態を判断する段階と、
   前記ハッシュテーブルのバケットを、前記ルックアップ処理中に前記バケットにアクセスしている間にリハッシュする段階と
   を実行させるためのプログラム。
10. 前記リハッシュ状態が新たな状態を示していない場合、前記ルックアップ処理を再開する段階をさらに実行させる請求項９に記載のプログラム。
11. 前記ルックアップ処理は第１のスレッドにより実行され、
    前記第１のスレッドが前記計算用の前記第１の容量の値を取得した後に、前記ハッシュテーブルが第２のスレッドにより拡張され、前記第１のスレッドが前記第１のバケットにアクセスする前に、第３のスレッドが、前記第１のバケットのリハッシュを開始する請求項９又は１０に記載のプログラム。
12. システムであって、
    それぞれが１以上のスレッドを実行する第１のコアおよび第２のコアを含むマイクロプロセッサであって、第１のスレッドは、複数のスレッドによりコンカレントに共有されるハッシュテーブルに第２の数のバケットを割り当て、前記ハッシュテーブルは、以前に第１の数のバケットを有しており、前記第２の数は前記第１の数と少なくとも等しく、前記第２の数のバケットの各々は、前記第１の数のバケットまたは前記第２の数のバケットの対応する親に論理的にマッピングされ、前記第１の数のバケットおよび前記第２の数のバケットを含む前記ハッシュテーブルの更新された容量を公開して、前記第１のスレッドは、前記割り当てを、前記第１の数のバケットの内容をリハッシュすることなく前記更新された容量を公開することで完了し、第２のスレッドは、リハッシュが必要であるかを判断するためにロック変数をチェックすることなく前記第１の数のバケットの第１のバケットに対してルックアップ処理を行い、第３のスレッドは、前記第１の数のバケットの前記第１のバケットの内容を、前記第１のバケットに存在するデータ対についてルックアップ処理を実行するときに、前記第２の数のバケットの第２のバケットにリハッシュするプロセッサと、
    前記マイクロプロセッサに連結されて前記ハッシュテーブルを格納する共有メモリであって、前記ハッシュテーブルは前記複数のスレッドの少なくとも一部によりコンカレントにアクセスされる共有メモリと
    を備えるシステム。
13. 前記第２のスレッドは、前記更新した容量を利用して前記第２の数のバケットの中のバケットのバケットインデックスを計算して、前記バケットインデックスを利用して前記バケットにアクセスして、前記バケットがリハッシュされていないと判断した場合、前記バケットを論理的にマッピングした親バケットの親バケットインデックスを、リハッシュされたルートバケットが発見されるまで再帰的に計算する請求項１２に記載のシステム。
14. 前記第２のスレッドは、前記ルックアップの要求のデータ対を検索するとき、またはその前に、前記バケットに前記リハッシュされたルートバケットの内容の少なくとも一部をリハッシュする請求項１２又は１３に記載のシステム。
15. 前記第２のスレッドは、前記ルートバケットの前記内容の一部のみをリハッシュするときに、前記ルートバケットの部分的なリハッシュインジケータを設定する請求項１４に記載のシステム。

Images