> Obviously, it's a bit sad when due credit is not given where it should be
The post actually references your paper. :)
The post actually references your paper. :)
From the QuestDB article:
> First, I found the Double Instance Locking[1] pattern at the amazing Concurrency Freaks blog[2]. This pattern is very similar to the one I described here. It also uses 2 internals structures and readers are alternating between them. It uses a read-write lock to protect the map being mutated. Given there is only a single writer then at any given time there is at least one internal map which is available for reading. This gives readers lock freedom.
> It's fair to say that the Double Instance Locking pattern is simpler to reason about. It decomposes the problem better. But I'd still argue my contribution is the trick with delayed replay of the last operation - if writers are sufficiently rare, then writers won't be blocked at all.
> The same blog also links to the paper Left-Right: A Concurrency Control Technique with Wait-Free Population Oblivious Reads[3] which on the surface also looks similar. It claims not only Lock-Freedom, but also Wait-Freedom. I have yet to deep dive into it.
[1] http://concurrencyfreaks.blogspot.com/2013/11/double-instanc...
[2] http://concurrencyfreaks.blogspot.com/
[3] https://master.dl.sourceforge.net/project/ccfreaks/papers/Le...