Optimized resizing for RCU-protected hash tables

Abstract

A technique for resizing a first RCU-protected hash table stored in a memory. A second RCU-protected hash table is allocated in the memory as a resized version of the first hash table having a different number of hash buckets, with the hash buckets being defined but initially having no hash table elements. The second hash table is populated by linking each hash bucket thereof to all hash buckets of the first hash table containing elements that hash to the second hash bucket. The second hash table is then published so that it is available for searching by hash table readers. The first table is freed from memory after waiting for a grace period which guarantees that no readers searching the first hash table will be affected by the freeing.

Description

BACKGROUND

1. Field

The present disclosure relates to hash table data structures. More particularly, the disclosure concerns adaptive hash table resizing for hash tables that support concurrent access by readers and writers using the read-copy update synchronization mechanism.

2. Description of the Prior Art

By way of background, hash tables provide useful data structures for many applications, with various convenient properties such as constant average time for accesses and modifications. When a hash table is shared for reading and writing by concurrent applications, a suitable synchronization mechanism is required to maintain internal consistency. One technique for supporting concurrent hash table access comes in the form of Read-Copy Update (RCU). RCU is a synchronization mechanism with very low overhead for readers, and thus works particularly well for data structures with significantly more reads than writes, such as hash tables. These properties allow RCU-protected hash tables to scale well to many threads on many processors.

RCU-protected hash tables are implemented using open chaining, with RCU-protected linked lists being provided for the hash buckets. Readers traverse these linked lists without using locks, atomic operations or other forms of mutual exclusion. Writers performing updates to hash table elements protect the readers by waiting for a grace period to elapse before freeing any stale data that the readers may have been referencing.

A challenge respecting RCU-protected hash tables is the need to support efficient hash table resizing. The ability to dynamically resize a hash table stems from the fact that the performance and suitability of hash tables depend heavily on choosing the appropriate size for the table. Making a hash table too small will lead to excessively long hash chains and poor performance. Making a hash table too large will consume too much memory, reducing the memory available for other applications or performance-improving caches, and increasing hardware requirements. Many systems and applications cannot know the proper size of a hash table in advance. Software designed for use on a wide range of system configurations with varying needs may not have the option of choosing a single hash table size suitable for all supported system configurations. Furthermore, the needs of a system may change at run time due to numerous factors, and software must scale both up and down dynamically to meet these needs. For example, in a system that supports virtual computing environments, the ability to shrink a hash table can be particularly important so that memory can be reallocated from one virtual environment to another.

Resizing an RCU-protected hash table so as to either increase or decrease the hash table size results in hash buckets being respectively added to or removed from the hash table, with a corresponding change being made to the hash function. This usually entails one or more hash table elements having to be relocated to a different hash bucket, which can be disruptive to readers if care is not taken to protect their operations during the resizing operation. Existing RCU-protected hash tables support reader-friendly hash table resizing using several approaches. However, there are shortcomings that are variously associated with these approaches, such as (1) the need to maintain duplicate sets of per-element list links, thereby increasing the hash table memory foot print, (2) the need to incur large numbers of grace period delays and require readers to search two hash table versions during resizing, and (3) the need to copy data hash table elements, which makes it difficult or impossible for readers to maintain long-lived references to such elements. The present disclosure presents a new technique that enables optimized resizing of RCU-protected hash tables while permitting concurrent read access without any of the above deficiencies.

SUMMARY

A method, system and computer program product are provided for resizing an RCU-protected hash table stored in a memory. According to the disclosed technique, a second RCU-protected hash table is allocated in the memory. The second hash table represents a resized version of said first hash table that has a different number of hash buckets than the first hash table, the second hash table buckets being defined but initially having no hash table elements. The second hash table is populated by linking each hash bucket of the second hash table to all hash buckets of the first hash table containing elements that hash to the second hash table bucket. The second hash table is then published so that it is available for searching by hash table readers. The first hash table is freed from memory after waiting for a grace period which guarantees that no readers searching the first hash table will be affected by the freeing.

In an embodiment, the second hash table has a size that is an integral factor of a size of the first hash table. In a further embodiment, the resizing comprises shrinking the hash table. In that case, (1) a hash function is selected for the second hash table so that elements of a given hash bucket of the first hash table map to a single hash bucket of the second hash table, and (2) the second hash table bucket links to a first hash bucket of the first hash table that in turn links to at least one additional hash bucket of the first hash table, such that the second hash table bucket chains through different buckets of first hash table whose elements map to the second hash table bucket.

In a further embodiment, the resizing comprises expanding the hash table. In that case, (1) a hash function is selected for the second hash table so that elements of a given hash bucket in the first hash table map to a predictable set of hash buckets of the second hash table, and (2) at least two hash buckets of the second hash table link to the same hash bucket of the first hash table due to the first hash table bucket containing elements that map to different hash buckets of the second hash table. In accordance with this embodiment, the disclosed technique may further include separating the hash bucket of the first hash table into the hash buckets of said second hash table. The separating may be performed by de-linking chains of elements in the hash bucket of the first hash table that respectively hash to different hash buckets of the second hash table. In particular, the separation may be performed by successively changing links from elements in the linked list representing the first hash table bucket to point to the next element of the linked list that hashes to the same bucket in the second hash table, or to point to a bucket-ending sentinel value (e.g., NULL). The separating includes waiting for a grace period before de-linking any two of the chains from each other, the grace period guaranteeing that no readers searching the second hash table will be affected by the de-linking.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying Drawings, in which:

FIG. 1 is a flow diagram showing a first example embodiment for resizing an RCU-protected hash table by shrinking the table;

FIGS. 2A-2G are diagrammatic representations showing successive stages of an example implementation of the hash table resizing operations of FIG. 1;

FIGS. 3A-3B are two parts of a single flow diagram showing a second example embodiment for resizing an RCU-protected hash table by expanding the table;

FIGS. 4A-4H are diagrammatic representations showing successive stages of an example implementation of the hash table resizing operations of FIGS. 3A-3B;

FIG. 5 is a functional block diagram showing a multiprocessor computing system that may be implemented in accordance with the present disclosure;

FIG. 6 is a functional block diagram showing example components of an RCU subsystem in the computer system of FIG. 5; and

FIG. 7 is a diagrammatic illustration showing example media that may be used to provide a computer program product in accordance with the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Introduction

Example embodiments will now be described for dynamically resizing RCU-protected hash tables in a manner that optimizes the resizing operation by conserving memory resources and minimizing both reader and writer overhead. The RCU-protected hash table resizing technique disclosed herein offers the following advantages:

• • (1) Hash table elements need not be copied during a resize operation, thereby avoiding expansion of the read-side cache footprint while still allowing long-lived references to any given element;
  • (2) Readers need only search a single hash chain, even during a resize operation;
  • (3) An expanding resize operation can handle multiple items per RCU grace period in order to minimize the number of RCU grace periods required; and
  • (4) Each hash table element need only maintain one set of list pointers.

In order to achieve these benefits, an approach is taken wherein any resizing-induced changes to the hash function are restricted so that a given hash bucket in the hash table prior to resizing will map to a predictable bucket or set of buckets in the hash table subsequent to resizing. This restriction allows a hash table to be resized using cross-linking operations in which the hash table elements are neither copied nor moved around in memory. Instead, resizing occurs in an incremental fashion so that readers see consistent hash bucket lists with all applicable hash table elements at all times. The approach waits for grace periods between certain steps of the resizing operation in order to guarantee that readers see a sufficiently consistent view of the hash table. Using the disclosed technique, shrinking a hash table requires only a single grace period. Enlarging a hash table requires only a limited number of grace periods that does not exceed the number of hash table elements in the longest hash chain.

Resizing an RCU-Protected Hash Table by Shrinking

To shrink an RCU-protected hash table, an updater may perform the example operations 2-16 shown in FIG. 1. These operations will be described using an example RCU-protected hash table H1 shown in FIG. 2A. The hash table H1 initially has two hash buckets B0 and B1. Hash bucket B0 comprises an RCU-protected linked list L0 containing two odd-numbered elements n₁ and n₃. Hash bucket B1 comprises an RCU-protected linked list L1 containing two even-numbered elements n₂ and n₄. In this example, the hash table H1 will be shrunk by an integral factor of two so as to produce a new resized hash table H2 having only a single hash bucket B-all containing all of the elements n₁, n₂, n₃ and n₄ (see FIG. 2G).

As shown in block 2 of FIG. 1, and with additional reference to FIG. 2B, the updater performing the resizing operation allocates the new smaller hash table H2 representing a resized version of the original hash table H1 having the new hash bucket B-all. When the new hash table H2 is first allocated, the hash bucket B-all is defined but has no hash table elements linked thereto. In block 4 of FIG. 1, a new hash function is created but is constrained so that all the elements of a given bucket in the original hash table H1 map to a single bucket in the new hash table H2. This can be accomplished by applying a different modulus to the same hash function. For example, the original modulus may be the number of hash buckets in the original table H1 and the new modulus may be the number of hash buckets in the new hash table H2. Block 6 of FIG. 1 iterates on blocks 8 and 10 for each bucket in the new hash table H2.

As shown in block 8 of FIG. 1, and with additional reference to FIG. 2C, the new hash table H2 is now populated with hash table elements. This is initiated by linking the new hash bucket B-all in the new hash table H2 to the first hash bucket in the original hash table H1 that contains elements that will hash to the new bucket. In the present example, this is the old hash bucket B0. As shown in block 10 of FIG. 1, and with additional reference to FIG. 2D, the end of the new hash bucket B-all in the new hash table H2 is now linked to the next hash bucket in the original hash table H1 that contains elements that will hash to the new bucket. In the present example, this is the old hash bucket B1. If there were additional hash buckets in the new hash table H2 that contained mapping elements, such buckets would also be successively linked. In this way, the new hash bucket B-all will be chained through all hash buckets of the original hash table H1 whose elements map to the new bucket. In some cases, such chaining may only entail a single hash bucket of the original hash table. In other cases, the chaining will involve different (e.g., two or more) hash buckets of the original hash table (as in the present example). This completes the operations of blocks 6-10 for the present example.

At this point, if a reader were to access the new hash table H2, it would find all of the elements of the original hash table H1. It is therefore safe to set the size of the new hash table H2 and publish it as a valid hash table that replaces the original hash table H1 (e.g., using the rcu_assign_pointer( ) primitive). These operations are shown in blocks 12 and 14 of FIG. 1, and the resultant state is shown in FIG. 2E. Note that any reader that accessed the original hash table H1 prior to the new hash table H2 being published will also be able to find all of the original hash able elements. In block 16 of FIG. 1, the updater waits for a grace period that guarantees all readers will now see the new hash table H2 (e.g., using a primitive such as synchronize_rcu( ) or synchronize_rcu_expedited( )), then frees the original hash table from memory. FIG. 2F illustrates the hash table state following the grace period in which buckets B0 and B1 of the original hash table H1 are no longer valid. FIG. 2G illustrates the final hash table state in which the original hash table H1 has been freed from memory and only the new hash table H2 remains.

Resizing an RCU-Protected Hash Table by Expanding

To expand an RCU-protected hash table, an updater may perform the example operations 20-44 shown in FIGS. 3A-3B. These operations will be described using an example RCU-protected hash table H1 shown in FIG. 4A. The hash table H1 has a single bucket B-all comprising an RCU-protected linked list L-all with two odd-numbered elements n₁ and n₃ and two even-numbered elements n₂ and n₄. In this example, the hash table H1 will be expanded by an integral factor of two so as to produce a new resized hash table H2 having two hash buckets B0 and B1, with B0 containing the two odd-numbered elements n₁ and n₃, and B1 containing the two even-numbered elements n₂ and n₄ (see FIG. 4H).

As shown in block 22 of FIG. 3A, and with additional reference to FIG. 4B, the updater performing the resizing operation allocates the new larger hash table H2 representing a resized version of the original hash table that has the two new hash buckets B0 and B1. When the new hash table H2 is first allocated, the hash buckets B0 and B1 are defined but have no hash table elements linked thereto. In block 24 of FIG. 3A, a new hash function is created but is constrained so that all the elements of a given bucket in the original hash table H1 map to a predictable set of buckets in the new hash table H2. This can be accomplished by applying a different modulus to the same hash function. For example, the original modulus may be the number of hash buckets in the original table H1 and the new modulus may be the number of hash buckets in the new hash table H2. Block 26 of FIG. 3A iterates on block 28 for each bucket in the new hash table H2.

As shown in block 28 of FIG. 3A, the new hash table H2 is now populated with hash table elements. This is initiated by linking each hash bucket of the new hash table H2 to a hash bucket in the original hash table H1 that contains elements that will hash to the new bucket. After two passes through block 28, new hash bucket B0 will be linked to element n₁ in old hash bucket B-all and new hash bucket B1 will be linked to element n₂ in hash bucket B-all. See FIG. 4C. The linking of two hash buckets in the new hash table H2 to a single hash bucket in the original hash table H1 is due to the original hash bucket containing elements that map to different hash buckets in the new hash table H2. This completes the operations of blocks 26-28 for the present example. At this point, because all of the elements that will end up in the new hash buckets B0 and B1 appear in the original hash bucket B-all, the hash table H2 represents an entirely new valid hash table, but with the new buckets being interleaved or “zipped” together in a single imprecise chain. This means that the new hash table H2 can be published (e.g., using the rcu_assign_pointer( ) primitive) as per block 30 of FIG. 3A and as shown in FIG. 4D. New readers will use the new table H2 even though older readers may still be using the old table H1. Insofar as is now desirable to remove the original hash table H1, block 32 of FIG. 3A waits for a grace period (e.g., using a primitive such as synchronize_rcu( ) or synchronize_rcu_expedited( ) and then frees the original hash table from memory. The resultant state in which only the new hash table H2 remains is shown in FIG. 4E.

Blocks 34-44 of FIG. 3B may now be performed to separate or “unzip” the interleaved hash buckets B0 and B1 in the new hash table H2 into separate RCU-protected linked lists. As will now be described, this is handled by successively changing links from hash table elements in the linked list L-all representing the old hash bucket B-all to point to the next element in the linked list that hashes to the same new bucket B0 or B1. Grace periods are implemented as necessary to protect readers from the effects of the link changes. Block 34 of FIG. 3B iterates on blocks 36-44 for each hash bucket in the original hash table H1. In the present example, bucket B-all is the only such bucket. It contain elements that are destined for different hash buckets in the new hash table H2, namely, buckets B0 and B1. Block 36 of FIG. 3B iterates on blocks 38-44 for each hash bucket in the new hash table H2. In block 38 of FIG. 3B, the RCU-protected linked list of a bucket in the original hash table H1 (i.e., the linked list L-all in FIG. 4E) is traversed to identify a chain of hash table elements that all hash to the same bucket in the new hash table H2. The end of this chain will be the immediate predecessor of the first hash table element that does not hash to the same bucket in the new hash table H2. In FIG. 4E, the first element n₁ of the linked list L-all represents the last element of a first chain (comprising but a single element) that hashes to bucket B0 in the new hash table H2. In block 40 of FIG. 3B, the linked list of the same hash bucket in the original hash table H1 (i.e., the linked list L-all in FIG. 4E) is again traversed, starting from the element n₁ identified in block 40, to find the next element (if any) that hashes to the same hash bucket in the new hash table H2 as the previously identified chain (i.e., bucket B0 in this example). In FIG. 4E, this is the third element n₃. In block 42 of FIG. 3B, the first element identified in block 38 is linked to the second element identified in block 40. The result of this operation for the present example is to link element n₁ to element n₃, as shown in FIG. 4F. If there was no second element identified in block 40, the first element in block 38 would be given a pointer that represents a bucket-ending sentinel value (e.g., a NULL pointer).

Before reiterating blocks 38-42 with respect to the next bucket in the new hash table H2 (per block 36), block 44 waits for a grace period (e.g., by calling a primitive such as synchronize_rcu( ) or synchronize_rcu_expedited( )). The grace period is needed because the next iteration will link element n₂ to element n₄, thereby removing the existing link from element n₂ to element n₃. Without the grace period, a reader that is referencing element n₂ but searching for odd-numbered hash table elements would be unable to continue its search when element n₂ is relinked from element n₃ to element n₄.

FIG. 4F shows the result of iterating on blocks 38-44 of FIG. 3B for the first bucket B0 of the new hash table H2. FIG. 4G shows the result of iterating on blocks 38-44 for the second bucket B1 of the new hash table H2. If there were additional elements of the original bucket B-all, the same processing would be performed until all of the elements of that bucket are linked into their respective buckets in the new hash table H2 (i.e., buckets B0 and B1). FIG. 4H shows the resultant new hash table H2, with hash bucket B0 comprising a linked list L0 and hash bucket B1 comprising a linked list L1.

Readers

Advantageously, the foregoing resizing techniques allow readers to perform concurrent read operations during hash table resizing without incurring any significant overhead. To access an RCU-protected hash table for reading, the reader initiates an RCU read-side critical section, for example, using the rcu_read_lock( ) primitive. The only additional step required of the reader is to snapshot the original hash table pointer in case an updater replaces the pointer during the reader's lookup operation. This represents a simple fetch and store sequence to create a local copy of the pointer. Once the reader has done this, it may search the hash table in conventional fashion, as by (1) hashing the desired key, modulo the number of buckets, (2) searching for the corresponding hash bucket, (3) traversing the hash bucket's linked list, comparing each element's key to the desired key, and (4) carrying out the desired read operation on the hash table element whose key matches the desired key. Thereafter, the reader may exit the RCU read-side critical section, for example, using the rcu_read_unlock( ) primitive. In this way, readers search only one hash bucket, as required.

Example Computing Environment

Turning now to the FIG. 5, an example computing environment is illustrated in which hash table resizing may be implemented. In particular, an example computer system 102 is shown in which one or more processors 104₁, 104₂ . . . 104_n are operatively connected by way of a common bus 106 (or other interconnection pathway) to a shared memory 108. Respectively associated with each processor 104₁, 104₂ . . . 104_n is a conventional cache memory 110₁, 110₂ . . . 110_n and a cache controller 112₁, 112₂ . . . 112_n. A conventional memory controller 114 is associated with the shared memory 108. It stores an RCU-protected hash table 116.

The computer system 102 may represent any of several different types of computing apparatus. Examples of such apparatus include, but are not limited to, general purpose computers, special purpose computers, portable computing devices, communication and/or media player devices, set-top devices, embedded systems, and other types of information handling machines. The term “processor” as used with reference to the processors 104₁, 104₂ . . . 104_n encompasses any logical execution unit capable of executing program instructions, including but not limited to a packaged integrated circuit device (such as a microprocessor), a processing core within a packaged integrated circuit device (such as a microprocessor core), or a hardware thread comprising one or more functional units within a processing core (such as an SMT thread). The processors 104₁, 104₂ . . . 104_n may be situated within a single computing device or node (e.g., as part of a single-node SMP system) or they may be distributed over plural nodes (e.g., as part of a NUMA system, a cluster, or a cloud). The memory 8 may comprise any type of tangible storage medium capable of storing data in computer readable form for use in program execution, including but not limited to, any of various types of random access memory (RAM), various flavors of programmable read-only memory (PROM) (such as flash memory), and other types of primary storage (i.e., program memory). The cache memories 110₁, 110₂ . . . 110_n may be implemented in several levels (e.g., as level 1, level 2 and level 3 caches) and the cache controllers 112₁, 112₂ . . . 112_n may collectively represent the cache controller logic that supports each cache level. As illustrated, the memory controller 114 may reside separately from processors 104₁, 104₂ . . . 104_n, for example, as part of a discrete chipset. Alternatively, the memory controller 114 could be provided by plural memory controller instances that are respectively integrated with the processors 104₁, 104₂ . . . 104_n.

Each of the processors 104₁, 104₂ . . . 104_n is operable to execute program instruction logic under the control of a software program stored in the memory 108 (or elsewhere). As part of this program execution logic, update operations (updaters) 118 will periodically execute within a process, thread, or other execution context (hereinafter “task”) on the processors 104₁, 104₂ . . . 104_n to perform hash table resizing on the hash table 116. Reference numerals 118₁, 118₂ . . . 118_n illustrate individual updaters that may execute from time to time on the various processors 104₁, 104₂ . . . 104_n. Each of the processors 104₁, 104₂ . . . 104_n also periodically executes read operations (readers) 120 on the hash table 116. Reference numerals 120₁, 120₂ . . . 120_n illustrate individual readers that may execute from time to time on the various processors 104₁, 104₂ . . . 104_n. Each search operation is assumed to entail an element-by-element traversal of a bucket (implemented as a linked list) until one or more items representing the target of the search are found. In order to support concurrent hash table operations, such search operations may be performed using a lock-free synchronization mechanism, such as read-copy update. Each search operation is assumed to entail an element-by-element traversal of a bucket (implemented as an RCU-protected linked list) until one or more items representing the target of the search are found.

To facilitate synchronized updater-reader access to the hash table 116, the several processors 104₁, 104₂ . . . 104_n are programmed to implement an RCU subsystem 122 by periodically executing respective RCU instances 122₁, 122₂ . . . 122_n as part of their operating system functions or user-mode operations. As shown in FIG. 8, each of the read-copy update subsystem instances 122 may include a reader registration component 124, a reader un-registration component 126, and a grace period detection component 128. The reader registration component 124 is used by the readers 120 when they enter an RCU-protected critical section, such as the start of a search of the hash table 116. This component may be implemented using an RCU primitive such as rcu_read_lock( ). The reader un-registration component 126 is used by the readers 120 when they leave an RCU-protected critical section, such as at the end of a search of the hash table 116. This component may be implemented using an RCU primitive such as rcu_read_unlock( ). The grace period detection component 126 may be implemented using conventional RCU processing techniques. For example, it may provide a primitive such as synchronize_rcu( ) or synchronize_rcu_expedited( ) that can be invoked by the updaters 118 to force each of the processors 104₁, 104₂ . . . 104_n to pass through a quiescent state whenever a grace period is needed. This is known as synchronous grace period detection. Other grace period detection techniques providing other semantics may also be used.

Accordingly, a technique for optimized resizing of RCU-protected hash tables has been disclosed. It will be appreciated that the foregoing concepts may be variously embodied in any of a data processing system, a machine implemented method, and a computer program product in which programming logic is provided by one or more machine-usable storage media for use in controlling a data processing system to perform the required functions. Example embodiments of a data processing system and machine implemented method were previously described in connection with FIGS. 1-6. With respect to a computer program product, digitally encoded program instructions may be stored on one or more computer-readable data storage media for use in controlling a computer or other information handling machine or device to perform the required functions. The program instructions may be embodied as machine language code that is ready for loading and execution by the machine apparatus, or the program instructions may comprise a higher level language that can be assembled, compiled or interpreted into machine language. Example languages include, but are not limited to C, C++, assembly, to name but a few. When implemented on a machine comprising a processor, the program instructions combine with the processor to provide a particular machine that operates analogously to specific logic circuits, which themselves could be used to implement the disclosed subject matter.

Example data storage media for storing such program instructions are shown by reference numerals 108 (memory) and 110 (cache) of the computer system 102 of FIG. 5. The system 102 may further include one or more secondary (or tertiary) storage devices (not shown) that could store the program instructions between system reboots. A further example of media that may be used to store the program instructions is shown by reference numeral 200 in FIG. 7. The media 200 are illustrated as being portable optical storage disks of the type that are conventionally used for commercial software sales, such as compact disk-read only memory (CD-ROM) disks, compact disk-read/write (CD-R/W) disks, and digital versatile disks (DVDs). Such media can store the program instructions either alone or in conjunction with an operating system or other software product that incorporates the required functionality. The data storage media could also be provided by portable magnetic storage media (such as floppy disks, flash memory sticks, etc.), or magnetic storage media combined with drive systems (e.g. disk drives). As is the case with the memory 108 and the cache 110 of FIG. 5, the storage media may be incorporated in data processing platforms that have integrated random access memory (RAM), read-only memory (ROM) or other semiconductor or solid state memory. More broadly, the storage media could comprise any electronic, magnetic, optical, infrared, semiconductor system or apparatus or device, or any other tangible entity representing a machine, manufacture or composition of matter that can contain, store, communicate, or transport the program instructions for use by or in connection with an instruction execution system, apparatus or device, such as a computer. For all of the above forms of storage media, when the program instructions are loaded into and executed by an instruction execution system, apparatus or device, the resultant programmed system, apparatus or device becomes a particular machine for practicing embodiments of the method(s) and system(s) described herein.

Although various example embodiments have been shown and described, it should be apparent that many variations and alternative embodiments could be implemented in accordance with the disclosure. It is understood, therefore, that the invention is not to be in any way limited except in accordance with the spirit of the appended claims and their equivalents.

Claims

1. A method for resizing an RCU [Read-Copy Update]-protected hash table in a computer system having one or more processors operatively coupled to a memory, said memory including a computer usable medium storing an RCU-protected first hash table and at least one program of instructions executable by said processor to perform hash table resizing operations representing said method, said operations comprising: allocating a second RCU-protected hash table in said memory, said second hash table representing a resized version of said first hash table that has a different number of hash buckets than said first hash table, said second hash table buckets being defined but initially having no hash table elements;populating said second hash table without copying or moving any hash table elements in memory by linking each hash bucket of said second hash table to all hash buckets of said first hash table containing elements that hash to said second hash table bucket;publishing said second hash table so that it is available for searching by hash table readers; andfreeing said first hash table from said memory after waiting for a grace period which guarantees that no readers searching said first hash table will be affected by said freeing.

2. The method in accordance with claim 1, wherein said second hash table has a size that is an integral factor of a size of said first hash table.

3. The method in accordance with claim 1, wherein said resizing comprises shrinking said first hash table and wherein (1) a hash function is selected for said second hash table so that elements of a given hash bucket of said first hash table map to a single hash bucket of said second hash table, and (2) said second hash table bucket links to a first hash bucket of said first hash table that in turn links to at least one additional hash bucket of said first hash table, such that said second hash table bucket chains through different buckets of said first hash table whose elements map to said second hash table bucket.

4. The method in accordance with claim 1, wherein said resizing comprises expanding said first hash table and wherein (1) a hash function is selected for said second hash table so that elements of a given hash bucket in said first hash table map to a predictable set of hash buckets of said second hash table, and (2) at least two hash buckets of said second hash table link to the same hash bucket of said first hash table due to said first hash table bucket containing elements that map to different hash buckets of said second hash table.

5. The method in accordance with claim 4, wherein said resizing comprises expanding said first hash table and at least two hash buckets of said second hash table are linked to the same hash bucket of said first hash table, and wherein said operations further include separating said same hash bucket of said first hash table into said at least two hash buckets of said second hash table, said separating being performed by de-linking chains of elements in said same hash bucket of said first hash table that respectively hash to different ones of said at least two hash buckets of said second hash table.

6. The method in accordance with claim 5, wherein separating includes waiting for a grace period before de-linking any two of said chains from each other, said grace period guaranteeing that no readers searching said second hash table will be affected by said de-linking.

7. A method for resizing an RCU [Read-Copy Update]-protected hash table in a computer system having one or more processors operatively coupled to a memory, said memory including a computer usable medium storing an RCU-protected first hash table and at least one program of instructions executable by said processor to perform hash table resizing operations representing said method, said operations comprising: allocating a second RCU-protected hash table in said memory, said second hash table representing a resized version of said first hash table that has a different number of hash buckets than said first hash table, said second hash table buckets being defined but initially having no hash table elements;populating said second hash table by linking each hash bucket of said second hash table to all hash buckets of said first hash table containing elements that hash to said second hash bucket;publishing said second hash table so that it is available for searching by hash table readers;freeing said first hash table from memory after waiting for a grace period which guarantees that no readers searching said first hash table will be affected by said freeing; andsaid resizing comprises either shrinking or expanding said first hash table and further wherein:if said resizing comprises shrinking said first hash table, then (1) a hash function is selected for said second hash table so that elements of a given hash bucket of said first hash table map to a single hash bucket of said second hash table, and (2) said second hash table bucket links to a first hash bucket of said first hash table that in turn links to at least one additional hash bucket of said first hash table, such that said second hash table bucket chains through different buckets of said first hash table whose elements map to said second hash table bucket;if said resizing comprises expanding said first hash table, then (1) a hash function is selected for said second hash table so that elements of a given hash bucket in said first hash table map to a predictable set of hash buckets of said second hash table, (2) at least two hash buckets of said second hash table link to the same hash bucket of said first hash table due to said first hash table bucket containing elements that map to different hash buckets of said second hash table, (3) said operations further include separating said same hash bucket of said first hash table into said at least two hash buckets of said second hash table, said separating being performed by de-linking chains of elements in said same hash bucket of said first hash table that respectively hash to different ones of said at least two hash buckets of said second hash table, and (4) said separating including waiting for a grace period before de-linking any two of said chains from each other, said grace period guaranteeing that no readers searching said second hash table will be affected by said de-linking.

8. The method in accordance with claim 7, wherein said second hash table has a size that is an integral factor of a size of said first hash table.