Re: To thread or not to thread ?
James Kanze wrote:
"Le Chaud Lapin" <email@example.com> wrote :
There are two philosophies: a thread is an asynchronous
function, or a thread is a class. The Boost model tries for a
sort of compromize between the two: a thread is a class, but one
that acts like an implicitly called functional object, and whose
lifetime doesn't need to extend to the lifetime of the entire
Some kind of "thread launcher"?
Not really, either. The problem is that the Boost model tries
to use a single class for several very different things:
identifying the thread, starting it and as a future. When used
to start a detached thread, it is a thread launcher. If you
don't detach, it is the classical thread object, to which you
can join. And you can have objects of type thread which are
copies, or are created independantly, which only serve to
identify a thread.
My experience suggests that you don't need a class to represent
a detached thread; a global function corresponds better to what
you are doing.
In my own work, I distinguish between joinable threads and those
that you "fire and forget". Joinable threads are a class, so
you have something to join with; detached threads are started by
a simple function call.
Another philosophy involves "futures": basically, it consists of
a function to start the thread; the function returns an object
which can later be used for joins.
OK. I don't have knowledge of the entire range of design problems that
threads can solve, so now I'm wondering about those other ones that I
haven't worked with yet. For instance, I don't know the concept
Anytime you want to use the response from a thread, you need a
joinable thread. It's also very hard to do a clean shutdown
Besides that though, do you think that Le Chaud
Lapin was talking about detachable threads when he stated that modeling
threads as classes was a bad idea?
Maybe. It's hard to say what he was thinking about; I have no
idea what type of application he works on (except that it must
be very different from mine, since he seems to be able to easily
force the lifetime of everything to correspond to a scope).
James Kanze (Gabi Software) email: firstname.lastname@example.org
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! ]