Re: To thread or not to thread ?
JohnQ wrote:
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1168886320.170649.189980@l53g2000cwa.googlegroups.com...
JohnQ wrote:
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1168780230.381634.41480@11g2000cwr.googlegroups.com...
JQP wrote:
[...]
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
"joinable threads".
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
without them.
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.
In the UNIX world. Show me the words 'joinable' or 'detached' in any of
the
Windows API (Win32, not more recent .Net/C# products) documentation.
In the threading world. The terms go back before Unix even
existed. Why Windows decided to use a non-standard vocabulary
is beyond me, but it's not a real problem. First, you learn
threading (which means learning terms like join), then you learn
Windows threading, or Posix threading, or whatever platform you
need. Many of the issues are the same, the works of people like
Hoare or Dijkstra are still pertinant today, and their ideas
will still permeate the design of a threaded application.
[...]
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.
That sounds like what ExitThread does. Actually, whether a thread exits or
calls ExitThread, the same thing happens (resources are cleaned up).
Which means that you cannot call ExitThread on a thread which
someone might wait for? I rather doubt that.
I'm not sure -- I'm not that familiar with Windows -- but
by reading some of the documentation and looking at example code
(e.g. in boost::threads), I get the impression that you detach a
thread by closing the thread handle. In some ways, it's a sort
of surprising idea, but I sort of like it. A thread has two
sets of system resources, those that it uses directly, and those
that are used to implement the join, and pass information back
to the joining thread. The handle is responsible for the
second, only.
OK...
ExitThread is an API that can be called from WITHIN a thread to exit the
thread. External to the thread, in order to exit the thread one must let
the
thread exit on its own, or one must have designed some way of exiting
gracefully or call TerminateThread, the last of which is never recommended
because resources will not be released. (I'm not reading the documentation
as I type this so don't take it as gospel).
I think it's more or less correct, except that I wouldn't say
that resources won't be released: the resources directly
associated with the thread by the system should be released, but
there's no guarantee that the thread will "clean-up" correctly
and leave things in a coherent state. One frequent symptom of
this incoherence is that some resources allocated by the thread
might leak.
This is very different from pthread_cancel. Although one would
normally expect functions with names like terminate and cancel
to behave similarly, pthread_cancel doesn't really cancel the
thread; it just sets a global flag that the thread can test, and
unblocks any blocking system calls. The good thing about it is
that the thread can e.g. read on a socket without a time out,
and be interrupted to clean up and terminate normally. (The bad
thing, of course, is that there is no guarantee that the thread
will do this; pthread_cancel is purely advisory, and a rogue
thread can ignore it completely.)
And remember, I'm not suggesting
that all this is possible using only the Win32 API, that's why wrapper
(actually more than just wrappers, but new abstractions from the synthesis
of API constructs) classes may be necessary, such as a Thread class.
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.)
I new you were going to say that. I agree: the program is not done being
developed until those issues have been solved for the given application.
My
intuition says that some kind of general library or language element is
not
possible to "solve the problem once and for all", but rather that
application or domain or framework -specific solutions are possibly the
only
solution.
That's really my feeling as well. Generally speaking, I'd like
something like pthread_cancel, so that I block without a
time-out, but still be able to interrupt and clean-up. But it's
not a killer issue; in fact, I don't use pthread_cancel under
Solaris, because Sun CC and g++ give it different semantics.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]