Reader-Writer mutex

Say that in our C++ application we have to protect some data that are read at high frequence from multiple threads and are seldom written. We could use a normal mutex-lock pattern, but that would slow down all the reading threads without any reason. The fact is that we should be able to track all the existing access to the resource and actually create a critical section only when the data change.

We can use the Boost Thread library shared_mutex and shared_lock for this purpose.

Instead of a plain mutex we define a shared_mutex to control the access to the resource; the readers would acquire a shared_lock on it before reading the data. When a writer wants to modify it, it would acquire a lock_guard on the shared_mutex, that would give it full control on the resource.

Let's see the code:

class ReadWrite
{
private:
    int value_; // 1
    boost::shared_mutex mx_; // 2

public:
    ReadWrite() : value_(42) {}

    void read()
    {
        boost::shared_lock<boost::shared_mutex> lx(mx_); // 3
        std::cout << boost::this_thread::get_id() << " read: " << value_ << std::endl; // 4
        boost::this_thread::sleep(boost::posix_time::millisec(100)); // 5
    }

    void increase()
    {
        boost::lock_guard<boost::shared_mutex> lx(mx_); // 6
        std::cout << boost::this_thread::get_id() << " increasing " << value_++ << std::endl; // 7
        boost::this_thread::sleep(boost::posix_time::millisec(100));
        std::cout << boost::this_thread::get_id() << " new value: " << value_ << std::endl;
    }

    void reading() // 8
    {
        for(int i = 0; i < 15; ++i)
            read();
    }
};

1. This is just a silly example, so it would suffice having an integer as undelying resource.
2. And this is the shared_mutex we'll use to access the resource.
3. Before actually reading the data we should succeed acquiring a shared_lock on the defined shared_mutex. As many thread as we like could do it, if are all reading.
4. Some feedback to see what it is actually going on. Notice that this code is buggy, no mutex has been used for the standard output to console - this means that we are almost surely to have mixedup output. I expressely avoided to use such a mutex to keep the code to point, but it should be easy for you to fix the problem.
5. Some sleeping to make the effect of the lock more readable.
6. Here we need to access the data for changing it, so we create a lock_guard on the shared_mutex. This lock would patiently wait its turn if other threads owns the mutex, but when it get it, it would be the only one that could access the data - as we expect from a lock_guard - till it exits.
7. Notice that here the data changes.
8. Just an utility function, to make the testing easier.

And talking about testing:

TEST(ReadWrite, One)
{
    ReadWrite rw;

    boost::thread t1(&ReadWrite::reading, &rw); // 1
    boost::thread t2(&ReadWrite::reading, &rw);

    for(int i = 0; i < 4; ++i)
    {
        boost::this_thread::sleep(boost::posix_time::millisec(300));
        rw.increase(); // 2
    }

    t1.join();
    t2.join();
}

1. Two threads run on the reading() function.
2. Sometimes the main thread butts in and changes the undelying data.