I'm happy to announce the availability of StashTable, my take at concurrent hash table implementation: https://github.com/olliNiinivaara/StashTable
It is optimized for use cases where insertions and deletions are rare compared to reads and writes, reads or writes may occasionally take some time, and iterating through all items must not slow down readers or writers or other iterators.
StashTable uses a unique collision resolution strategy and fine-grained locking to achieve O(1)-class performance in thread-safe manner.
Unlike SharedTable, StashTable supports len (get count of items), findIndex (check if key already exists), insert (insert item only if key does not exist) and keys (iterate through all keys) operations.
Code is MIT-licenced, elegant Nim without any "C-level" unsafe stuff like casts or allocs.
Running nimble test under Linux with nim version 1.0.6 yields messages such as
Key 8205 in SharedTable with value 8205 but missing from StashTable
Key 14365 in SharedTable with value 14365 but missing from StashTable
Key 8205 in SharedTable with value 8205 but missing from StashTable
Key 14365 in SharedTable with value 14365 but missing from StashTable
Is this expected?
Yes, and the explanation is given at the github page. However, if you set threadcount to 1 (test.nim, line 14), such messages should never occur.
Unfortunately writing fast and correct concurrent data structures is an extremely hard problem. (https://forum.nim-lang.org/t/6070#37565)
and testing them is hard, too...
I wanted to make this work onwards Nim 1.0.0 so I had to comment out some runnableExamples.
Just realized that I had managed to comment out the whole keys iterator as well (!)
Please, reinstall, and sorry for the inconvenience...