Sign in to follow this  

[C++, boost] Quick question about mutexes

This topic is 3660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It is a pretty noob question, but if I have a mutex around a block of code, does that just prevent multiple threads entering this block of code at the same time? Or does it also lock variables used in the block? For example:
public class A
{
 private:
  int x;
 public:
  int getX()
  {
   boost::mutex lock;
   return x;
  }
  void setX(int x)
  {
   boost::mutex lock;
   this->x = x;
  }
};
In order for this class to be properly thread safe, I need to stop a thread reading x while it is being updated. Does my example do this, or does it simply make the setter thread-safe? My real example is a container, where one thread can insert into the container and another can remove from it. For example is this thread safe?
public class ThreadSafeStack
{
 private:
  List list;
 public:
  void push(int x)
  {
   boost::mutex lock;
   list.push(x);
  }
  int pop()
  {
   boost::mutex lock;
   return list.pop();
  }
};

Share this post


Link to post
Share on other sites
I don't know boost::mutex's,
I don't see how the local variable will be connected to the other local variable, so I guess you are protecting each function alone, if the mutex class automatically locks and unlocks.

I am guessing proper use will be something along:

class A
{
private:
boost::mutex mut;

public:
void Set(value)
{
mut.lock();
// set stuff
mut.unlock();
}

value Get()
{
mut.lock();
// get stuff
mut.unlock();
}
};

Share this post


Link to post
Share on other sites
Boost mutexes don't allow you to explicitly lock and unlock. Essentially the constructor calls lock() internally and the destructor calls unlock() internally - it's very nice as it means the lock automatically dies at the end of the function.

Reading the docs again it seems to suggest that *this is what gets locked. But does that mean the mutex, or the class containing the method using the mutex?

Can anyone comment further?

Share this post


Link to post
Share on other sites
Boost is magic.. but its not a miracle

No, the mutex will not lock class members

what you should do to make the class thread safe is to create get/set methods and then have one or more mutexes that lock the properties

Share this post


Link to post
Share on other sites
Quote:
Original post by d000hg
Boost mutexes don't allow you to explicitly lock and unlock. Essentially the constructor calls lock() internally and the destructor calls unlock() internally - it's very nice as it means the lock automatically dies at the end of the function.

Reading the docs again it seems to suggest that *this is what gets locked. But does that mean the mutex, or the class containing the method using the mutex?

Can anyone comment further?


I haven't used any of boost's threading facilities, but I think you've missed a bit.

What you want is the mutex to be a class member, as Iftah suggested. However, according to the documentation, boost::mutex provides an inner class, boost::mutex::scoped_lock, which takes a mutex reference to its constructor. It is the scoped lock whos constructor locks and destructor unlocks the mutex:

class ThreadSafeStack
{
private:
List list;
boost::mutex mutex;
public:
void push(int x)
{
boost::mutex::scoped_lock(mutex);
list.push(x);
} // mutex is unlocked here

int pop()
{
boost::mutex::scoped_lock(mutex);
return list.pop();
} // mutex is unlocked here
};


Share this post


Link to post
Share on other sites

This topic is 3660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this