Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-01-31 18:39:33

On Thu, 31 Jan 2002, bill_kempf wrote:
willia> mutex_private_accessor(mutex).lock();
willia> vs.
willia> lock_ops<boost::mutex>::lock(mutex);
willia> The only benefit is that you no longer have to specify the type.

I agree that is the only benefit. I think it is a very nice benefit. We do
this sort of thing throughout the iterator adaptor library to make the
notation nicer. Writing out types can be a real pain sometimes.

willia> The same thing could be done by making lock_ops a non-template class
willia> with template members, though:
willia> lock_ops::lock(mutex);

Sure. But I still like the other one better.

willia> > willia> The real issue here is actually how to interact with
willia> > willia> boost::condition, however. I can't quite see how to
willia> document this
willia> > willia> well enough in the public interface to allow for mutex
willia> extensions
willia> > willia> that work with the condition variable.
willia> >
willia> > Hmm, I'd have to understand the problem better...
willia> The boost::condition::wait() (and timed_wait()) operations make use
willia> of private lock/unlock methods in the mutexes that take a cv_state
willia> reference. The cv_state is a nested type that's platform specific.
willia> On the Windows platform it holds state information such as the number
willia> of nested locks for a recursive_mutex. The POSIX stuff holds this
willia> state information as well as a pointer to the pthread_mutex instance
willia> that's used in the call to pthread_cond_wait(). So the state
willia> information is mostly specific to the mutex type, but also requires
willia> certain information on some platforms regardless of the mutex type.
willia> Simply leaving it as is (i.e. an implementation detail) prevents
willia> users from creating new mutex types, such as a named_mutex, which can
willia> be used with boost::condition. But I don't know how to modify this
willia> design so that platform specific information isn't exposed to the
willia> user.

I don't see a real problem with having this exposed in the
mutex_private_accessor interface. That's plenty of warning to people that
they shouldn't mess around with it unless they know what they are doing.


 Jeremy Siek
 Ph.D. Student, Indiana Univ. B'ton email: jsiek_at_[hidden]
 C++ Booster ( office phone: (812) 855-3608

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