The consensus for programming languages (not just C++) is that the granularity of locking single member function calls with a mutex is typically too small for real-world applications. You need transactions spanning several calls to the same and/or different containers and data structures to get again a valid state.


Protecting all individual member functions just for the duration of the call would not be thread-safe.


Doing it in addition to another overarching mutex would be worse performance-wise and could lead many developers into a false sense of security. So they would assume the code is thread-safe, when actually it is not.


Java did it wrong once in the past, but then reversed course.

-----Ursprüngliche Nachricht-----
Von: David G. Pickett via Std-Proposals <>
Gesendet: Fr 23.02.2024 18:21
Betreff: Re: [std-proposals] High Performance Thread-Safe C++
CC: David G. Pickett <>;
It'd be nice if the language had a way to say that a particular container *instance* needs to be thread safe, so all methods are mutex protected.  The developer could add a reserved word in the declaration.  This way, users are not accidentally using a mutex unnecessarily.  The compiler can add the mutex lock to all methods when invoked, somewhat like a MACRO but less global.  We don't want to be like Java, and have to remember which container name is synchronized, e.g ArrayList, Vector; StringBuffer, StringBuilder, or hve duffers using a synchronized container when not needed.
 Std-Proposals mailing list