Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-22 22:54:23

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:
> At Thu, 22 Mar 2001 22:31:30 -0500,
> Rich Lee wrote:
> > 
> > At Thu, 22 Mar 2001 11:19:09 -0600,
> > William Kempf wrote:
> > > Pthreads don't allow for timed locking.  So the condition 
variable is needed 
> > > for simulating this. 
> > 
> >   Ok. To simulate timed locking, you need a condition
> >   variable.  However, norm locking (do_lock) does not need to 
wait on 
> >   the condition, does it?
> > 
> 
> What I means is, maybe there is a way to have two different
> do_unlock(), one for norm locking, the other for timed
> locking. Somehow they could match well and let norm locking not to
> wait on the condition.

I'm not quite following.  A "norm lock" does not wait on the 
condition at all.  It's only inefficiency in comparison to standard 
pthread mutexes is that it both locks and unlocks the internal mutex, 
as the lock state is tracked by other means.  I'm not sure that this 
can be optimized out any differently considering the need for the 
timed lock, but if you've got a solution I'm more than willing to 
look at it.

Bill Kempf