boost mutex locks

[mike_wilson]

Hi,

I am a newbie to C++ multi threading (did a bit in java) and would like for information on the following...

consider:-

class MyClass
{
   void SetMyObject(SomeClass const& value)
   {
      boost::mutex::scoped_lock lock(objectMutex);
      myObject = value;
   }
   SomeClass SetMyObject() const
   {
      boost::mutex::scoped_lock lock(objectMutex);
      return myObject;
   }
private:
   SomeClass myObject;
   boost::mutex objectMutex;
};


Say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the  GetMyObject()  blocking any other thread from calling?

This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?

Thanks again for your help.

[Matheus Araújo Aguiar]

Hello,

On Wed, Jul 15, 2009 at 8:53 AM, mike_wilson <me95mlp@...> wrote:

Hi,

I am a newbie to C++ multi threading (did a bit in java) and would like for
information on the following...

consider:-

class MyClass
{
  void SetMyObject(SomeClass const& value)
  {
     boost::mutex::scoped_lock lock(objectMutex);
     myObject = value;
  }
  SomeClass SetMyObject() const
  {
     boost::mutex::scoped_lock lock(objectMutex);
     return myObject;
  }
private:
  SomeClass myObject;
  boost::mutex objectMutex;
};


Say one thread accesses the SetMyObject() , given that there is a lock in
the function, it will also lock the  GetMyObject()  blocking any other
thread from calling?

Yes. Since you use the same mutex in both methods, whenever a thread constructs the lock with the mutex, another thread that later constructs other lock using the same mutex will be blocked until the mutex is unlocked, or in other words, until the lock object is destructed (in your code that happens when the methods 'get' and 'set' ends).

 

This kind of implies that wherever in the object there is a lock, any
function owned by the object will be locked to any other thread trying to
access. Is this correct?

In the code you submited above, yes. But note that the lock object performs locks and unlocks on a given mutex. So if you use different mutexes in different methods, you'll get some other behaviour.

 

Thanks again for your help.
--
View this message in context: http://www.nabble.com/boost-mutex-locks-tp24406812p24406812.html
Sent from the Boost - Users mailing list archive at Nabble.com.

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

PS: in the code you submited, the 'get method' is named SetMyObject. No trouble for me understanding that and ignoring it, but other people may be more picky.

Regards,

--
Matheus Araújo Aguiar
Computer Scientist
matheus.pit@...

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Igor R]

> Say one thread accesses the SetMyObject() , given that there is a lock in
> the function, it will also lock the  GetMyObject()  blocking any other thread from calling?

Yes. To be more exact, it will block even if you try to access
GetMyObject() from the same thread.

> This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?

I don't know what you mean by saying "function owned by the object",
but the mechanism works as follows: when boost::mutex is locked, any
additional attempt to lock it would block. Where to put a mutex and
where to lock it - all these are matters of a higher-level design.
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Rush Manbert]

On Jul 15, 2009, at 4:53 AM, mike_wilson wrote:

<snip>

> Say one thread accesses the SetMyObject() , given that there is a  
> lock in
> the function, it will also lock the  GetMyObject()  blocking any other
> thread from calling?
>
> This kind of implies that wherever in the object there is a lock, any
> function owned by the object will be locked to any other thread  
> trying to
> access. Is this correct?
>

You are correct. There is, however, a variant of mutex that allows for  
multiple readers to hold the lock simultaneously, but there can only  
be a single writer. All readers or other writers are locked out until  
the writer releases the lock. But if you mostly read this can reduce  
contention.

- Rush

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users