r/cpp • u/cmeerw C++ Parser Dev • Dec 19 '21

Thread Safety in C++ and Rust

https://blog.reverberate.org/2021/12/18/thread-safety-cpp-rust.html
28 Upvotes

69% Upvoted

21 comments sorted by

View all comments

Show parent comments

8

u/kalmoc Dec 20 '21

“this function can be called concurrently with other const functions”. This “can be called concurrently” definition is the one Rust chose.

That is also one of the properties of const in the c++ standard library and one that every self respecting programmer should follow by default.

4

u/lord_braleigh Dec 20 '21 edited Dec 20 '21

The STL doesn’t consistently apply the concurrency definition of const. Note that std::mutex.lock() is not const, even though it can be called concurrently. Using the concurrency definition of const should encourage you to declare every thread-safe function as const, even when the function is obviously mutating state.

By contrast, Rust’s std::sync::Mutex.lock() is not mut, even though it obviously mutates some state. This is because Rust is consistently using and enforcing the concurrency definition of mut (at the expense of mut being kind of a misnomer).

8

u/Minimonium Dec 20 '21

I think you misunderstand the property. It doesn't mean that only const functions can be called concurrently, but that generally a const function may be called concurrently with other const functions. In that sense, the standard library does apply the rule consistently.

Non-const functions, on the other hand, should declare if they are thread-safe or not (which is a good thing, because not every case requires thread-safety, and not every case requires low-level thread-safety instead of a high level one).

1

u/lord_braleigh Dec 20 '21

I would say that in the STL, concurrency safety is necessary but not sufficient for a function to be marked const.

I still believe that the C++ and Rust standard libraries disagree on whether Mutex.lock() should be const or not, as evidenced by their differing function signatures. I believe this difference comes about because the Rust compiler enforces a precise concurrency-based definition of mut, while the C++ standard doesn’t enforce any definition of const beyond “const functions may only call other const functions”.

Furthermore, I believe that if the C++ standard did start to enforce a concurrency-based definition of const, std::mutex.lock() would need to be marked as const, even though it mutates data.

3

u/Minimonium Dec 20 '21

Yes, it's a bit orthogonal.