Atomically moving list elements between lists using read-copy update

Abstract

A system, method and computer program product for atomically moving a shared list element from a first list location to a second list location includes inserting a placeholder element at the second list location to signify to readers that a move operation is underway, removing the shared list element from the first list location, re-identifying the list element to reflect its move from the first list location to the second list location, inserting it at the second list location and unlinking the placeholder element. A deferred removal of the placeholder element is performed following a period in which readers can no longer maintain references thereto. A method, system and computer program product are additionally provided for performing a lookup of a target list element that is subject to being atomically moved from a first list to a second list.

Description

BACKGROUND OF THE INVENTION [0001] 1. Field of the Invention [0002] The present invention relates to computer systems and methods in which list data are shared by software running concurrently on one or more processors. More particularly, the invention concerns an improved system and method that allows lock-free lookups of list elements while efficiently permitting concurrent update operations in which list elements are moved from one list to another. [0003] 2. Description of the Prior Art [0004] By way of background, shared data elements that are members of a linked list sometimes need to be moved from one list to another while maintaining consistency for the benefit of data consumers who may be concurrently performing lookups on the same data. This situation arises in the context of in-memory file system tree images used by operating systems to perform file name lookups for locating files maintained on block storage devices. When a file's name is changed and / or the file is moved f...

AI Technical Summary

Benefits of technology

[0019] In exemplary embodiments of the invention, the lookup further includes maintaining a count of elements traversed by the lookup and asserting a lock against concurrent move operations if the count reaches a computed maximum. The lookup may additionally include determining whether the lookup has been pulled from one list to another as a result of a concurrent move, and if true, retur

Problems solved by technology

If a lookup of the new name succeeds, then every subsequent lookup of the old name must fail.

This is undesirable because directory cache lookups are extremely common, and such operations should be lock-free if possible.

However, these rename( ) operations are extremely costly, requiring duplication of the entire data structure (which for a hash table can contain hundreds of thousands of elements, even on small desktop systems).

Furthermore, even though the lookups are lock-free, they use atomic operations that perform write operations, thereby inflicting costly cache misses on lookups running in other processors.

This is impractical for the POSIX rename( ) operation.

File system operations further complexify traditional read-copy update due to the existence of long-lived references to the old list element (directory entry representing the file) that is to be removed following a grace period.

It is often difficult or even infeasible to determine where these references are located, because many different parts of an operating system kernel or of dynamically loaded kernel modules might at any time acquire a reference to the list element.

Thus, there is no effective method for tracking down all the possible references to the old element.

However, as in the case of lock-free synchronization, this latter approach is hopelessly inefficient for directories containing large numbers of files, and is even less well suited to systems that maintain a hash table to cache filename / directory mappings.

Making a new duplicate copy of this table for each rename( ) operation is clearly undesirable.

Another alternative, creating a copy of a single hash chain is not feasible because the rename( ) operation will normally move a directory entry to some other hash chain.

It is also not possible to atomically create a copy of only the affected pair of hash chains with the instructions available on commodity microprocessors.

In sum, given current commodity microprocessor instruction sets, along with the undesirability of duplicating large list structures, it is not practical to atomically move an element from one list to another using traditional read-copy update techniques.

Images