From: Alan Griffiths (alan_at_[hidden])
Date: 2000-05-31 15:45:40
In message <20000531112149.19960.qmail_at_[hidden]>, Dietmar
Kuehl <dietmar_kuehl_at_[hidden]> writes
>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.
I'd like to second this viewpoint but with the addition of atomic
>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.
>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
>of this issue).
...such guidelines are probably the starting point, not the third
-- Alan Griffiths (alan_at_[hidden]) http://www.octopull.demon.co.uk/ ACCU Chairman (chair_at_[hidden]) http://www.accu.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk