Lock free skiplist with size

[polytypic]

This adds a minimalistic optimized lock-free skiplist implementation with size (using and written on top of PR #102).

For future work:

• Changing the max node height dynamically.
• Additional operations. Skiplist can support operations like finding/removing the binding with the minimum / maximum key, listing bindings in (ascending) order of their keys, finding a bindings with keys in given range (min, max) of keys, finding the binding with the smallest key that is greater or equal to search key, ... all the things you'd expect from an ordered container.
• Rethink benchmark

The benchmark in this PR is not ideal, but I plan to leave that to (near) future work. I've recently enhanced the small internal multicore benchmarking framework I've been using in Kcas and the plan is to move that to a separate package to allow using it in other projects (like Saturn).

[lyrm]

This line made me think quite a bit so I'm leaving a note in hope it may help someone else (or a future version of myself).

I was wondering why the recursive call here is made at the current level and not at a higher level as if curr_node has higher levels there are also marked but these marked could have been missed by the current find_path call. Also, I made the wrong assumption that these missed marks may cause the function calling find_path (add for example) to do some costlier operations to remove the marked node. So I was thinking maybe we can prevent it by looping a bit higher here (basically at the max height of the marked node, if possible).

But :

• the add function actually does not make an avoidable costlier operation : either the node has been completely removed making a CAS fail (line 263) (this is unavoidable as the removal operation can be completed by almost all operations) or the removal operation is not finished and add can finish without any additional work
• it may actually make thing worst as encountering a marked node may happen repetitively. So if each time this happen find_path goes back up a few levels it may be delayed indefinitely.

[polytypic]

Interesting. Hmm... Yes, I wonder whether there might be ways to do these traversals more intelligently.

🤔

I think a reasonable basic assumption is that encountering a marked link is something that should happen relatively rarely. That is because marked links are only used on nodes to be removed and so usually you would expect a particular marked link to be encountered roughly just once — unless there is heavy ongoing parallelism — and even in that case only a single thread will succeed in unlinking the node at each level. Also, the expected number of links (and therefore the number of marked links) on a node is (less than) two, because of the way the node heights are distributed. So, it is probably better to optimize with the assumption that marked links are rare.

[lyrm]

I don't see a reason to not do an Atomic.set here instead of and Atomic.compare_and_set as no one can access these levels of the added node yet.

[polytypic]

Hmm... It is a subtle thing, but after the node has been added to level 0, i.e. the first compare_and_set in add has succeeded, the node is considered as having been added to the skiplist and then remove may concurrently find and mark all the outgoing links from the node. The remove operation is special in this sense. Other operations cannot access outgoing links of a node on levels that the node has not yet been linked to from other nodes of the skiplist.

[lyrm]

Oh, right, the node can be marked. The tests passed on my computer with this change so there is definitely a dscheck test missing here.