views:

592

answers:

5

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

+12  A: 

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.

Mark Pim
Assuming you're not using mutable anywhere ;-)
Leon Timmermans
And assuming it's initialization is thread-safe.
xtofl
Initialization usually is. Why would you share an object that hasn't been fully initialized?
Greg Rogers
also assuming all member functions are reentrant (i.e no static objects or other shared data)
Johannes Schaub - litb
+5  A: 

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

Brian Rasmussen
True, but you need to do extra work to shoot yourself in the foot.
Gamecat
Brian Rasmussen
No code is fool-proof, but you must protect against Murphy, not against Machiavelli.
Gorpik
+3  A: 

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.

Patrick
+2  A: 

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

Lazin
Indeed: constness only _helps_ build thread safe applications
xtofl
A: 

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++.

dsimcha