From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-08-04 18:11:11
Dietmar Kuehl wrote:
> apparently you are in an extreme hurry and you want to start doing
> things at some more or less random point: Mutex? Who cares about
> mutexes? What is the point of a mutex?
I understand that ``mutex'' in this discution means ``any tool for
synchronisation''.
> Whether mutexes are the right tool to deal with the
> problem will be seen once we know at least the problem.
I think that ``mutex'' have been used to designate any solution
of the problem.
> - How do we interact with the system's threading support? Again, I can
> see multiple answers, some of them being (at least to me) plain
> ridiculous other rather sensible:
> - We don't interact with the system's thread support but provide the
> thread support ourself (eg. because we have to anyway?)
That's the road I took in MT++ (the URL is
http://www.eleves.ens.fr:8080/home/bonnard/NewLibs/Para/MultiThread/doc/MT.html
)
> - There will be a 100% coverage of the system's threading support
And you know that it's impossible and write warpers for an
arbitrary and unknown system.
> - What is the goal of our threading library anyway? Here are two
> radically different answers:
> - We want a library to be used for the implementation of the Boost
> components.
> - We want to give the user a portable approach how to create and
> maintain threads.
I would prefer to have both.
> - We indeed use a mutex, how do we deal with dead locks?
> - We don't because there is no such thing like a dead lock (yes, I'm
> dead serious and I really mean it):
> - We detect the dead lock and terminate the program.
> - We detect the dead lock and break the tie in some form.
In many (most ?) cases there are no ways to detect the deadlock.
> - We prevent that there can a dead lock arise.
You forgot:
- The programmer ensures that no deadlock arise
-- Valentin Bonnard