Re: [boost] More Threads Review

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-10-18 06:39:47

>From: David Abrahams <dave_at_[hidden]>
>"Iain K.Hanson" <iain.hanson_at_[hidden]> writes:
> > > [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
> > > Sent: 17 October 2002 17:55

Sorry, I'm not ignoring this thread, just EXTREMELY busy. I'll answer the 
questions as I find time, which may look like I'm ignoring, but I'm not.  
I'll even summarize everything at some point.

> > > 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 maybe the definition needs some tweaking.  A deadlock occurs when a 
thread waits on a resource that it can never acquire.  This case, where a 
thread simply never releases the resource, most certainly can result in 
deadlock.

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

In what ways is this case different?  Even disregarding the effect?

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

Did you mean precisely this?  If so, that points out that the sentence 
should have read "The result is likely deadlock.", rather than the 
certainty... but I think maybe you didn't mean precisely what was written 
here, since it's a different take on this then what you've made previously.

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

How so?

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

There's also the fact that recursive_mutexes have several negative qualities 
making them the less preferred types.  And yes, we need vastly expanded 
rationale for everything.  That's something I'm working, and comments like 
these will certainly help.

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

Yep.

Bill Kempf

_________________________________________________________________
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp