Scope of scoped_lock

Question

I kind of new in multi thread programming. So in my case I have a boost multi_index container which can be reached from many threads simultaneously. I'm performing some search and insert operations.

So when a search starts with an index I don't want a new value to be inserted by another thread. Because it can change the index and mass things up. So I have to use a mutex.

So many people using boost scoped_lock for this purpose. My quesition is simply what is the "scope" of scoped_lock ?

Assume that I have a function like that:

void A ()
{
   myData data;
   // prepare data here

    // ******* 1 ******** 
   B(data); // assume this perform some operations

}

void B (myData data)
{
   // do some stuff with data
   // ******* 2 ********
   search(data);
}


void search(myData data)
{
   // ******* 3 ********
   // start searching the data here
} 

so I would like to acquire the lock from the beginning of the process it means from procedure A. If I put my boost::mutex::scoped_locklock(mutex); code to the place which is marked as ******* 1 ******** does it lock also the processes in procedure B and procedure search or do I have to put lock inside B and search as well? (to the places marked with 2 & 3). Which is the right place 1, 2, 3 or all?

By the way my app is single writer & multiple reader type. So shared_lock makes to much difference in my case or is it ok to go with scoped_lock ?

Note: I'm using visual c++ in visual sturdio 2008 environment

Thanks...

Answer 1

scope of scoped lock is within the scope, so:

X(){

}

Y(){
    boost::mutex::scoped_lock(mut);
    X();
}

means that when you call Y() , mutex will be locked also during execution of X , but only when X is called from Y .

Answer 2

boost::mutex::scoped_lock lock(mutex);

Creates an object with automatic storage (aka a regular local variable). This object locks the mutex you pass it on creation, and unlocks it on destruction. Since the object has automatic storage, it gets destroyed (and thus the mutex gets unlocked) when it goes out of scope.

Concretely, it means that yes , if you put the scoped_lock statement above at the ******* 1 ******** marker in your code, the mutex will be held until A() returns, so the execution of B will also be protected by the lock (in this context).

void A ()
{
   myData data;
   // prepare data here

   boost::mutex::scoped_lock lock(mutex);
   // whatever happens from here ....

   doSomeStuff();

   B(data); // assume this perform some operations

   doMoreStuff();

   // ... to here is protected by the lock
}

This programming idiom is named RAII, for "Resource Acquisition Is Initialization", and you can learn more about it in here: What is meant by Resource Acquisition is Initialization (RAII)?

Side-note: as of C++11, the STL now includes mutexes and locks, so you do not need to use boost for this. The equivalent statements are:

std::mutex a_mutex;
{
    std::lock_guard<std::mutex> a_lock(a_mutex);

    // mutex is locked until the end of this scope
}