Re: multi threading support (was: [boost] Hello boosters)

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-05-31 12:06:46

From: Dietmar Kuehl <dietmar_kuehl_at_[hidden]>
> 
> I think the important part which is to be supported on virtually any
> multi-threaded OS is the access to a basic thread synchronization
> mechanism, ie. to a mutex to protect critical sections. With this in
> place other components can be implemented with an eye towards thread
> safety simply using the mutex and a corresponding lock class which
> automatically releases the lock.

That is a very good start, but for efficient reference
counting you need an atomic decrement-and-test.

> The whole issue of thread creation, priority manipulation, termination,
> etc. is IMO not that important as is the thread synchronization: To
> implement classes suitable for a threaded environment, there is no need
> to do this at all. Threads can be created in some non-portable way but
> the thread safe classes are supposed to be portable. Of course, it
> would also be nice to have a portable interface to this functionality,
> too, but I consider the thread synchronization as a more urgent and
> basically separate issue. That is, I would probably place favour two
> separate challenges, namely one for the synchronization mechanism and
> another one, probably taking the results of the synchronization
> challenge into account, for other threading mechanisms.

Yes.  Thread lifetime management is the least portable
part of threading.

> Actually, there might even be a third challenge, namely one for a
> guideline what is supposed to be thread protected and what is not and
> how components should use thread protection. The need for such a thing
> shows up with the numerous requests for "thread safe" containers where
> users often expect the container to deal with their threading problems
> which will never be the case (see eg.
> <http://www.sgi.com/Technology/STL/thread_safety.html> for a discussion

An excellent disscussion.  See also their implementation
in http://www.sgi.com/Technology/STL/stl_threads.h

> of this issue). For example an expression like 'a[i] = 17' cannot be
> thread safe by adding thread support to the class of 'a' unless the
> return of 'a[i]' is actually a proxy holding a lock on 'a' which would
> be rather inefficient and fairly error prone (due to a large potential
> for dead locks). Another part of such a guideline would spell out how
> to prevent dead locks.

Atomic assignment might be another useful primitive, and
Java provides it for volatile variables.  Still, the ease
with which you can deadlock a Java program has left me
wondering whether whatever realiability Java gained by
banishing pointers was lost by providing threads with
such a promitive interface.