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

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
increment/decrement-and-test and...

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

-- 
Alan Griffiths  (alan_at_[hidden])  http://www.octopull.demon.co.uk/
ACCU Chairman   (chair_at_[hidden])             http://www.accu.org/