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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk