RE: [boost] More Threads Review

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-10-17 13:54:04

> [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. The effect is deadlock - recursive mutex or
not.

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

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

/ikh