Re: Threads: New Win32 Implementation

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-08 16:44:34

--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: William Kempf <sirwillard_at_m...>
> > --- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> > > From: William Kempf <sirwillard_at_m...>
> > > I agree that throwing an exception is a much safer interface, 
and
> > > reasonably clean to use.  I don't see that this
> > > 
> > >    try {
> > >       mutex::try_lock tlk(mx);
> > >       cond.wait(tlk, ...);
> > >       DoSomethingInteresting();
> > >    } catch (failed_try) {
> > >       DoSomethingElse();
> > >    }
> > > 
> > > is any harder to write than this
> > > 
> > >    mutex::try_lock tlk(mx);
> > >    if (tlk)
> > >    {
> > >      cond.wait(tlk, ...);
> > >      DoSomethingInteresting();
> > >    } else {
> > >      DoSomethingElse();
> > >    }
> > 
> > The real issue is performance.  Exceptions are expensive, and the 
> > main reason to use a try lock is to try and eke out the best 
possible 
> > performance (there's other reasons, yes).  It might be nice to 
have 
> > multiple types of try locks, compile time options on behavior, or 
to 
> > make use of the nothrow concept of new.  We've been down this 
road 
> > before, so I don't expect a concesus of opinion on this one yet, 
but 
> > I bet we come back to this at some point.
> 
> I'm not that sold on the need for try_lock at all, so I'm
> not that concerned about performance.  Timeouts are another
> matter.

A try_lock is just a timed_lock constructed with a 0 timeout.  So 
conceptually we don't need try_locks.  However, many thread libraries 
that we'll be based on don't have timed locks for mutexes.  This 
makes a try_lock trivial to implement and efficient, but a timed lock 
more difficult and probably not very efficient.  I think the idea 
right now is to allow the Mutex concept to have leeway for simply not 
having a timed_lock to satisfy those platforms where there isn't a 
native timed lock.  Whether this is actually allowed in 
implementations of "the standard library" is debatable, but I think 
the concept of a TryLock is appropriate here.

> Nevertheless, if performance and safety both matter couldn't
> we do some like the following?
> 
>     mutex::try_lock tlk(mx);
>     if (cond.wait(tlk, ...))
>     {
>       DoSomethingInteresting();
>     } else {
>       DoSomethingElse();
>     }

mutex::try_lock tlk(mx);
// do some preliminary work
if (cond.wait(tlk, ...))
{
   // do something interesting
}

The "undefined behavior" occurs at the first comment.  You'll 
probably suggest that we combine the lock and the wait again to 
prevent code from being there, but I really don't think we can do 
that.  There may well need to be some preliminary work before you 
wait, such as simply checking to see if it's valid to even be calling 
the method in question before wasting time waiting for some condition 
to occur.

As long as you check the lock you're safe.  Fail to check the lock 
and we have anything from a race condition to a deadlock to simple 
undefined behavior, depending on what you do next.  An exception 
solves this, and I prefered that from the beginning, but I can see 
why others don't like it.

Bill Kempf