Idea : Lock Free STD Collection

Compared to e.g. Java std is lacking just about any shared-mutability collection in the first place. However, curiously but without quantification I think that observation holds across the ecosystem, too. Anecdotally for bloom filters, count-min-sketch, and hyperloglog implementations, despite that parallel use being a rather prominent application and there being specifically distributed variants addressing cache hierarchies, false, and true sharing, many crates implementing them provide an interface either based on &mut self or are not sync.

The interoperability argument seems weak without a concrete example. Moving these into the standard library would not magically make them better and: which interface would pass a concurrent data structure across crates, not offer an opaque wapper for it? The comparison to Vec, which is a buffer for String, Read in std, and has specialization to make into_iter() (and conversely extend) efficient, is a rather large leap of logic. All of those motivate it being an actual vocabulary type of sorts. Arc in comparison is already less motivated but it gives us stable unsizing and some std-os modules can build on it. What's the tie-in for lockfree data structures?

Maybe consider if, instead, a specific lack of deeper core routines / types contributes to the disconnect between the two worlds that should be addressed first. Rust makes it easier to work on exclusively owned data, in general that is by design and good. However, for another more special class of algorithms are we missing something–apart from the obviously hard atomic unordered / memcpy, is there some safe core abstraction that we can already provide to facilitate?