Re: [boost] Threads

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-02 07:31:51

Hi,

--- Jon Jagger <jon.jagger_at_[hidden]> wrote:
>      I'm also reminded of the old primitive/idiomatic
>      duality. For example, you don't _need_ empty()
>      in a container class, you could use length()==0.
>      But empty() is provided because it's sufficiently
>      common and hence idiomatic. So, are read/write locks
>      sufficiently common? I think they are. And if
>      you don't provide them you have a self-fulfilling
>      prophesy that they won't become common...

Like for 'empty()' I think there is even more to it: 'empty()' can be
much more efficient than 'length()' because 'length()' might have to
count the number of elements in a container (eg. the SGI 'std::list'
does not store the element count). Similarily, some systems might
provide certain thread synchronization mechanisms with a very efficient
implementation, eg. because there is a corresponding CPU instruction
available. Thus, support for common idioms should probably be provided
with a default implementation using just one globally  available
synchronization mechanism, eg. using mutexes (don't confuse 'CMutex'
with "real" mutexes: The class 'CCriticalSection' is what is normally
called a "mutex" and a "critical section" is the code protected by it;
that is, I don't want to propose a performance hog for MS Windows
systems by suggesting to use a mutex).

Let me also note again, that we should really start of with the goals
we want to achieve! I think we should care about the techniques and
related idioms to make classes "collaborative thread safe" (I don't
know whether there is term for this). That is, classes should be made
thread safe in the following sense:

- Using independent objects of the class from different threads does
  not cause a problem, even if the user does not care about any form of
  synchronization. That is, internally referenced resources shared
  between different object (eg. the memory allocation pool) are
  accessed in a thread safe manner.

- Using the same [sub-] object from different threads requires some
  form of synchronization to be done by the user, that is, the objects
  do not defend themselves from simultaneous accesses (basically
  because either they can't and even if they can, it won't help
  anything).

More details on this can be found at
<http://www.sgi.com/Technology/STL/> in the section on papers. If there
is a deviation from what I have said, the paper on thread safety is
probably what I really mean :-)

If we can agree on this goal (maybe we should take a vote on how to
address this issue with this, or a variation thereof, being one of the
options), we can move on and start about thinking how to support this.
This is where the techniques, idioms, and eventually the classes aiding
in this work drop in.

Also note that I'm actually merely talking about the *interface* to the
corresponding classes, not their implementation: There might be an
implementation available from Boost but the important goal is to have
the tools available to implement classes in a thread safe manner. The
corresponding interfaces can then be plugged into some suitable thread
library. That is, the Boost classes become independent from the
underlying threading library used and it should only be a matter of a
little typing exercise to port the threading code to a new threading
library. This does, however, not work if we try to address the whole
multi threading issue including thread life time (creation, suspension,
termination, etc.), thread scheduling, etc.: The models for this are
too different between systems. Just consider the difference between a
non-preemptive threading library and one normally assumed.

My personal feeling is that we need right now some documents lying out
the basics of our threading concept and a general agreement that we
feel bound to these documents. Basically, this consist of the following

- A clear statement of our goal.
- A decription of techniques, idioms, pitfalls, etc. related to
  achieving this goal.
- A set of interfaces used by those techniques and idioms.
- Possibly a simple [demo] implementation.

Probably, these documents are created in this order with feedback
incorporated into them. Anybody volunteering to get this going? I would
volunteer except for two nits:

- I have no clue about multi threading, ie. I have read some stuff on
  this but I have no practical experience (at least I have never had to
  track down a problem caused by some race condition or a dead lock).
- I would need someone to kick my butt if I don't meet a [tight]
  schedule. Ask Nico to find out what it took him to have me translate
  the stuff for his book...

So, probably someone else is more appropriate :-)

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

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