Re: [boost] More Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 14:02:14

"Iain K.Hanson" <iain.hanson_at_[hidden]> writes:

> > [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
> > Sent: 17 October 2002 17:55
> >
> 
> 
> > mutex_concept.html:
> >
> >   "When exceptions are thrown, it becomes nearly impossible to ensure
> >   that the mutex object is unlocked properly when using these
> >   traditional API's. The result is deadlock."
> >
> > Well, sort of. Isn't deadlock supposed to be when two threads are
> > waiting on one another to finish with some resource before proceeding?
> > Yes, that's how definitions.html specifies it.
> >
> > I think what happens if you fail to unlock a mutex is that the
> > resource becomes permanently unavailable**, which is rather different,
> > though the behavior may appear to be similar.
> >
> > **to other threads only, in the case of a recursive locking strategy
> 
> I don't think so. If your thread has destructed then it can not be
> re-created and therefore you can not ( from anywhere in your process )
> recover the leaked resource. 

Right, so how is that different from saying, "the resource (mutex)
becomes permanently unavailable to other threads than the one which
locked the mutex"?

> The effect is deadlock

It's not deadlock according to our definition of deadlock:

    "Deadlock is an execution state where for some set of threads,
  each thread in the set is blocked waiting for some action by one of
  the other threads in the set."

You can't possibly interpret that to cover the case where no thread ever
tries to lock the mutex again after the lock is leaked.

> - recursive mutex or not.

Since this can't be described in terms of our definition of deadlock,
I'm trying to describe which threads will block forever when trying to
lock it. Whether it's recursive or not affects which threads will
block forever when trying to lock the mutex.

> > It may be late to change this, but I'd like the most-convenient
> > names to correspond to the safer constructs. So, for example, I'd
> > prefer it if "recursive_mutex" were called "mutex" and if the
> > current "mutex" were called something else, though I can't think
> > of a good name. Neither "nonrecursive_mutex" or
> > "unspecified_locking_mutex" is very satisfying.
> >
> 
> And the trade off is that people who are familar with threads do not
> get the expected names. There was never any intention of this
> library becomming threads 'for dummy's' as that is not something
> that is possible.  By keeping the common names, we are in line with
> the common literature dating back decades, which every a newbie
> should consult before attempting and multi-threaded programming.

OK, fine. This should show up in the rationale, then.

> In general, I think you need to wait for definative answers from
> Bill Kempf because all of this was very heavily discussed at the
> time it was under development and he is probably the only one who is
> now authorative on the reasons for the descions made. Or you could
> go back and read the archive :-).

Or we could expand the rationale sections so we don't have to go
through this again.

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