Re: [boost] [thread] is there an interest on this unique_to_shared_mutex_adapter class?

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-05-09 13:06:37

vicente.botet wrote:
> template <typename Lockable>
> class shared_lockable_adapter
> {
>     shared_lockable_adapter(Lockable& mtx): mtx_(mtx) {}
>     ~shared_lockable_adapter() {}
>     void lock_shared() {mtx_.lock();}
>     void unlock_shared() {mtx_.unlock();}
>     bool try_lock_shared() { return mtx_.try_lock();}
>     void lock() {mtx_.lock();}
>     void unlock() {mtx_.unlock();}
>     bool try_lock() { return mtx_.try_lock();}
>     // other functions ....
> private:
>     Lockable& mtx_;
> };

So this is a trivial adapter that makes a shared mutex that can't 
actually be shared.

It would also be possible, I think, to make an adapter that actually 
creates a shared mutex from a normal one.  I've never had to write a 
read/write mutex but I guess that this is how they are implemented internally.

There are various usage scenarios.  For example, I may have a generic 
algorithm that really needs a shared lock that can be shared, i.e. it 
creates threads that must run concurrently.  If I concept-check that 
the passed mutex is a SharedLockable, but it's actually your adaptor, 
I'll get a runtime deadlock.  Maybe we need some more fine-grained 
concepts to express these requirements.

Certainly it would help if algorithms could work with both shared and 
non-shared mutexes without extra effort.  I'm not yet aware of much 
generic code that uses mutexes and lock concepts.  No doubt we will 
learn more as that code appears.

Phil.