Boost logo

Boost :

From: Preston A. Elder (prez_at_[hidden])
Date: 2007-11-16 08:40:11

On Wed, 14 Nov 2007 16:41:12 -0500, Howard Hinnant wrote:
> I'm not sure I see the purpose of:
>> exclusive_mutex_view smv(smtx);
>> exclusive_mutex_view::scoped_lock sl(smv);
> because actually unique_lock<shared_mutex> should work just fine (and
> has semantics similar to what you indicate for exclusive_mutex_view).
> And condition_variable_any::wait works with unique_lock<shared_mutex>
> just fine as well. That covers exclusive locking for shared_mutex.

This was just for completeness. If I was going to have something_view
for the others, I may as well have one for exclusive, even if its

> For shared locking what you have for shared_mutex_view is very similar
> to the shared_lock<Mutex> template proposed here:

Good to know - this is why I asked. I figured a more complete and well
thought-out system (I knocked the above file out in about 10 minutes) was

Thanks for the info.

> upgrade_mutex mut;
> unique_lock<upgrade_mutex> lk(mut);
> // mut exclusive locked here
> shared_lock<upgrade_mutex> slk(move(lk)); // mut share locked here

This is nice, but:
1) I can easily see the terms shared_mutex and shared_lock getting
2) shared_lock and upgrade_lock are both templates - which is not so bad
by itself, a simple typedef can make 'concrete' versions. But it looks
weird to do unique_lock<shared_mutex> or
unique_lock<shared_lock<shared_mutex> > for example.
3) The implementation as specified uses c++-0x features, and the
liklihood is 1.35 will be released before c++-0x, and most compilers will
not support these features soon (yes, I know GCC will next version). So
we need a solution that does not use things like rvalue reference.
And 4) none of these interfaces have a scoped_lock / scoped_try_lock /
scoped_timed_lock typedef in them. Many people (myself included) are
used to the interface of boost::lock_type::scoped_lock sl(lock); I don't
know if this is being deprecated or not, but it is very prevalent.

> void wait_in_shared_ownership_mode()
> {
> // ...
> } // mut is now unlocked
> void wait_in_unique_ownership_mode()
> {
> // ...
> } // mut is now unlocked
> upgrade_mutex mut2;
> void wait_with_transfer_from_unique_to_shared_ownership() {
> // ...
> } // mut2 is now unlocked

All of these though can be achieved without c++-0x. The equivalent in my
interface is to create a shared_mutex, and then create one of my view
classes (which just hold a reference). I called them views because they
don't hold any data themselves, but are used to treate the shared_mutex
in a specific way (ie. as a shared-only lock, etc). All of mine work
with conditions just as this interface and could easily be templatized to
work with anything supporting the shared_mutex interface easily enough.
But it doesn't require c++-0x :)

So my original question stands, is there something coming in
boost::thread that will work with existing compilers that implements the
functionality of either my link or Howard's for boost 1.35? and if so,
when will we get to play with it (or at least see something close to the
final interface, even if not exact)?

PreZ :)

Boost list run by bdawes at, gregod at, cpdaniel at, john at