On 24/02/2024 08.29, Jan Schultke via Std-Proposals wrote:
> This sounds very questionable because you're essentially standardizing
> one form of synchronization, and this form isn't necessarily the best
> for all purposes.
>
> - In some cases, the user really would have just wanted a mutex
> guarding the whole container.
> - In other cases, the user would have wanted multiple mutexes (e.g.
> one mutex per N buckets in a std::unordered_map)
> - In other cases, a mutex per node in some graph/linked list is desirable.
> - In other cases, lock-free data structures are best.

Agreed.

Also, for some people, having a shared_ptr (and its atomic
counter management) is a non-starter. Approaches such as
RCU or hazard pointers have been invented precisely to avoid
the overhead of more synchronous approaches.

> The standard doesn't have the flexibility to benefit from any such new
> findings, so it's the worst possible place to define these thread-safe
> data structures. They belong in third-party libraries.

I think there is space to offer some basic concurrent data structures
in the standard, with the express understanding that more of the
implementation is exposed in the interface than we'd prefer.
In return, that comes with possibly less of an abstraction than
we're used to for single-thread-access data structures.

In short, anyone claiming "here is /the/ multi-thread-safe
<list/queue/map/whatever> data structure, please standardize it" is
misguided. Having a thread-safe forward list with the
ABA problem expressly unsolved, or one that expressly ties into
RCU, might get more consensus.

Jens