Inserting into B+ tree using locks

Question

I am trying to figure out how to insert an item into a B+ tree using locks and don't really understand the theory behind it.

So for searching, my view is that I put a lock on the root node, and then decide which child node I should go to and lock it, at this point I can release the parent node and continue this operation until I reach the leaf node.

But inserting is a lot more complicated because I can't allow any other threads to interfere with the insertion. My idea is put a lock on each node along the path to the leaf node but putting that many locks is quite expensive, and then the question I have is what happens when the leaf node splits because it is too large?

Does anyone know how to properly insert an item into a B+ tree using locks?

Answer 1

There are many different strategies for dealing with locking in B-Trees in general; most of these actually deal with B+Trees and its variations since they have been dominating the field for decades. Summarising these strategies would be tantamount to summarising the progress of four decades; it's virtually impossible. Here are some highlights.

One strategy for minimising the amount of locking during initial descent is to lock not the whole path starting from the root, but only the sub-path beginning at the last 'stable' node (ie a node that won't split or merge as a result of the currently planned operation).

Another strategy is to assume that no split or merge will happen, which is true most of the time anyway. This means the descent can be done by locking only the current node and the child node one will descend into next, then release the lock on the previously 'current' node and so on. If it turns out that a split or merge is necessary after all then re-descend from the root under a heavier locking regime (ie path rooted at last stable node).

Another staple in the bag of tricks is to ensure that each node 'descended through' is stable by preventative splitting/merging; that is, when the current node would split or merge under a change bubbling up from below then it gets split/merged right away before continuing the descent. This can simplify operations (including locking) and it is somewhat popular in reinventions of the wheel - homework assignments and 'me too' implementations, rather than sophisticated production-grade systems.

Some strategies allow most normal operations to be performed without any locking at all but usually they require that the standard B+Tree structure be slightly modified; see B-link trees for example. This means that different concurrent threads operating on the tree can 'see' different physical views of this tree - depending on when they got where and followed which link - but they all see the same logical view.

Seminal papers and good overviews:

• Efficient Locking for Concurrent Operations on B-Trees (Lehman/Yao 1981)
• Concurrent Operations on B*-Trees with Overtaking (Sagiv 1986)
• A survey of B-tree locking techniques (Graefe 2010)
• B+Tree Locking (slides from Stanford U, including Blink trees)
• A Blink Tree method and latch protocol for synchronous deletion in a high concurreny environment (Malbrain 2010)
• A Lock-Free B+Tree (Braginsky/Petrank 2012)