Edit Script¶

The insertion and deletion functions produce an ‘edit script’ that can later beapplied to effect the changes without riskingENOMEM. This retains thepreallocated metadata blocks that will be installed in the internal tree andkeeps track of the metadata blocks that will be removed from the tree when thescript is applied.

This is also used to keep track of dead blocks and dead objects after thescript has been applied so that they can be freed later. The freeing is doneafter an RCU grace period has passed - thus allowing access functions toproceed under the RCU read lock.

The script appears as outside of the API as a pointer of the type:

struct assoc_array_edit;

There are two functions for dealing with the script:

1. Apply an edit script:

   void assoc_array_apply_edit(struct assoc_array_edit *edit);

This will perform the edit functions, interpolating various write barriersto permit accesses under the RCU read lock to continue. The edit scriptwill then be passed tocall_rcu() to free it and any dead stuff it pointsto.

2. Cancel an edit script:

   void assoc_array_cancel_edit(struct assoc_array_edit *edit);

This frees the edit script and all preallocated memory immediately. Ifthis was for insertion, the new object is _not_ released by this function,but must rather be released by the caller.

These functions are guaranteed not to fail.

Operations Table¶

Various functions take a table of operations:

struct assoc_array_ops {        ...};

This points to a number of methods, all of which need to be provided:

1. Get a chunk of index key from caller data:

   unsigned long (*get_key_chunk)(const void *index_key, int level);

This should return a chunk of caller-supplied index key starting at thebit position given by the level argument. The level argument will be amultiple ofASSOC_ARRAY_KEY_CHUNK_SIZE and the function should returnASSOC_ARRAY_KEY_CHUNK_SIZEbits. No error is possible.

2. Get a chunk of an object’s index key:

   unsigned long (*get_object_key_chunk)(const void *object, int level);

As the previous function, but gets its data from an object in the arrayrather than from a caller-supplied index key.

3. See if this is the object we’re looking for:

   bool (*compare_object)(const void *object, const void *index_key);

Compare the object against an index key and returntrue if it matches andfalse if it doesn’t.

4. Diff the index keys of two objects:

   int (*diff_objects)(const void *object, const void *index_key);

Return the bit position at which the index key of the specified objectdiffers from the given index key or -1 if they are the same.

5. Free an object:

   void (*free_object)(void *object);

Free the specified object. Note that this may be called an RCU grace periodafterassoc_array_apply_edit() was called, sosynchronize_rcu() may benecessary on module unloading.

Manipulation Functions¶

There are a number of functions for manipulating an associative array:

1. Initialise an associative array:

   void assoc_array_init(struct assoc_array *array);

This initialises the base structure for an associative array. It can’t fail.

2. Insert/replace an object in an associative array:

   struct assoc_array_edit *assoc_array_insert(struct assoc_array *array,                   const struct assoc_array_ops *ops,                   const void *index_key,                   void *object);

This inserts the given object into the array. Note that the leastsignificant bit of the pointer must be zero as it’s used to type-markpointers internally.

If an object already exists for that key then it will be replaced with thenew object and the old one will be freed automatically.

Theindex_key argument should hold index key information and ispassed to the methods in the ops table when they are called.

This function makes no alteration to the array itself, but rather returnsan edit script that must be applied.-ENOMEM is returned in the case ofan out-of-memory error.

The caller should lock exclusively against other modifiers of the array.

3. Delete an object from an associative array:

   struct assoc_array_edit *assoc_array_delete(struct assoc_array *array,                   const struct assoc_array_ops *ops,                   const void *index_key);

This deletes an object that matches the specified data from the array.

Theindex_key argument should hold index key information and ispassed to the methods in the ops table when they are called.

This function makes no alteration to the array itself, but rather returnsan edit script that must be applied.-ENOMEM is returned in the case ofan out-of-memory error.NULL will be returned if the specified object isnot found within the array.

The caller should lock exclusively against other modifiers of the array.

4. Delete all objects from an associative array:

   struct assoc_array_edit *assoc_array_clear(struct assoc_array *array,                  const struct assoc_array_ops *ops);

This deletes all the objects from an associative array and leaves itcompletely empty.

This function makes no alteration to the array itself, but rather returnsan edit script that must be applied.-ENOMEM is returned in the case ofan out-of-memory error.

The caller should lock exclusively against other modifiers of the array.

5. Destroy an associative array, deleting all objects:

   void assoc_array_destroy(struct assoc_array *array,                         const struct assoc_array_ops *ops);

This destroys the contents of the associative array and leaves itcompletely empty. It is not permitted for another thread to be traversingthe array under the RCU read lock at the same time as this function isdestroying it as no RCU deferral is performed on memory release -something that would require memory to be allocated.

The caller should lock exclusively against other modifiers and accessorsof the array.

6. Garbage collect an associative array:

   int assoc_array_gc(struct assoc_array *array,                   const struct assoc_array_ops *ops,                   bool (*iterator)(void *object, void *iterator_data),                   void *iterator_data);

This iterates over the objects in an associative array and passes each one toiterator(). Ifiterator() returnstrue, the object is kept. If itreturnsfalse, the object will be freed. If theiterator() functionreturnstrue, it must perform any appropriate refcount incrementing on theobject before returning.

The internal tree will be packed down if possible as part of the iterationto reduce the number of nodes in it.

Theiterator_data is passed directly toiterator() and is otherwiseignored by the function.

The function will return0 if successful and-ENOMEM if there wasn’tenough memory.

It is possible for other threads to iterate over or search the array underthe RCU read lock while this function is in progress. The caller shouldlock exclusively against other modifiers of the array.

Access Functions¶

There are two functions for accessing an associative array:

1. Iterate over all the objects in an associative array:

   int assoc_array_iterate(const struct assoc_array *array,                        int (*iterator)(const void *object,                                        void *iterator_data),                        void *iterator_data);

This passes each object in the array to the iterator callback function.iterator_data is private data for that function.

This may be used on an array at the same time as the array is beingmodified, provided the RCU read lock is held. Under such circumstances,it is possible for the iteration function to see some objects twice. Ifthis is a problem, then modification should be locked against. Theiteration algorithm should not, however, miss any objects.

The function will return0 if no objects were in the array or else it willreturn the result of the last iterator function called. Iteration stopsimmediately if any call to the iteration function results in a non-zeroreturn.

2. Find an object in an associative array:

   void *assoc_array_find(const struct assoc_array *array,                       const struct assoc_array_ops *ops,                       const void *index_key);

This walks through the array’s internal tree directly to the objectspecified by the index key..

This may be used on an array at the same time as the array is beingmodified, provided the RCU read lock is held.

The function will return the object if found (and set*_type to the objecttype) or will returnNULL if the object was not found.

Index Key Form¶

The index key can be of any form, but since the algorithms aren’t told how longthe key is, it is strongly recommended that the index key includes its lengthvery early on before any variation due to the length would have an effect oncomparisons.

This will cause leaves with different length keys to scatter away from eachother - and those with the same length keys to cluster together.

It is also recommended that the index key begin with a hash of the rest of thekey to maximise scattering throughout keyspace.

The better the scattering, the wider and lower the internal tree will be.

Poor scattering isn’t too much of a problem as there are shortcuts and nodescan contain mixtures of leaves and metadata pointers.

The index key is read in chunks of machine word. Each chunk is subdivided intoone nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels andon a 64-bit CPU, 16 levels. Unless the scattering is really poor, it isunlikely that more than one word of any particular index key will have to beused.

Basic Internal Tree Layout¶

Ignoring shortcuts for the moment, the nodes form a multilevel tree. The indexkey space is strictly subdivided by the nodes in the tree and nodes occur onfixed levels. For example:

Level: 0               1               2               3       =============== =============== =============== ===============                                                       NODE D                       NODE B          NODE C  +------>+---+               +------>+---+   +------>+---+   |       | 0 |       NODE A  |       | 0 |   |       | 0 |   |       +---+       +---+   |       +---+   |       +---+   |       :   :       | 0 |   |       :   :   |       :   :   |       +---+       +---+   |       +---+   |       +---+   |       | f |       | 1 |---+       | 3 |---+       | 7 |---+       +---+       +---+           +---+           +---+       :   :           :   :           | 8 |---+       +---+           +---+           +---+   |       NODE E       | e |---+       | f |           :   :   +------>+---+       +---+   |       +---+           +---+           | 0 |       | f |   |                       | f |           +---+       +---+   |                       +---+           :   :               |       NODE F                          +---+               +------>+---+                           | f |                       | 0 |           NODE G          +---+                       +---+   +------>+---+                       :   :   |       | 0 |                       +---+   |       +---+                       | 6 |---+       :   :                       +---+           +---+                       :   :           | f |                       +---+           +---+                       | f |                       +---+

In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).Assuming no other meta data nodes in the tree, the key space is dividedthusly:

KEY PREFIX      NODE==========      ====137*            D138*            E13[0-69-f]*     C1[0-24-f]*      Be6*             Ge[0-57-f]*      F[02-df]*        A

So, for instance, keys with the following example index keys will be found inthe appropriate nodes:

INDEX KEY       PREFIX  NODE=============== ======= ====13694892892489  13      C13795289025897  137     D13889dde88793   138     E138bbb89003093  138     E1394879524789   12      C1458952489      1       B9431809de993ba  -       Ab4542910809cd   -       Ae5284310def98   e       Fe68428974237    e6      Ge7fffcbd443     e       Ff3842239082     -       A

To save memory, if a node can hold all the leaves in its portion of keyspace,then the node will have all those leaves in it and will not have any metadatapointers - even if some of those leaves would like to be in the same slot.

A node can contain a heterogeneous mix of leaves and metadata pointers.Metadata pointers must be in the slots that match their subdivisions of keyspace. The leaves can be in any slot not occupied by a metadata pointer. Itis guaranteed that none of the leaves in a node will match a slot occupied by ametadata pointer. If the metadata pointer is there, any leaf whose key matchesthe metadata key prefix must be in the subtree that the metadata pointer pointsto.

In the above example list of index keys, node A will contain:

SLOT    CONTENT         INDEX KEY (PREFIX)====    =============== ==================1       PTR TO NODE B   1*any     LEAF            9431809de993baany     LEAF            b4542910809cde       PTR TO NODE F   e*any     LEAF            f3842239082

and node B:

3   PTR TO NODE C   13*any LEAF            1458952489

Shortcuts¶

Shortcuts are metadata records that jump over a piece of keyspace. A shortcutis a replacement for a series of single-occupancy nodes ascending through thelevels. Shortcuts exist to save memory and to speed up traversal.

It is possible for the root of the tree to be a shortcut - say, for example,the tree contains at least 17 nodes all with key prefix1111. Theinsertion algorithm will insert a shortcut to skip over the1111 keyspacein a single bound and get to the fourth level where these actually becomedifferent.

Splitting And Collapsing Nodes¶

Each node has a maximum capacity of 16 leaves and metadata pointers. If theinsertion algorithm finds that it is trying to insert a 17th object into anode, that node will be split such that at least two leaves that have a commonkey segment at that level end up in a separate node rooted on that slot forthat common key segment.

If the leaves in a full node and the leaf that is being inserted aresufficiently similar, then a shortcut will be inserted into the tree.

When the number of objects in the subtree rooted at a node falls to 16 orfewer, then the subtree will be collapsed down to a single node - and this willripple towards the root if possible.

Non-Recursive Iteration¶

Each node and shortcut contains a back pointer to its parent and the number ofslot in that parent that points to it. None-recursive iteration uses these toproceed rootwards through the tree, going to the parent node, slot N + 1 tomake sure progress is made without the need for a stack.

The backpointers, however, make simultaneous alteration and iteration tricky.

Simultaneous Alteration And Iteration¶

There are a number of cases to consider:

1. Simple insert/replace. This involves simply replacing a NULL or oldmatching leaf pointer with the pointer to the new leaf after a barrier.The metadata blocks don’t change otherwise. An old leaf won’t be freeduntil after the RCU grace period.

2. Simple delete. This involves just clearing an old matching leaf. Themetadata blocks don’t change otherwise. The old leaf won’t be freed untilafter the RCU grace period.

3. Insertion replacing part of a subtree that we haven’t yet entered. Thismay involve replacement of part of that subtree - but that won’t affectthe iteration as we won’t have reached the pointer to it yet and theancestry blocks are not replaced (the layout of those does not change).

4. Insertion replacing nodes that we’re actively processing. This isn’t aproblem as we’ve passed the anchoring pointer and won’t switch onto thenew layout until we follow the back pointers - at which point we’vealready examined the leaves in the replaced node (we iterate over all theleaves in a node before following any of its metadata pointers).

   We might, however, re-see some leaves that have been split out into a newbranch that’s in a slot further along than we were at.

5. Insertion replacing nodes that we’re processing a dependent branch of.This won’t affect us until we follow the back pointers. Similar to (4).

6. Deletion collapsing a branch under us. This doesn’t affect us because theback pointers will get us back to the parent of the new node before wecould see the new node. The entire collapsed subtree is thrown awayunchanged - and will still be rooted on the same slot, so we shouldn’tprocess it a second time as we’ll go back to slot + 1.

Obsolete blocks and leaves are freed up after an RCU grace period has passed,so as long as anyone doing walking or iteration holds the RCU read lock, theold superstructure should not go away on them.