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_at_[hidden]> Gesendet:Fr 23.02.2024 18:21 Betreff:Re: [std-proposals] High Performance Thread-Safe C++ An:std-proposals_at_[hidden]; CC:David G. Pickett <dgpickett_at_[hidden]>; 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_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals