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.