|Numéro de publication||US20060112121 A1|
|Type de publication||Demande|
|Numéro de demande||US 10/995,657|
|Date de publication||25 mai 2006|
|Date de dépôt||23 nov. 2004|
|Date de priorité||23 nov. 2004|
|Autre référence de publication||US7873612, US20080033952|
|Numéro de publication||10995657, 995657, US 2006/0112121 A1, US 2006/112121 A1, US 20060112121 A1, US 20060112121A1, US 2006112121 A1, US 2006112121A1, US-A1-20060112121, US-A1-2006112121, US2006/0112121A1, US2006/112121A1, US20060112121 A1, US20060112121A1, US2006112121 A1, US2006112121A1|
|Inventeurs||Paul McKenney, Orran Krieger, Dipankar Sarma, Manneesh Soni|
|Cessionnaire d'origine||Mckenney Paul E, Krieger Orran Y, Dipankar Sarma, Manneesh Soni|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Référencé par (29), Classifications (6), Événements juridiques (1)|
|Liens externes: USPTO, Cession USPTO, Espacenet|
1. Field of the Invention
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.
2. Description of the Prior Art
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 from one directory to another (referred to as a “rename” operation), its corresponding entry in the file system tree image will often move between lists. For example, in a typical directory entry cache, directory entry elements (representing files) are assigned to doubly-linked circular directory lists. Each such list is headed by a parent directory entry whose files are represented by the directory entries in the list. Relocating a file from one directory to another will cause its directory entry to move from one directory list to another. Similarly, in a directory entry hash table, directory entries are assigned to hash chains (lists) according to a hash algorithm based on their name and name of their parent directory. Directory entries will typically move from one hash chain to another whenever the file's name is changed or it is relocated to another directory.
Techniques must be used to perform these list operations without impacting readers who may be concurrently performing look-ups on the same file. Moreover, in computing environments conforming to the POSIX (Portable Operating System Interface), the list manipulations must be performed atomically. This atomicity requirement is illustrated in the context of the POSIX rename( ) system call by considering the situation where the rename( ) operation races with concurrent lookups of the old file name and the new file name. If a lookup of the new name succeeds, then every subsequent lookup of the old name must fail. Similarly, if a lookup of the old name fails, then every subsequent lookup of the new name must succeed. Note that a “subsequent” lookup must start after a preceding lookup completes. This is summarized in the following table, in which the term “failed” signifies a failure to open the file being renamed:
TABLE 1 POSIX rename( ) atomicity conditions Rename If open (“old”) failed, If open (“new”) succeeded, (“old”, “new”) Then open (“new”) Then open (“old”) must fail. must succeed
The atomicity requirements for the POSIX rename( ) system call are the same whether a file is being renamed to a new name, and when a file is being renamed on top of a pre-existing file. In the latter case, an “early” attempt to open the new filename (i.e., before the rename( ) operation returns) will fail to open the renamed file, but will instead open the pre-existing file. This race condition is in all ways equivalent to the race condition where the file is being renamed to a new name. Therefore, for simplicity, the ensuing discussion will consider only the case where a file is renamed to a new name.
There are a number of prior-art algorithms that permit atomic rename( ) operations by relying on locks held during the lookup operations. This is undesirable because directory cache lookups are extremely common, and such operations should be lock-free if possible. There are also lock-free synchronization techniques that provide the desired semantics, and avoid locking in the lookups. 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.
Another mutual exclusion technique, known as read-copy update, permits shared data to be accessed for reading without the use of locks, writes to shared memory, memory barriers, atomic instructions, or other computationally expensive synchronization mechanisms, while still permitting the data to be updated concurrently. The technique is well suited to multiprocessor computing environments in which the number of read operations (readers) accessing a shared data set is large in comparison to the number of update operations (updaters), and wherein the overhead cost of employing other mutual exclusion techniques (such as locks) for each read operation would be high.
The read-copy update technique implements data updates in two phases. In the first (initial update) phase, the actual data update is carried out in a manner that temporarily preserves two views of the data being updated. One view is the old (pre-update) data state that is maintained for the benefit of operations that may be currently referencing the data. The other view is the new (post-update) data state that is available for the benefit of operations that access the data following the update. In the second (deferred update) phase, the old data state is removed following a “grace period” that is long enough to ensure that all executing operations will no longer maintain references to the pre-update data.
Traditional read-copy-update manipulation of list data leaves the old data element in place in the list, creates a new copy with the desired modifications, and then atomically inserts the new copy in place of the old element into the same list. This is impractical for the POSIX rename( ) operation. Here, the old element must be atomically removed and a new element inserted, not necessarily in the same place that the old one occupied, but likely into a different list. 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.
A possible work-around would be to have read-copy update atomically update an entire file system tree data structure, and atomically replace it with a new one by switching pointers. 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. As stated, it is not unusual for even small desktop machines to cache more than 100,000 such 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. If the POSIX rename( ) operation is not performed atomically, there will be a short but non-zero duration when the renamed directory entry will not be on any list. This time duration can be expanded by interrupts, ECC (Error Correction Code) errors in memory or caches, or by many other events that can occur in current microprocessors and operating systems. In a multiprocessor system, it is possible that some other process might be able to perform a lookup on the new name followed by the old name during this time interval and observe both failing, thus violating the required POSIX semantics as shown in the second column of Table 1.
Accordingly, a need exists for an efficient lock-free technique for atomically moving shared list elements from one list to another. It would be particularly desirable to provide a solution to the foregoing problem using existing aspects of the conventional read-copy update technique but with modifications thereto to facilitate inter-list movement of list elements with the required atomicity.
The foregoing problems are solved and an advance in the art is obtained by a method, system and computer program product for atomically moving a shared list element from a first list location to a second list location while permitting lock-free concurrent lookup operations. To perform the atomic move operation, a placeholder element is inserted at the second list location to signify to readers that a move operation is underway, and the shared list element is removed from the first list location. The shared list element is then re-identified to reflect its move from the first list location to the second list location. It is inserted at the second list location and the placeholder element is unlinked. A deferred removal of the placeholder element is performed following a period in which readers can no longer maintain references to the placeholder element. Readers that were waiting on the placeholder element will fail and presumably be retried, at which point the shared list element will be found at its new location.
In exemplary embodiments of the invention, the placeholder element includes a flag that indicates when the move operation has completed, and readers performing lookups use a mechanism, such as a semaphore, an event queue, or a wait queue, to wait until the flag signifies completion before returning. The placeholder element further includes a reference count representing a count of readers maintaining references to the placeholder element (and thus waiting for completion of the move operation). This reference count is used in conjunction with read-copy update to defer release of the placeholder element until all readers have completed processing thereof.
The shared list element is not limited to any particular type of data, but one of its uses is in a doubly-linked circular list of directory entries in a file system directory entry cache. The shared list element could also be a member of a directory entry hash table chain. In both cases, the move operation can be part of a file rename( ) operation. A further example of the shared list element would be an individual row element in a relational database tuple. Many other list environments would likewise be candidates for implementation of the present invention.
A method, system and computer program product are additionally provided for performing a lookup of a shared list element that is subject to being atomically moved from a first list to a second list. The lookup initiates a list traversal beginning at a first list element. Upon encountering a list element that is the target of the lookup, the lookup returns success. Upon encountering a list element that is a placeholder for the lookup target that was generated as a result of a concurrent move operation involving the target, the lookup waits until the placeholder indicates that the move operation has completed.
When this occurs, the lookup returns failure so that the lookup can be retried. Upon the target list element or the placeholder not being found in the list, the lookup returns failure.
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, returning to the initial list being traversed. The lookup increments a reference count in the placeholder upon encountering the placeholder and decrements the reference count if the placeholder indicates that the concurrent move operation has competed. When waiting on the placeholder, the lookup can block on a global or per-element semaphore, or spin (busy wait) on a global or per-element lock.
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of exemplary embodiments of the invention, as illustrated in the accompanying Drawings, in which:
Before discussing the details of the invention in its exemplary embodiments, it will be helpful to consider several examples illustrating the manner in which conventional read-copy update can be used to update list elements.
It is assumed that the data element list of
At some subsequent time following the update, r1 will have continued its traversal of the linked list and moved its reference off of B. In addition, there will be a time at which no other reader process is entitled to access B. It is at this point, representing expiration of a grace period, that u1 can free B, as shown in
In the context of traditional read-copy update, a grace period represents the point at which all running processes having access to a data element guarded by read-copy update have passed through a “quiescent state” in which they can no longer maintain references to the data element, assert locks thereon, or make any assumptions about data element state. For many types of shared data, a context (process) switch, an idle loop, and user mode execution all represent quiescent states for any given CPU (as can other operations that will not be listed here).
There are various methods that may be used to implement a deferred data update following a grace period, including but not limited to the use of callback processing as described in commonly assigned U.S. Pat. No. 5,727,209, entitled “Apparatus And Method For Achieving Reduced Overhead Mutual-Exclusion And Maintaining Coherency In A Multiprocessor System Utilizing Execution History And Thread Monitoring.” The contents of U.S. Pat. No. 5,727,209 are hereby incorporated herein by this reference.
The callback processing technique contemplates that an updater of a shared data element will perform the initial (first phase) data update operation that creates the new view of the data being updated, and then specify a callback function for performing the deferred (second phase) data update operation that removes the old view of the data being updated. The updater will register the callback function (hereinafter referred to as a callback) with a read-copy update subsystem so that it can be executed at the end of the grace period. The read-copy update subsystem keeps track of pending callbacks for each processor and monitors per-processor quiescent state activity in order to detect when a current grace period has expired. When it does, all scheduled callbacks that are ripe for processing are executed.
The present invention represents an extension of the read-copy update mutual exclusion technique wherein, instead of replacing an old list element with a new one, the old element is atomically moved to a new list location so that the references to this element need not be changed. The invention achieves this effect by inserting a temporary placeholder element, referred to as a “birthstone,” at the destination location where the real list element is to be moved. Lookups finding the birthstone will wait until the move operation is complete before returning failure. The birthstone element is maintained until it is replaced by the actual element being moved. At this point, the birthstone is marked “complete.” Readers waiting on the birthstone “complete” state will then fail but a retry of the lookup will be attempted and the actual element will be successfully found at its new location. It is thus guaranteed that any lookup that fails to find the old element will subsequently find the new one, consistent with POSIX requirements, after the element is inserted into its new location (e.g., a new directory list or a new hash chain, depending on the implementation). As described in more detail below, reference counts and read-copy update are used to guarantee that concurrent lookups see valid state information at all points.
Turning now to
It is further assumed that update operations executed within processes, threads, or other execution contexts will periodically perform updates on a shared set of linked lists 16 stored in the shared memory 8. By way of example only, the shared list set 16 could be a directory entry cache or hash table and the lists thereof could contain file system directory entry elements. It will be appreciated that the invention may also be used in connection with many other types of lists. Reference numerals 18 1, 18 2 . . . 18 n illustrate individual data update operations (updaters) that may periodically execute on the several processors 4 1, 4 2 . . . 4 n. In the present case, the updates performed by the updaters 18 1, 18 2 . . . 18 n involve moving a list element from one list to another, such as could occur if a directory entry element is renamed and moved between lists in a directory entry cache or hash table. In that case, the renaming of an element would in many cases cause it to hash to a different hash chain. To facilitate such updates, the several processors 4 1, 4 2 . . . 4 n are programmed to implement a read-copy update (RCU) subsystem 20, as by periodically executing respective read-copy update instances 20 1, 20 2 . . . 20 n as part of their operating system functions.
The processors 4 1, 4 2 . . . 4 n also execute readers 22 1, 22 2 . . . 22 n that perform lookup operations on the shared list set 16. Each lookup operation is assumed to entail an element-by-element traversal of a linked list until an element which is the target of the lookup is found. If the shared list set 16 is a directory entry cache or hash table, the linked list being traversed will be selected according to the name and parent directory of the lookup target. Such lookup operations will typically be performed far more often than updates, thus satisfying one of the premises underlying the use of read-copy update.
As shown in
Overview Of Atomic Move of List Element Between Lists Using Read-Copy Update
As mentioned above, the present invention applies read-copy update to the situation where a list element needs to be moved from one list to another. This is done by inserting a “birthstone” into the element's new location, which is later replaced with the actual element being moved. If a reader 22 1, 22 2 . . . 22 n performing a lookup sees the birthstone, it waits for the move operation to complete before failing.
In step 32 of
It is possible as a result of step 34 that lookups for another element in the list L1, such as element J, will have been carried with element B to the list L2. That is, lookups can be “pulled” to a different list by moving a list element that is currently being consulted as part of a list traversal sequence at the time of the move. For example, if list L1 is being traversed during a lookup of element J, and the lookup is referencing element B at the same time element B is moved to list L2, the lookup for element J can be pulled to L2. This race condition can be resolved by maintaining a back pointer (not shown) from each list element to the corresponding list header element, then restarting the search if the wrong back pointer is encountered (see lookup technique below for further details). Thus, a simple check can detect and recover from this possible race.
In step 36 of
Lookup Technique for Use With Atomic Move of List Element Between Lists
Any reader 22 1, 22 1 . . . 22 n performing lookups on list elements that may be concurrently moved between lists during the lookup operation must be adapted to correctly handle this situation.
Another way to prevent indefinite looping during lookups is to have the updater 18 2 . . . 18 n, when manipulating an element, check to see if the element will end up in the same list that it started in. If so, the updater 18 2 . . . 18 n can insert a birthstone before the element rather than replacing it. This guarantees that a move cannot cause a lookup to visit more entries than it would otherwise have to see. However, for this to work, an element that has been moved cannot be moved again until all in-flight lookups complete. Otherwise, lookups could be recycled by renaming an element back and forth between two lists. As described above, this can be guaranteed by having the updater 18 2 . . . 18 n refuse to move a recently moved element until after a grace period has elapsed since its previous move.
If a count procedure is to be used per steps 46 and 48 of
No matter which maximum count computation technique is used, the readers 22 1, 22 1 . . . 22 n should always be sensitive to excessively locking out move operations. Thus, the count function should be adjusted to choose a desired tradeoff between readers 22 1, 22 1 . . . 22 n potentially having to traverse large numbers of list elements and updaters 18 1, 18 2 . . . 18 n performing move operations being needlessly locked out.
In step 50 of
As indicated, there are a number of ways a reader 22 1, 22 2 . . . 22 n can wait for a move operation to complete. Each has different advantages in different situations. For example, one technique would be to have the lookups block (sleep) on a global semaphore (sometimes referred to as a “sleeplock”). This minimizes memory use, because there is only one semaphore. However, it can result in needless wakeups when there are multiple moves executing in parallel. It also causes the system to incur the overhead of an additional context switch each time a lookup encounters a birthstone. Another alternative would be to have lookups block on a per-element semaphore. This requires additional memory, but eliminates the needless wakeups. It still incurs the context-switch overhead. A further alternative would be to have the lookups spin (busy wait) on a global lock. This, although possible, is almost always undesirable due to the potential lock contention overhead. A still further alternative would be to have lookups spin on a per-element lock. This likely requires no additional memory, and this method is preferred as long as the move operation does not block and is likely to complete quickly.
Atomic Rename( ) Using Read-Copy Update
The atomic POSIX rename( ) problem described by way of background above can be solved using the above-described technique to insert a “birthstone” at the destination of a file system directory entry to be renamed. As per the discussion above, when a lookup operation encounters a birthstone that matches the lookup target, it blocks until the birthstone is marked “completed”, and then fails (and is presumably then retried). This ensures that any operation that fails to see the old file name will see the new file name on any subsequent lookup, and also ensure that any operation that sees the new file name will fail to see the old file name, as required by POSIX semantics.
As shown in
The rename( ) operation is implemented according to the generalized atomic move procedure described above, with the target list element being a file system directory entry and the list being a doubly-linked circular directory list in a directory entry cache or a hash chain in a directory entry hash table. As is known, the rename( ) operation can be used to change a file's name without moving it to a different directory, or it can move the file to a different directory without changing its name, or it can both rename the file and move it to a different directory. Because of the way lists are implemented in a directory entry cache or hash table, the rename( ) operation usually results in a directory entry element being moved from one list to another. Of course, if the rename( ) operation results in the directory entry element remaining on the same list, the birthstone procedure described herein may not be necessary. If the element name can be renamed atomically, then such an operation can be used. Lookups will see either the old name or the new name.
Assuming that a birthstone is required, it will typically have the same name, hash, hash chain, child, and parent as the element will have after being renamed, but with the requisite indication (e.g., a flag value, bit or other parameter) in the “flags” field of
When using the generalized atomic move operation of
Special Handling for Global Hash Table
As mentioned above, the re-identification step 34 of
For best results in this situation when there is a global hash table, the name and parent pointer of each directory entry element should be changed atomically. Although it is possible to change them one at a time, doing so makes lookups considerably more complex. This atomic update may be accomplished by placing the parent directory pointer into a structure that also contains the element's name, so that the “name” field of the element points to both of them (and so that the “parent” field is not required).
However, if the parent pointer is frequently referenced, this might have unacceptable performance consequences. In this case, it may be better to keep the “name” and “parent” fields, and also provide a special pointer in each element that is normally NULL, but, when non-NULL, points to a special structure containing both the parent pointer and the name. In some cases, this structure can simply be another list element.
It will be appreciated that the special-pointer approach should provide some way of propagating the atomic update to the special name/parent pointer structure back to the parent and name stored in the main element containing the pointer. This can be accomplished by registering a callback to invoke a function (after a grace period elapses) that does the following:
If a directory entry's name is stored directly in the list element (and not as a pointer), it cannot be changed atomically. Therefore, the new name must be placed in separate storage as a long name would be, even if the new name is short enough to fit into the list element. This allows the name to be changed atomically. When it is desirable to move the short name back into the list element, a callback can be registered to invoke a function (after a grace period elapses) that does the following:
In cases where a directory cache or hash table is subject to the above-described rename( ) operation, the lookup procedure described above in connection with
Accordingly, a technique has been disclosed for atomically moving list elements from one list to another using read-copy update. 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 means are recorded on one or more data storage media for use in controlling a data processing system to perform the required functions. Exemplary data storage media for storing such programming means are shown by reference numeral 100 in
While various embodiments of the invention have been described, it should be apparent that many variations and alternative embodiments could be implemented in accordance with the invention. 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.
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|US7664323 *||28 janv. 2005||16 févr. 2010||Microsoft Corporation||Scalable hash-based character recognition|
|US7668851 *||29 nov. 2006||23 févr. 2010||International Business Machines Corporation||Lockless hash table lookups while performing key update on hash table element|
|US7953708||28 juil. 2008||31 mai 2011||International Business Machines Corporation||Optimizing grace period detection for preemptible read-copy update on uniprocessor systems|
|US7953778||20 mai 2008||31 mai 2011||International Business Machines Corporation||Efficient support of consistent cyclic search with read-copy update and parallel updates|
|US8020160||28 juil. 2008||13 sept. 2011||International Business Machines Corporation||User-level read-copy update that does not require disabling preemption or signal handling|
|US8055860 *||27 janv. 2008||8 nov. 2011||International Business Machines Corporation||Read-copy-update (RCU) operations with reduced memory barrier usage|
|US8055918||3 avr. 2008||8 nov. 2011||International Business Machines Corporation||Optimizing preemptible read-copy update for low-power usage by avoiding unnecessary wakeups|
|US8108696||24 juil. 2008||31 janv. 2012||International Business Machines Corporation||Optimizing non-preemptible read-copy update for low-power usage by avoiding unnecessary wakeups|
|US8185704||2 sept. 2009||22 mai 2012||International Business Machines Corporation||High performance real-time read-copy update|
|US8195893||3 nov. 2008||5 juin 2012||International Business Machines Corporation||Eliminating synchronous grace period detection for non-preemptible read-copy update on uniprocessor systems|
|US8307173||13 févr. 2012||6 nov. 2012||International Business Machines Corporation||High performance real-time read-copy update|
|US8407503||27 sept. 2010||26 mars 2013||International Business Machines Corporation||Making read-copy update free-running grace period counters safe against lengthy low power state sojourns|
|US8495641||29 juin 2007||23 juil. 2013||International Business Machines Corporation||Efficiently boosting priority of read-copy update readers while resolving races with exiting and unlocking processes|
|US8615771||20 juin 2011||24 déc. 2013||International Business Machines Corporation||Effective management of blocked-tasks in preemptible read-copy update|
|US8661005||8 déc. 2011||25 févr. 2014||International Business Machines Corporation||Optimized deletion and insertion for high-performance resizable RCU-protected hash tables|
|US8666952||25 avr. 2012||4 mars 2014||International Business Machines Corporation||Optimized deletion and insertion for high-performance resizable RCU-protected hash tables|
|US8706706||13 sept. 2007||22 avr. 2014||International Business Machines Corporation||Fast path for grace-period detection for read-copy update system|
|US8869166||2 avr. 2012||21 oct. 2014||International Business Machines Corporation||Effective management of blocked-tasks in preemptible read-copy update|
|US8874535||16 oct. 2012||28 oct. 2014||International Business Machines Corporation||Performance of RCU-based searches and updates of cyclic data structures|
|US8924655||4 févr. 2013||30 déc. 2014||International Business Machines Corporation||In-kernel SRCU implementation with reduced OS jitter|
|US8938631||30 juin 2012||20 janv. 2015||International Business Machines Corporation||Energy efficient implementation of read-copy update for light workloads running on systems with many processors|
|US8972801||4 févr. 2013||3 mars 2015||International Business Machines Corporation||Motivating lazy RCU callbacks under out-of-memory conditions|
|US8997110||30 nov. 2013||31 mars 2015||International Business Machines Corporation||Resolving RCU-scheduler deadlocks|
|US9003420||18 mai 2012||7 avr. 2015||International Business Machines Corporation||Resolving RCU-scheduler deadlocks|
|US9009122||8 déc. 2011||14 avr. 2015||International Business Machines Corporation||Optimized resizing for RCU-protected hash tables|
|US9015133||25 avr. 2012||21 avr. 2015||International Business Machines Corporation||Optimized resizing for RCU-protected hash tables|
|US9081803 *||22 févr. 2013||14 juil. 2015||International Business Machines Corporation||Performance of RCU-based searches and updates of cyclic data structures|
|US20110321005 *||29 déc. 2011||Antonio Lain||Compaction and de-allocation of partial objects through scheduling a transaction|
|US20140108366 *||22 févr. 2013||17 avr. 2014||International Business Machines Corporation||Performance Of RCU-Based Searches And Updates Of Cyclic Data Structures|
|Classification aux États-Unis||1/1, 707/E17.011, 707/999.101|
|7 avr. 2005||AS||Assignment|
Owner name: INTERNAITONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAYLOR, PAUL S.;GERBER, ROBERT;REEL/FRAME:016031/0991;SIGNING DATES FROM 20041029 TO 20041110