syncbuf VS dashmap

I was trying to do something similar a little while back and ended up writing the Synclist type in Syncbuf. This has the tradeoff that the elements are spread across non-contiguous chunks, so it can't be sliced. But it has the advantage of being able to contain any type, memory usage is monotonic, and "reallocation" is much cheaper since nothing is copied.

Since you asked, my little project in this area has been Syncbuf: https://github.com/bplevin36/syncbuf. It has 2 lock-free concurrent buffer types that are low-overhead by being append-only.

I was writing a toy virtual machine when I realized that in order to make it multi-threaded, it would be very helpful to maintain a global symbol table that allowed adding new symbols without invalidating references to old ones. No such thing appeared to exist yet, so I wrote it: https://github.com/bplevin36/syncbuf

The problem is, every single one of these half-dozen crates has at least one known major issue (including UAF), exactly like C++ implementations (which isn't surprising since it's the kind of things where the ownership isn't clear and then the borrow checker can't help us).

Deadlocks and leaks are easy as other languages.

Have you considered https://github.com/xacrimon/dashmap ?

Dashmap made some api changes compared to the stdlibs hashmap, which leads to some oddities, as highlighted here: https://github.com/xacrimon/dashmap/issues/175

Some additional notes are in this slide deck and the implementation javadoc. You'd probably want to use something like DashMap for the hash table.

You can look at existing concurrent maps like Dashmap https://github.com/xacrimon/dashmap or Cashmap https://gitlab.redox-os.org/redox-os/chashmap

Also dashmap

The only one I've used is Dashmap, it's a concurrent interior-mutability hashmap. Very convenient crate in the case you need that.