This point about the B-tree is salient:<p><pre><code> Unfortunately, to make the B-tree generic we require an
interface and the most expensive operation in CPU
profiling is the interface method which in turn calls
into runtime.assertI2T. We need generics.
</code></pre>
One of the most frustrating aspects of go is having to resort to interface{} every time you want a generic implementation of a data structure.
Something I've always wondered - in the futures packages (<a href="https://github.com/Workiva/go-datastructures/blob/master/futures/futures.go" rel="nofollow">https://github.com/Workiva/go-datastructures/blob/master/fut...</a>):<p>The author has a variable `triggered` to check the state of whether or not the future is complete. Now to protect that variable from data races, the author uses a standard lock. Now since you need to protect a simple value what I would do in this situation is use an atomic variable w/ atomic.StoreInt32 (you could also probably not even have to use an atomic load in GetResult).<p>Of course the best option would be to benchmark (and I'm assuming the author did, given that the structures are performant), but I'm wondering if my "gut" is right and under what situations others have seen that would necessitate a lock vs. an atomic instruction (high contention on readers, few writers)?
Now someone will hopefully create "type writers" for gen [1] for compile-time type checking and convenience.<p>[1] <a href="http://clipperhouse.github.io/gen/typewriters/" rel="nofollow">http://clipperhouse.github.io/gen/typewriters/</a>
For an alternative to Futures, check out tv42's "topic":<p><a href="http://github.com/tv42/topic" rel="nofollow">http://github.com/tv42/topic</a><p>I used it here in my multiplexing serial-to-TCP adapter: <a href="https://github.com/chrissnell/tnc-server/blob/master/tnc-server.go" rel="nofollow">https://github.com/chrissnell/tnc-server/blob/master/tnc-ser...</a>
Some of these sound really great. A major pain point with go concurrency is the absence of a fast lockfree map implementation that doesn't destroy your GC times. The 'ctrie' sounds very appealing; I'm curious to try it.
Has anyone used Ctries in any real scenario (has anyone implemented them in a language like C)? How do they fare as opposed to other data structures? Is the latency of CAS instructions insignificant?<p>I'm thinking of using it in our codebase, in theory it should speed things up quite a bit.