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.