Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Randy
Date : Wed Apr 27 2005 06:48 pm

Maciej Sobczak wrote:
> Hi,
> 
> There is a fervent discussion on pl.comp.lang.c about the possible
> thread support in C++.
> 
> I have gathered my thoughts in a single place, where I describe what in
> my opinion should be the appropriate threading support in a high-level
> programming language:
> 
> http://www.msobczak.com/prog/articles/threadscpp.html
> 
> The motivation for writing this was that I do not like the current
> approaches to do threading in C++. For example, pthreads is a very
> low-level API that does not give me enough abstraction. For another
> example, Boost.Threads imposes the "thread is an object" point of view,
> which I somehow do not share.
> 
> I would like to kindly ask you to express your opinion - what I'm
> interested in is whether what I wrote is complete nonsense or maybe it
> has some merits.
> 
> Please note that I do not tackle the memory model, which needs to be
> specified in C++ anyway. I'm interested in high-level usage patterns.

It seems to me that you can approach threading to serve a couple of
goals, regardless of the syntax:

1) a large grained level of concurrency, like that of POSIX threads

2) a finer grained level of concurrency, like that needed by the
upcoming generation of multicore CPUs

I would think that a C++ template container would be the natural way to
manage heavyweight threads.  Only at the template level are the thread
IDs known or managed.  As you say, generally you don't want threads to
be managing other threads.  But you could nest templates to do this
(subthreads within a thread), if necessary.

To serve lightweight threads, you could look to the kind of implicit
concurrency that's been around for a long time in Modula and Ada (and
Erlang, I suppose).  I don't think it's caught on in the past since
efficient threading wasn't available on enough O/Ses, or it wasn't
portable, nor had the popularity of those languages reached critical
mass.  Maybe that will change with the rising need for concurrency in
the P4 Extreme and other single instruction stream multicore CPUs.
Current languages are not going to serve those CPUs well.  Something
like the an implicit threading model within a popular language probably
is going to be necessary for concurrency to enter the main stream.

    Randy

-- 
Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

.