Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 15:13:55

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> I just noted when reading Beman's mail: We should actually come up 
with
> a bunch of rather concrete scenarios where threads are solving some
> problem in the first place! Sure, I have a feeling where threads 
seem
> to be a solution to some problem but are they indeed or are they 
just
> some hyphe which is currently around? Since MT support by a 
language is
> not just some add on but causes all kinds of strange interactions 
there
> will be a fair amount of resistance when trying to convince the
> committee that this is indeed needed. Here are some issues which 
will
> be asked immediately (if nobody else does, the German delegation 
will
> bring them up :-) when this stuff comes up in the C++ 
standardization
> committee:
> 
> - What happens to platforms which don't have threading support, ie. 
are
>   threads important enough to make optional standard components?

I don't see that they need to be optional.  If the interface is well 
defined than user level threads can be implemented for platforms that 
don't support native threads.  Even DOS has several thread libraries 
designed this way.  The embedded people may not like them... but 
they're defining a "slimmer" C++ any way.  My opinion here isn't 
really important, I just thought I'd share my thoughts about this 
particular statement.

> - What is the impact on programs not needing multi threading 
support?

That will totally depend upon the design.  It's an issue we need to 
be concerned with.
 
> - How do exceptions and threads interact. For example what happens 
if
>   two threads throw exceptions at the same time?

Each thread must run with it's own stack, making this particular 
question irrelevant.  What's not irrelevant is what occurs if a 
thread does not catch a thrown exception.
 
> Now, currently we are not discussing to bring this stuff into the 
C++
> standard (Boost is *not* a workgroup of WG21). However, since 
different
> platforms provide rather different MT support for C++ programs, 
there
> is clearly at least some need for common basics.
> 
> ... and even if this will never be brought to the standardization
> committee, we should have good reasons to devote any effort from the
> Boost library: There are lots of other areas we can cover instead. 
So
> apart from answering the questions brought up in my previous mail, 
we
> should also come up with sample uses of threads where threads are
> indeed an advantage over other techniques - without any hand waving!

Our world now lives on multiple processors, multi-tasking OSes and 
distributed systems.  Even with out "threads" in terms of OS or 
language constructs we still must deal with threads in these other 
terms.  No programmer can avoid these problem domains for long today 
and a language that doesn't address it is going to be dismissed from 
many common chores.  This may be acceptable from a language stand 
point, but taking this stance with the language will mean a reduction 
in the language's use in the industry.  Don't think in terms 
of "thread" but in terms of "concurrent processing" and you'll see 
the need for language support.