Boost logo

Boost :

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
> a bunch of rather concrete scenarios where threads are solving some
> problem in the first place! Sure, I have a feeling where threads
> to be a solution to some problem but are they indeed or are they
> 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
> will be a fair amount of resistance when trying to convince the
> committee that this is indeed needed. Here are some issues which
> be asked immediately (if nobody else does, the German delegation
> bring them up :-) when this stuff comes up in the C++
> committee:
> - What happens to platforms which don't have threading support, ie.
> 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

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
> 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
> standard (Boost is *not* a workgroup of WG21). However, since
> platforms provide rather different MT support for C++ programs,
> 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.
> apart from answering the questions brought up in my previous mail,
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at