Re: [Boost-users] question about threading library

Subject: Re: [Boost-users] question about threading library
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-11-07 11:57:13

Thanks for this information.

I appreciate the effort you've put into this, and I have
a lot of confidence in the library.  But I feel it would be more
useful to me and others  if it were it to have a lot more tutorial type
documentation and examples.

Robert Ramey

Anthony Williams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>> I want to use the boost threading library in an application.
>>
>> Looking through the documentation, I have a questions.
>>
>> a) in the examples I find "boost::mutex::scoped_lock" but
>> I don't find this in the documentation.  It looks like this
>> is called "lock_guard".  What should I be doing here.
>
> boost::mutex::scoped_lock is provided for backwards compatibility. It
> is a typedef for boost::unique_lock<boost::mutex>.
>
> I suggest using lock_guard unless you need backwards compatibility
> with boost 1.34 or earlier, or need the flexibility provided by
> unique_lock.
>
>> b) Its not clear to me how unique_lock(Lockable l)
>> is different than using lock_gard(..) or scoped_lock.
>
> lock_guard is a lightweight wrapper that *always* owns the lock. It is
> not movable, and doesn't support try_lock, timed locks or
> unlock/release.
>
> unique_lock is a more fully-featured lock owner. It supports the full
> Lockable interface (including try_lock and timed_lock), so you can
> pass it to boost::lock. Ownership can be transferred between
> unique_lock instances, and a given instance may or may not have an
> associated mutex, and may or may not own the lock on its mutex.
>
> You can also use unique_lock with condition variables, which you can't
> do with lock_guard.
>
> scoped_lock is just a typedef to unique_lock in most cases.
>
> Anthony