Re: Which libraries in Boost are mature enough to be used in real applications?
David Abrahams wrote:
James Kanze <kanze.james@neuf.fr> writes:
for some (including some of the oldest and best understood),
pthreads is inadequate.
For example?
Fine grained parallel processing. I'm not sure "inadequate" is
the most appropriate word, but it is certainly too heavy to be
useful in such cases. And this is certainly one of the oldest
uses of multithreading: array processors were floating around at
the end of the 1970's, and I remember reading in the 1980's
about work being done at Rice University for the compiler to
detect and implement the parallelization automatically.
It also lacks any real support for hard real time, when
guarantied latency is required.
But that wasn't my point -- most of the problems I run into
don't stem from pthreads themselves, but from the way people
use them. I have a couple of objections concerning
boost::threads, but that wasn't the point of my posting.
Like I said, it's by no means perfect.
Nothing is:-).
Seriously, what I was trying to get accross, in my own awkward
way, is that we shouldn't necessarily wait for everything to be
"well-mulled". Generally, I'd prefer a solution which has stood
the test of time, where we know from experience exactly what is
needed, and where there is a concensus as to what the best
solutions are. In the case of threading (and certainly not only
threading), even the basic concepts aren't that "well-mulled" --
so obviously, the library can't be. But I don't think we can
afford to wait -- well-mulled or not, I need to be able to write
threaded code today, preferrably portably. IMHO, despite
certain weaknesses, the Boost threads library is a giant step in
the right direction. I'm not sure its a good analogy, but it is
so tempting: for many, many years, people used magnetic
compasses: even though they don't indicate true north, they were
significantly better than having no direction at all.
(Note that my criticisms concerning boost::threads generally
concern points where I find that it hides the underlying
pthreads abstraction too much. Things like not being able
to use non-scoped locks when appropriate, or having threads
"accidentally" become detached because of an exception, so
that I can't shut them down cleanly.)
I agree with all that, FWIW. We finally have a plan in place
to address some of these issues.
Note that not all of the issues affect the threading library
directly. Currently, it is impossible (at the pthreads level)
to catch an std::exception of unknown type in a child thread,
propagate it accross the join, and rethrow it in the parent
thread, after the join. Adding virtual functions clone() and
raise() to std::exception would go a long way to making that
easier.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]