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 <std-proposals@lists.isocpp.org>
Gesendet: Fr 23.02.2024 18:21
Betreff: Re: [std-proposals] High Performance Thread-Safe C++
An: std-proposals@lists.isocpp.org;
CC: David G. Pickett <dgpickett@aol.com>;

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
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals