Is the meaning of `const` still thread-safe in C++11?

Question

I recently came across Herb Sutter's video from about how the meaning of const and mutable has changed in C++11 to mean bitwise const (and thread-safe, as a consequence) instead of the traditional logically const.

Five years later, have programmers migrated to this new meaning of const?

I've tried using this while writing a new application but it seems that I'm marking every private member as mutable because they're either protected by a mutex or thread-safe (by their implementation) - which doesn't feel right (I'm inexperienced and do not have a basis for this).

Is it good practice while designing a thread-safe application to mark every member function const and every member variable mutable?

Answer 1

The video you cited is for an advanced and expert audience. Herb Sutter tries to bring this audience to a consensus on how to best communicate the intent of these keywords to other people, in this age of everything yearning to be thread-safe.

So don't expect that this video contains all you need to know to write perfectly thread-safe code.

---

I'm marking every private member as mutable because they're either protected by a mutex or thread-safe (by their implementation) - which doesn't feel right (I'm inexperienced and do not have a basis for this).

Here is a hypothetical example of what would be blatantly wrong:

class Size
{
    mutable int x;
    mutable int y;
    // ...
public:
    void setSize(int newX, int newY) const // (first scream)
    {
        // modify members "x" and "y", "SAFELY!" (second scream)
    }
};

The function signature screams wrong, because a function named setSize couldn't possibly be const. The implementation of the function's code would eventually require marking the members "x" and "y" as mutable, which would scream wrong too.

It doesn't matter what code is in the setSize function. If the function's name implies that the function will change the state of the object, it should not be marked with const. Let's suppose we remove the const keyword from the function. Now we find that we don't have to use the mutable keyword on the members "x" and "y". Problem solved.

In other words, if the use of const and mutable are both against intuition, and if such awkward usage occur in pairs, then one should to be suspicious of their usage being wrong.

However, the video mentions one exceptional case. If a class contains a std::mutex member, it is almost always correct to mark it as a mutable member. Please refer to the video for explanations.

Once you have some experience doing it correctly, you can rely on your intuition to see whether it looks natural, and natural means correct.

If a function's name implies that it should not change the state of the object, then it should be marked with const, and the code inside needs to be made thread-safe, by not performing thread-unsafe operations.

This is the mentality expressed in the video linked above. When it comes to thread-safety, users of your code (yourself, or your fellow teammates) have certain expectations that certain functions shouldn't do certain things.

The video mentions these examples:

• bool operator == (const T& other) const should never modify this or other, because nobody would expect comparisons to modify anything. (This is called "side-effect free".)
• class T { public: T(const T& other) {...} }; should never modify other, because the same instance of other might have been passed into two threads, each threading passing it into the copy constructor.

---

How about this code?

class Size
{
    const int x;
    const int y;
    // ...
public:
    Size(int init_x, int init_y)
        : x(init_x), y(init_y)
    {
    }
};

This code is even better. It demonstrates the correct use of const on members.

However, it does prevent one from using the Size class in certain ways. For example, you cannot use assignment operators to overwrite an existing instance of Size. In other words, following the best practice when implementing the Size class, may require you to redesign other source code that uses Size. This is the "contagious issue" that makes const-ness an important consideration for a C++ project.

Answer 2

Is it good practice while designing a thread-safe application to mark every member function const and every member variable mutable?

No, that is not good practice.

A const member function signals that the function will not modify the object it is called upon. Because the object won't be modified, it is safe to call the function from multiple thread without external locking.

However, it is not the case that const member functions are the only thread-safe functions. Any other function can be thread safe as well.
Using the const modifier to mark a mutating function as thread-safe is giving the wrong signal.

Answer 3

As already stated by others, a const function implies it should be thread-safe to call it from multiple threads simultaneously, without calling a non const function at the same time. As Herb Sutter (29:43) stated himself, this means that a const function should be bitwise const or internally synchronised, which isn't really thread-safe if other non-const functions may be called at the same time.

Thread-safe definitely does not mean/imply const.

Note that the following old threat is still relevant: Does const mean thread-safe in C++11?, but bear in mind that the term thread-safe is often abused (see What is the definition of a thread safe function according to the C++11 (Language/Library) Standard?), i.e. in this context thread-safe is used for bitwise const or internally synchronised.

Answer 4

The meaning of the const keyword is still 'logically const': it's just that logical constness now has to take account of thread safety as well as other things.

All 'logically const' means is that, from the point of view of the public interface of the class, we appear to be a const function. This is a good concept, because the public interface of the class is the only thing that should make a difference to the rest of the program. Our const function might store some information to a cache, or change the bitwise state in some other way, but that's an implementation detail: if external code can't tell that it's not bitwise const, then it should be marked const - possibly with some members marked mutable to make this possible.

With C++11 and its multithreading capabilities, this definition becomes more complicated. If a function is truly bitwise const, then it is automatically safe to call it from multiple threads concurrently. This means that any function that is not thread safe is automatically not logically const - because it behaves differently from a bitwise const function from the point of view of external code. A bitwise const function would be thread safe.

So while it's true that you should make sure that any function that is marked const in your code is thread safe, the reverse does not apply: it's perfectly legal to have functions that are thread safe but are not logically const for other reasons.

That said, if your code calls a non-const function, then that code should assume that the function is not thread-safe: if it needs to be called concurrently, then the individual calls should be protected by mutexes in the enclosing scope. It may be the case that the function is thread-safe at the moment, but that is an implementation detail and can be changed without changing the signature of the function.

On the other hand, if the function is const and you change it to be non-thread-safe, then you have broken the contract of the function.