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

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-18 16:34:13

"Hillel Y. Sims" <hsims_at_[hidden]> writes:

> "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)? 

I can only think of one (unlikely) reason: they don't want the mutex
locked while they execute some expensive operation which is part of
the full-expression containing the wait call (e.g. building the
predicate object).

However, that's not why I'm suggesting this. I'm suggesting it because
I think that functions specified to throw exceptions when the inputs
are inappropriate are generally difficult to work with and to think
about. If this is really meant to be a precondition, we should say
that and give implementations the freedom to assert if it is violated,
a more useful behavior. If it's not meant to be a precondition, we
ought to handle it ourselves. It makes the specification of the
function simpler, which is a GOOD THING in and of itself. It also
makes the function marginally more useful.

> 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.

What's the point of waiting if you don't think you're going to end up
with the lock at the end?

And what kind of followup logic could depend on an assumption that
it's unlocked?

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html