$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-01 10:20:36
--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Thu, 31 Jan 2002, bill_kempf wrote:
> 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.
The problem is that it requires intimate knowledge of the 
implementation of boost::condition.  Unlike the normal lock 
operations, there's nothing portable that you can do with the 
cv_state versions using nothing but documented interfaces.
Bill Kempf