Non blocking data structures for Go
Latest commit 2716306 Jun 26, 2016 @zond committed on GitHub Merge pull request #4 from kenshaw/master
Fixing compilation issues with go1.7+


Non blocking data structures for Go.


The List type is implemented using A Pragmatic Implementation of Non-Blocking Linked-Lists by Timothy L. Harris.

The Hash type is implemented using Split-Ordered Lists: Lock-Free Extensible Hash Tables by Ori Shalev and Nir Shavit with the List type used as backend.

The Transaction type is implemented using OSTM from Concurrent Programming Without Locks by Keir Fraser and Tim Harris with a few tweaks described in

The Treap type uses Transaction to be non blocking and thread safe, and is based (like all other treaps, I guess) on Randomized Search Trees by Cecilia Aragon and Raimund Seidel, but mostly I just used for reference.


On my laptop I created benchmarks for a) regular Go map types, b) Go map types protected by sync.RWMutex, c) the gotomic.Hash, d) the gotomic.Treap type and e) the type.

The benchmarks for a) and b) can be found at, the benchmark for c) at and the benchmark for d) and e) at

The TL;DR of it all is that the benchmark sets runtime.GOMAXPROCS to be runtime.NumCPU(), and starts that number of goroutines that just mutates and reads the tested mapping.

Last time I ran these tests I got the following results:


BenchmarkNativeMap   5000000           567 ns/op


BenchmarkMyMapConc    200000         10694 ns/op
BenchmarkMyMap   1000000          1427 ns/op


BenchmarkHash      500000         5146 ns/op
BenchmarkHashConc     500000         10599 ns/op


BenchmarkTreap     50000         71250 ns/op
BenchmarkTreapConc     10000        110843 ns/op


BenchmarkStatHatTreap    1000000          4373 ns/op

Also, there are some third party benchmarks available at

Conclusion: As expected a) is by far the fastest mapping, and it seems that the naive RWMutex wrapped native map b) is much faster at single thread operation, and on a weak laptop about as efficient in multi thread operation, compared to c).

However, on more multicored systems (and also a few smaller ones, strangely enough) c) is more efficient than b).

When it comes to the treap class, I am afraid my implementation of STM is really REALLY inefficient. Maybe because I tried to be clever, or because I just botched it someplace. It seems to work, but I reckon that an RWMutex-wrapped stathat treap would be preferable in most circumstances.


See or

Also, see the tests.



Hash and List have no known bugs and seem to work well.

The Transaction, Handle and Treap types are alpha. They seem to work, but are too slow and untrustworthy :/

I have not tried it on more than my personal laptop however, so if you want to try and force it to misbehave on a heftier machine than a 4 cpu MacBook Air please do!


It would be nice to have a Hash#DeleteIfPresent that atomically deletes matching key/value pairs, but since the implementation is slightly harder than trivial and I see no immediate use case I have been too lazy. Tell me if you need it and I might feel motivated :)