Boost logo

Boost :

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.


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