Re: Boost.Threads draft library submission

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

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:
> At Thu, 22 Mar 2001 16:15:20 -0000,
> Bill Kempf wrote:
> > 
> > --- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:
> > > Hi Bill,
> > > 
> > >    Is any particular reason why a boost mutex in your code is
> > >    implemented by two pthread mutex and one condition variable? 
I
> > >    recalled that I saw a comment on this but I did not see a 
> > followup.
> > > 
> > >    Thanks!
> > 
> > Check out the latest upload.  This is not the case any more.
> > 
> 
> I downloaded the latest zip. Yes, your implementation changed.  You
> asked this since you did not mentioned this change in the previous
> message. Sorry.
> 
> However, could you explain a little bit why a single pthread mutex
> cannot serve the purpose? You used a pthread mutex and a condition
> vairable. 

The pthreads standard doesn't allow for timed locks, so the condition 
is needed to simulate this functionality.  Further the pthreads 
doesn't currently supply a recursive mutex variant, and the next 
standard that will does a poor job of defining usage with condition 
variables while the Boost.Threads implementation deals nicely with 
this.

> It looks like the mutex implementation try to protect a case that a
> thread other than mutex owner to release mutex. If that does happen,
> exception lock_error is thrown. I see the mutex documentation 
metioned
> "safety". That is the safety provided. Is that right?

That's part of it yes.  The next pthreads standard will also contain 
a "checked mutex" variant as well that would work here if not for the 
lack of timed locks.

Bill Kempf