Boost logo

Threads-Devel :

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-06 10:30:45

Anthony Williams <anthony_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> writes:
>> Matt Hurd <matt.hurd_at_[hidden]> writes:
>>> The current models supported by boost are:
>>> boost::mutex::scoped_lock
>>> boost::recursive_mutex::scoped_lock
>>> boost::try_mutex::scoped_lock
>>> boost::recursive_try_mutex::scoped_lock
>>> boost::timed_mutex::scoped_lock
>>> boost::recursive_timed_mutex::scoped_lock
>>> boost::try_mutex::scoped_try_lock
>>> boost::recursive_try_mutex::scoped_try_lock
>>> boost::timed_mutex::scoped_try_lock
>>> boost::recursive_timed_mutex::scoped_try_lock
>>> boost::timed_mutex::scoped_timed_lock
>>> 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.

If you really want genericity, each of these should be followed by



> 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.

...why, though?

All this twiddling with the interface is basically aesthetic
manipulation whose value is in the eye of the beholder until there's
some clear use case that demonstrates its superiority.

I haven't seen a single example that demonstrates why the current
interface is deficient, and in fact all the alternative proposals have
clear disadvantages in verbosity and complexity.

Dave Abrahams
Boost Consulting

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at