Re: To thread or not to thread ?
"James Kanze" <email@example.com> wrote in message
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
OK "joinable" is semantically foreign to me.
It's the standard vocabulary. It's the term used in all of the
threading interfaces I know: Posix, Boost, Java... I'd expect
the term to be familiar with anyone familiar with threading.
If you would have said
'waitable thread', I would have groked it right away. Example of a
"joinable"/"waitable" thread: an intermediate result of some complex
mathematical formula. Example of a "detached" thread: worker threads in a
thread pool handling incoming database transactions. Yes?
It depends. A lot of server software will use joinable threads
in order to ensure a clean shutdown. It's especially true if
you use objects for threads. GUI worker threads will typically
be detached, since the GUI event thread cannot very well do a
join, although some designs will use a special reaper thread to
do the joins. (Again, this is done in order to ensure clean
shutdown.) (I'm not sure, but I have the impression that you
can close the thread handle without stopping the thread. This
corresponds very exactly to detaching the thread; the vocabulary
is a little wierd, but in this case, perhaps justifiably so,
because of the unified way Windows handles handles.)
Note that similar issues concern processes.
In Windows, one does not have to specify anything to get a "joinable"
thread: one just waits for the thread handle to become signaled. (That is,
if the concept of "waiting on" and "joining" is the same).
And if no one ever waits for the thread? A thread uses system
resources, and in a joinable thread, those resources must be
kept by the system until the join has taken place. If a thread
is detached, on the other hand, the system frees up the
resources as soon as the thread has finished.
Why is it hard to cleanly shutdown a detached thread?
Because you don't know when it has finished. (And of course,
you can't call exit() safely until it has finished.)
On the flip side, why is it easy to cleanly shutdown a
joinable thread? Oh, did you mean shutdown the application
rather than the threads (which becomes the problem of shutting
down the threads)?
Shutdown means shutting down the application, yes. With the
constraint that you cannot call exit as long as any threads are
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! ]