Hi all,

in the current working draft, clause [res.on.data.races] (§16.4.6.10,
https://eel.is/c++draft/res.on.data.races), which regards data race
avoidance in the standard library implementation, states (Paragraph 3):

"A C++ standard library function shall not directly or indirectly
modify objects ([intro.multithread]) accessible by threads other than
the current thread unless the objects are accessed directly or
indirectly via the function's non-const arguments, including this."

What I'm reading into this is that it is UB if a standard library
function calls a const member function of an object that was passed to
it via a const ref, and the the const member function "modifies" the
object (via const_cast or a mutable member).
However, I doubt that this is the correct interpretation.

There is some discussion about this clause, but I couldn't find a
definitive answer.
Most notably, there is a talk by Herb Sutter:
https://web.archive.org/web/20170119232617/https://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank

At about 15:35, he states that since C++11, const implies threadsafe,
because it implies either bitwise const or internal synchronization
(e.g., by a mutable std::mutex).

With the above interpretation, I can see how const may imply bitwise
const, but I fail to see how Herb derives the internal synchronization
requirement. In my understanding, the example given at 26:00, locking a
mutable std::mutex member still modifies the object, violating
[res.on.data.races], if a standard library function were to call
w.get_info() on a const widget& w.

My main questions are:
What are the requirements for const member functions that are intended
to be used with the standard library, and how does thread-safety relate
to the const qualifier?

Best
Marvin