[boost] Threads

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-04 13:39:01

Hi,

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?

Now these are obviously extremely ignorant questions and it is likely
that you will explain to me what these "mutexes" are for. Great! This
is what we need *first* to determine how to address the problem in the
first place. Whether mutexes are the right tool to deal with the
problem will be seen once we know at least the problem. The assumption
how to solve the problem before even knowing the problem is almost
certainly fatal. Although it was already considered not to be the best
approach to multi-threading but as an example let me note that Java
apparently has no mutex class and deals with synchronization
differently (yes, I know that it is built into the language but without
knowing what the problem is we will not be able to determine whether
mutexes and intrinsic language support are the only two alternatives).

At least I haven't asked for definitions but for some agreement on what
we want to deal with. ... and actually the mail which spawned this
thread contained a rather arbitrary bunch of stuff addressing a diffuse
variaty of problems. For example, thread synchronization and thread
lifetime maintainance are rather separate issues! Still, I really
appreciate the restart of the discussion and in some form I also
appreciate the hurry because it forces me to think and write about the
stuff *now* and not later [when it is likely not to happen...]

The insistance on the basic work (which I also don't like; I *love* to
just hack away) is not to block the progress but to avoid the necessity
of legacy maintainance: We do not win anything to define the interface
for a mutex in hurry just to later find out that we don't want mutexes
at all! ... or that we try to maintain nearly unimplementable
requirements like having multiple threads before even reaching 'main()'
although we also describe idioms making this stuff unnecessary anyway.

There are lots of questions we have to answer before even naming the
entities used to address the various problems! Here are just a bunch of
them:

- What does multi threading safety mean at all to us? Probably there
  is actually more than one answer to this question with different
  needs for support. Here are three potential answers:
  - *Different* objects can be accessed simultaneously from different
    threads as long as two threads never try to access the same object
    simultaneously (that is basically, only internally shared resources
    are protected against paralell accesses).
  - An object can be accessed from multiple threads at the same time
    and the object will deal with the synchronization needs. Note, that
    this design has *huge* impacts on the design of the classes.
  - When accessing an object the user of the object has to acquire
    explicitly a lock on the object. Otherwise no thread safety is
    guaranteed.

- Will we support thread safety during program startup and termination
  and with what locking scheme do we support this? The style of access
  to objects during startup and termination might be different than
  during normal processing (eg. explicit locking using special locks
  during program startup). Can we provide this kind of support on all
  systems we are interested in?

- 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?)
  - There will be a 100% coverage of the system's threading support and
    access to the system's threading support always has to go through
    the Boost library to have things working (eg. because otherwise we
    cannot guarantee proper operation of your stuff).
  - We will just provide tools aiding in portability and providing
    better C++ support than the normally C style system threading
    support.

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

- 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.
  - We prevent that there can a dead lock arise.

Some of the answers are not exclusive and we might start with some sort
of support now and later add some form of layer which is used at some
kind of "higher" multi threading support with the "low level" support
being used internally.

Before these and probably a lot more related questions are answered I
don't see any point in discussing solutions to problems! The reason is
simply that without an agreement on the problem to be solved we won't
be able to come up with a solution acceptable to everybody. We should
have learnt from the "auto_ptr" fiasco! What started out as a resonable
solution to two similar looking problems (release a pointer at the
right time - for both cases) was modified into something of rather
questionable use and finally fixed to become a solution to only one of
the two original problems solved. Obviously, different people had
rather different problems in mind and agreed on a solution (at least at
some point) which didn't solve any of those!

Also note that I'm not seeking a completely new approach solving all
problems at once! I'm just seeking an agreement on the *problem* before
looking for a solution. Of course, I hope that we can come up with a
superior solution to the problem when going this direction but I would
not be opposed to a working solution even if it has some edges I don't
like.

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/