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]>
>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
> > > > > implemented by two pthread mutex and one condition
> > > > > 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.
> > >asked this since you did not mentioned this change in the
> > >message. Sorry.
> > >
> > >However, could you explain a little bit why a single pthread
> > >cannot serve the purpose? You used a pthread mutex and a
> > >vairable.
> > Pthreads don't allow for timed locking. So the condition
variable is needed
> > for simulating this. Further, pthreads don't have a standard
> > mutex type (the next standard will, but we have to deal with older
> > implementations as well, and the next standard leaves usage of
> > 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
> > >thread other than mutex owner to release mutex. If that does
> > >exception lock_error is thrown. I see the mutex documentation
> > >"safety". That is the safety provided. Is that right?
> > That's part of it, yes. The next pthread standard has a "checked
> > variant that does this same thing as well.
>Good. Maybe you should mention the exact safety provided in the
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk