[boost] Re: Re: Re: More on Boost.Threads

From: Hillel Y. Sims (hsims_at_[hidden])
Date: 2002-10-18 16:24:49

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ufzv4ahj4.fsf_at_boost-consulting.com...
> "Hillel Y. Sims" <hsims_at_[hidden]> writes:
>
> > >      template <class ScopedLock, class Predicate>
> > >      wait(ScopedLock& lock, Predicate pred)
> > >      {
> > >          if (!lock.locked())
> > >              lock.lock(); // instead of throw
> > >          while (!pred())
> > >              wait(lock);
> > >      }
> > >
>
> > (Anyhow, how do you have a reference
> > to a ScopedLock object without already holding the lock, except by
> > malicious intent?)
>
> By explicitly unlocking it, I guess.
>

Well, yeah. I guess I don't understand if they already have (by necessity)
acquired the lock, why would anyone purposely unlock it before calling
cv.wait() (other than it being a logic error)? And if they accidentally
unlocked it before calling wait(), now it is locked again after coming back
out, which seems like it could likely throw off whatever (probably incorrect
also) followup logic in the caller which is assuming that it's unlocked.

>
> > (I like the notion of predicate-based wait() wrapper though, might help
to
> > eliminate some confusion over whether/why one should say "while (!pred)
> > cv.wait()" vs. "do { cv.wait() } while (!pred)".)
>
> <confused> We already have a predicate-based wait wrapper, don't we?

Sorry, I was just agreeing that I like the idea. :-) Also Peter's followup
that takes a function object... very nice encapsulation, makes me think of
Ada protected entries almost.. (Also I guess it has also been pointed out
that "do { cv.wait() } while (!pred)" style is valid under certain
circumstances.)

hys

--
Hillel Y. Sims
FactSet Research Systems
hsims AT factset.com