Re: [Threads-devel] Mutexes

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2006-03-06 04:50:14

>On Monday 06 March 2006 20:35, Anthony Williams wrote:
> >David Abrahams <dave_at_[hidden]> writes:
> >> Matt Hurd <matt.hurd_at_[hidden]> writes:
<snip>
> >> boost::recursive_timed_mutex::scoped_timed_lock
> >>
> >> Such specification is crying out for a different, policy like interface.
> >
> > Why?
>
> boost::scoped_lock<boost::mutex>
> boost::scoped_lock<boost::try_mutex>
> boost::scoped_lock<boost::timed_mutex>
> boost::scoped_lock<boost::recursive_mutex>
> boost::scoped_lock<boost::recursive_try_mutex>
> boost::scoped_lock<boost::recursive_timed_mutex>
>
> boost::scoped_try_lock<boost::try_mutex>
> boost::scoped_try_lock<boost::timed_mutex>
> boost::scoped_try_lock<boost::recursive_try_mutex>
> boost::scoped_try_lock<boost::recursive_timed_mutex>
>
> boost::scoped_timed_lock<boost::timed_mutex>
> boost::scoped_timed_lock<boost::recursive_timed_mutex>
>
> Would seem cleaner to me. Yes, the lock implementation depends on the mutex
> type, but it avoids duplication. IIRC, the current/old boost threads
> implementation does exactly this under the covers, relying on some kind of
> lock_traits stuff. I think it would make sense to expose this to the users.

Yes, that does seem a better interface.  I'm not sure if the scoped should 
remain as part of the name as I don't think it makes sense to have a 
non_scoped lock.  Better to allow a shared_ptr<lock<mutex> > as the 
non_scoped lock which hopefully will discourage its use ;-)

> Of course, if you tried to compile boost::scoped_timed_lock<boost::mutex>,
> then this would fail to compile.

I think so too, but you could make the argument that a mutex may support more 
than one locking interface and boost::timed_lock<boost::mutex> might make 
sense then but that might be asking for too much trouble especially 
considering a critical section based window mutex wouldn't support a timed 
interface out of the box.

Regards,

Matt.