Designing a new concurrent data structure

In my experience Left-Write is the clear place to start. It&#x27;s general purpose and fast for reads. Only if that is unsuitable (eg memory usage) does one design a custom data structure. There&#x27;s a Rust lib implementation with links to more resources:<p><a href="https:&#x2F;&#x2F;docs.rs&#x2F;left-right&#x2F;latest&#x2F;left_right&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.rs&#x2F;left-right&#x2F;latest&#x2F;left_right&#x2F;</a>

Hello, the author here. It feels great to see my blog on HN!<p>It was quite a journey, at first I thought I invented a novel concurrency schema. However, it turns out that it was simply a mix of my ignorance and hubris! :-)<p>Still, I had a lot of fun while designing this data structure and I believe it made a nice story. Ask me anything!

You could also check out hazard pointers. This is basically the example used in <a href="https:&#x2F;&#x2F;melodiessim.netlify.app&#x2F;intro-hazard-ptrs&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;melodiessim.netlify.app&#x2F;intro-hazard-ptrs&#x2F;</a>

Hi. You missed the opportunity to implement the reader as an AutoCloseable and do the get as a Reader method.<p>That way, classe users will be warned by the IDE that they should use a try-with-resources when acquiring a Reader.<p>For the sake of completeness here, Java compiler will warn about it, but that warning is disabled by default.

Did you consider just making an array of HashMap, say 512 of them, and locking only one of them based on your key&#x27;s hash?<p>Or, more generally, minimizing the odds of waiting on a lock, without resorting to a complex lock free scheme?

Why not just allocating the blobs off-heap? (That is something you probably want to do anyway if it&#x27;s cryptographic material, to avoid being at the mercy of the GC leaving copies around)<p>ByteBuffer.allocateDirect should do that IIRC. This allows you to use the standard ConcurrentHashMap while being able to get a stable pointer for use by the rust logic.

seems like a lot of effort - could you have moved the map state to rust instead? to invoke the AuthCrypto.verifySignature with just the key?

cool article, I learned a lot, but I’m scratching my head wondering why they’re settling for Java on this project when Rust is better suited for it, seems like with the lifetimes, need for consistency and concurrency, memory leak issues, and generally the goal for high performance, this would be an awesome project for learning Rust