Howard Hinnant <hinnant@twcny.rr.com> writes:
On Nov 2, 2006, at 3:23 AM, Anthony Williams wrote:
Agreed. So we would end up with mutex and recursive_mutex, yes?
Yes, though I like Howard's idea of recursive_mutex being an adaptor, with specializations for optimization.
Btw, recursive_mutex adaptor, if it is a good idea in the first place, is a good example of an application needing to lock a mutex in a non-scoped manner.
Only if you allow non-scoped locking of the recursive mutex adaptor. If you only allowed scoped locks, then the first scoped lock of the recursive mutex can check to see if this thread owns the mutex. If so, then the whole scoped_lock is a no-op. If not, then we need to actually lock the underlying mutex. template<class Mutex> class recursive_mutex { private: Mutex m; thread_util::id id; public: recursive_mutex(): id(thread_util::not_any_thread()) {} class scoped_lock { recursive_mutex& m; std::auto_ptr<typename Mutex::scoped_lock> lock; public: scoped_lock(recursive_mutex& m_): m(m_) { if(m.id!=thread_util::self()) // assume atomic read { lock.reset(new typename Mutex::scoped_lock(m.m)); m.id=thread_util::self(); } } ~scoped_lock() { if(lock.get()) { m.id=thread_util::not_any_thread(); } } }; };
Ion pointed out to me that recursive_mutex shouldn't hold a mutex&, but rather a mutex.
Yes. I always assumed it would be a type adaptor, not an instance adaptor.
I should also stress: recursive_mutex is an experiment, not a proposed solution. I'm just thinking out loud, and would like more help in the thinking department. :-)
Well, my Windows implementation of a recursive mutex is essentially just an adaptor on boost::mutex, so your thinking coincides with mine.
I was thinking about mutex, try_mutex and timed_mutex, which I think can really be one and the same class.
I've also been experimenting with a timed_mutex adaptor:
[snipped example impl] Intriguing thought. It's certainly doable, and can also be specialized to allow for optimization where the adapted mutex is already timed-capable.
This is even less mature than the recursive_mutex. But hopefully people can see where I'm trying to go: Instead of having recursive and timed flavors of every kind of mutex (exclusive, sharable, upgradable), one might instead have adaptors that one could apply to these, and perhaps to user-defined mutexes as well (more motivation for mutex concepts: here's more generic mutex code people could plug into).
I like the idea of providing adaptors so that behaviour can be added to basic mutexes. Maybe some traits or Concepts could be used to mean that people didn't have to explicitly specialize timed_mutex_adaptor<custom_mutex> if custom_mutex already supported timed locks. Your sample adaptor has given me the idea of not having an explicit timed_lock function, but rather overloads of try_lock: bool try_lock(); // just try once bool try_lock(unsigned spin_count); // spin this many times bool try_lock(target_time_type target_time); // wait until the specified time bool try_lock(time_period_type wait_time); // wait for the specified period Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk