Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-22 13:28:24

I responded to Lie-Quan Lee's original message in private e-mail 
because a delay here caused me to not realize that he'd posted to 
this list as well.  His response here seems appropriate for the list 
as well, and may have been intended to be, so I'm responding here 
this time.  Sorry for any confusion caused here.

>From: Lie-Quan Lee <llee1_at_[hidden]>
>Reply-To: llee1_at_[hidden]
>To: "William Kempf" <williamkempf_at_[hidden]>
>Subject: Re: [boost] Re: Boost.Threads draft library submission
>Date: Thu, 22 Mar 2001 12:31:04 -0500
>
>At Thu, 22 Mar 2001 11:19:09 -0600,
>William Kempf 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.
> >
> > Pthreads don't allow for timed locking.  So the condition 
variable is needed
> > for simulating this.  Further, pthreads don't have a standard 
recursive
> > mutex type (the next standard will, but we have to deal with older
> > implementations as well, and the next standard leaves usage of 
recursive
> > mutexes with condition variables in a rather poor state in 
comparison to the
> > Boost.Threads implementation).
> >
> > >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 pthread standard has a "checked 
mutex"
> > variant that does this same thing as well.
>
>Good. Maybe you should mention the exact safety provided in the
>corresponding documentation.
>
>Another point, I saw you reuse fast mutex in mutex impl for windows
>part. As a matter of fact, both windows part and pthread part shared
>the most of code except geting thread id and call condition.  Maybe
>the mutex impl could be just one by reusing fast-mutex and condition
>and having a unified way to get thread id.

If I follow what you're saying here, I was unable to implement the 
pthreads version using boost::fast_mutex because of the way that 
boost::condition is implemented.  It works with the Win32 
implementation because boost::condition for Win32 is fully hand 
created and is not reliant on a specific mutex type.

>This leads me to another thought, is anyone intrested in having boost
>thread manipulation interface?  Bill's submission only has
>synchronization part now.

The documentation points out that the "thread manipulation interface" 
is planned for Phase 2.  This interface is going to be *MUCH* more 
complex than the synchronization interfaces and is going to take some 
time to hammer out.  In the mean time there is serious need for 
synchronization interfaces for other Boost libraries to insure thread 
safety even though they don't use threads themselves.  We already 
have at least one accepted submission that "rolled it's own" mutex 
concept for this purpose.  This is the reasoning behind the Phased 
approach to this library.

Bill Kempf