CODEWITHSUNDEEP
c++multithreadingboostboost-thread
2607
2607

Reputation: 4115

Boost, mutex concept

I am new to multi-threading programming, and confused about how Mutex works. In the Boost::Thread manual, it states:

Mutexes guarantee that only one thread can lock a given mutex. If a code section is surrounded by a mutex locking and unlocking, it's guaranteed that only a thread at a time executes that section of code. When that thread unlocks the mutex, other threads can enter to that code region:

My understanding is that Mutex is used to protect a section of code from being executed by multiple threads at the same time, NOT protect the memory address of a variable. It's hard for me to grasp the concept, what happen if I have 2 different functions trying to write to the same memory address.

Is there something like this in Boost library:

  1. lock a memory address of a variable, e.g., double x, lock (x); So that other threads with a different function can not write to x.
  2. do something with x, e.g., x = x + rand();
  3. unlock (x)

Thanks.

Upvotes: 5

Views: 4420

Answers (6)

David Schwartz
David Schwartz

Reputation: 182743

I think the detail you're missing is that a "code section" is an arbitrary section of code. It can be two functions, half a function, a single line, or whatever.

So the portions of your 2 different functions that hold the same mutex when they access the shared data, are "a code section surrounded by a mutex locking and unlocking" so therefore "it's guaranteed that only a thread at a time executes that section of code".

Also, this is explaining one property of mutexes. It is not claiming this is the only property they have.

Upvotes: 1

Tudor
Tudor

Reputation: 62439

It is possible to do non-blocking atomic operations on certain types using Boost.Atomic. These operations are non-blocking and generally much faster than a mutex. For example, to add something atomically you can do:

boost::atomic<int> n = 10;
n.fetch_add(5, boost:memory_order_acq_rel);

This code atomically adds 5 to n.

Upvotes: 2

Diego Sevilla
Diego Sevilla

Reputation: 29001

Your understanding is correct with respect to mutexes. They protect the section of code between the locking and unlocking.

As per what happens when two threads write to the same location of memory, they are serialized. One thread writes its value, the other thread writes to it. The problem with this is that you don't know which thread will write first (or last), so the code is not deterministic.

Finally, to protect a variable itself, you can find a near concept in atomic variables. Atomic variables are variables that are protected by either the compiler or the hardware, and can be modified atomically. That is, the three phases you comment (read, modify, write) happen atomically. Take a look at Boost atomic_count.

Upvotes: 0

Jerry Coffin
Jerry Coffin

Reputation: 490018

The mutex itself only ensures that only one thread of execution can lock the mutex at any given time. It's up to you to ensure that modification of the associated variable happens only while the mutex is locked.

C++ does give you a way to do that a little more easily than in something like C. In C, it's pretty much up to you to write the code correctly, ensuring that anywhere you modify the variable, you first lock the mutex (and, of course, unlock it when you're done).

In C++, it's pretty easy to encapsulate it all into a class with some operator overloading:

class protected_int {
    int value; // this is the value we're going to share between threads
    mutex m;
public:
    operator int() { return value; } // we'll assume no lock needed to read
    protected_int &operator=(int new_value) {
        lock(m);
        value = new_value;
        unlock(m);
        return *this;
    }
};

Obviously I'm simplifying that a lot (to the point that it's probably useless as it stands), but hopefully you get the idea, which is that most of the code just treats the protected_int object as if it were a normal variable.

When you do that, however, the mutex is automatically locked every time you assign a value to it, and unlocked immediately thereafter. Of course, that's pretty much the simplest possible case -- in many cases, you need to do something like lock the mutex, modify two (or more) variables in unison, then unlock. Regardless of the complexity, however, the idea remains that you centralize all the code that does the modification in one place, so you don't have to worry about locking the mutex in the rest of the code. Where you do have two or more variables together like that, you generally will have to lock the mutex to read, not just to write -- otherwise you can easily get an incorrect value where one of the variables has been modified but the other hasn't.

Upvotes: 5

nos
nos

Reputation: 229058

No, there is nothing in boost(or elsewhere) that will lock memory like that. You have to protect the code that access the memory you want protected.

what happen if I have 2 different functions trying to write to the same memory address.

Assuming you mean 2 functions executing in different threads, both functions should lock the same mutex, so only one of the threads can write to the variable at a given time.

Any other code that accesses (either reads or writes) the same variable will also have to lock the same mutex, failure to do so will result in indeterministic behavior.

Upvotes: 3

Jason
Jason

Reputation: 32490

In order to protect a memory address shared by multiple threads in two different functions, both functions have to use the same mutex ... otherwise you will run into a scenario where threads in either function can indiscriminately access the same "protected" memory region.

So boost::mutex works just fine for the scenario you describe, but you just have to make sure that for a given resource you're protecting, all paths to that resource lock the exact same instance of the boost::mutex object.

Upvotes: 1

Related Questions