Re: A Quick Question about Threads

From: Mark Sizer (yg-boost-users_at_[hidden])
Date: 2003-07-31 14:44:31

I just did this, it's remarkably easy. I then ported the system to Linux 
from Windows with no problems at all. Boost Threads rock. That being said...

Be very careful about confusing object lifetime with thread lifetime. 
The relationship is murky, at best. I can start a thread on a stack 
based object. When that object goes out of scope, the thread does not 
stop. I can start a thread on a heap based object, when the thread 
terminates, the object is not deleted.

That being said, I use the method you describe. Just make sure your 
object doesn't go out of scope or get deleted.

I found the synchronization stuff strange, at first. Now I love it, it's 
much less error prone than critical sections or mutexes.

You use a combination of mutexes and locks. The mutex is used only to 
acquire the lock, which is the only way to use the mutex. Locks, at 
least scoped_lock, release the mutex when they go out of scope.

After much debate, we adopted the following coding standard:

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

   // do whatever

}

It makes it very clear what the locked section is, even if the "open 
brace then code on one line" is a bit strange. Also after much debate, 
we decided to never explicitly unlock. With this scoping convention, 
it's both redundant and obscuring (e.g. auto-release on an exception 
prior to the unlock call).

I deleted tons of:
try
{
   critical_section.lock();
   // do whatever
   critical_section.unlock();
}
catch (...)
{
   critical_section.unlock();
   throw;
}

Have fun,
  - Mark

Paul Grenyer wrote:

> Hi All
> 
> I'm planning on replacing all our (Win32 API Wrapped) threads with the
> boost threads.
> 
> I was looking at the thread class interface and there isn't a method to
> ask if the thread is still running. This is something we use quite a lot
> in out current wrapper. To get around this I was thinking of using a
> member variable in the function object that is passed to the thread
> constructor to indicated whether the thread had finished. Is there a
> better way?
> 
> I've not had a really good look at the docs yet, but there doesn't
> appear to be a Critical Section class. Should I be using the Mutex for
> synchronisation instead?
>