Thread safety and `const`

Question

How does const (pointers, references and member functions) help with thread safety in C++?

Answer 1

Any immutable (that is, unchangable) data is inherently thread safe - there's no risk for multiple threads concurrently reading the same read-only data because it's never going to change!

Marking a variable as const in C++ makes it read-only and thus thread safe.

Answer 2

The main problem with multiple threads is mutability. const restricts this, but since you can cast away the const-ness, it's not foolproof.

Answer 3

A const member function shouldn't change state which makes it safe to call from multiple threads at the same time. However thread safety is not the purpose of const and C++ provides the mutable keyword and const_cast meaning that const does not actually guarantee thread safety and shouldn't be relied on for this purpose.

Answer 4

Const functions is not thread safe. Normaly, you can call const object methods from different threads concurrently, but if you call non const and const method from different threads you get race condition. Check this:

class Foo
{
    size_t size_;
public:
    ...
    size_t get_size() const
    {
        return size_
    }
};

class Bar
{
    boost::shared_ptr<Foo> foo_;
public:
    //accessor
    size_t get_size() const
    {
        size_t size = 0;
        if (foo_)
            size = foo_->size();
        return size;
    }
    //modifiers
    void init()
    {
        foo_ = new Foo;
    }

    void clear()
    {
        foo_ = boost::shared_ptr<Foo>();
    }
};

If somebody call init method, and then call clear and get_size methods concurrently, it will cause access violation. You must use read write lock idiom. Multiple accessors can be called at the same time, and only one modifier can be called at the same time. Exemple:

class Bar
{
    boost::shared_ptr<Foo> foo_;
    mutable tbb::spin_rw_mutex lock_;
public:
    //accessor
    size_t get_size() const
    {
        size_t size = 0;
        //lock modifiers
        rw_mutex_type::scoped_lock lock(mutex, false);
        if (foo_)
            size = foo_->size();
        return size;
    }
    //modifiers
    void init()
    {
        //lock accessor and modifiers
        rw_mutex_type::scoped_lock lock(mutex, true);
        foo_ = new Foo;
    }

    void clear()
    {
        //lock accessor and modifiers
        rw_mutex_type::scoped_lock lock(mutex, true);
        foo_ = boost::shared_ptr<Foo>();
    }
};

tbb::spin_rw_lock is a mutex class from threading builing blocks library

Answer 5

C++ const allows non-const aliasing such as:

Foo myVar;
const Foo* ptr1;
Foo* ptr2;

Given this, const provides no guarantees as to the immutability of your data, even if you don't do any casting or anything to get around it. If you access myVar through ptr1, you can't change it through ptr1 (assuming I got the syntax right; that was the intent.) However, it could still change through ptr2. What you really want is a separate immutable construct. This does not exist in C++.

Answer 6

Const and thread safety are orthogonal concepts.

Take a const function as an example: A class may have both const and non-const functions, and one thread may be calling a non-const function that modifies the object at the same time another thread is in its const function. In this case, marking the function const provides no safety whatsoever. Thread-safety is only achieved with locking or other synchronization primitives.