Re: Thread killing problem
On Dec 26 2007, 10:42 am, "J.K. Baltzersen" <jornb...@pvv.org> wrote:
To whomever it may concern:
I am using MS Visual C++ 6.0.
I have a process A which instantiates an object C.
At a later point the process A creates the thread B.
The thread B has access to the object C.
Because the user cancels the "process" which the thread B
handles, the thread B is stopped by the use of
TerminateThread.
I'm not too sure about the exact semantics of TerminateThread,
but in general, thread cancellation (or termination) must be
synchronized in some way or another. Under Posix,
pthread_cancel is really only advisory, and will only
"terminate" the thread at specific "cancellation points. Which
of course, may mean never, if the thread never encounters a
cancellation point. Also, the C++ binding of pthread_cancel is
undefined, and different implementations do it differently, even
on the same platform. If TerminateThread is more than advisory,
or doesn't have some sort of additional synchronization
semantics, then you can't use it directly either.
A bit later on I try to access member variables in the object B, the
purpose of this being replacing some files with backup versions of
these same files. These member variables are of type std::string.
Let's call these m, n, and o. When I access m, there seems to be no
problem. However, when I access n, the debugger hangs, apparently
infinitely.
You mean the object C, I presume. If thread B was in the middle
of modifying object C when it was terminated, then it probably
left object C in an inconsistent state.
If your code is modifying object C, anywhere, all accesses to
object C must be synchronized via some sort of mutex. And a
thread may not be terminted while it holds that mutex.
I tried replacing std::string with char*, but that only
resulted in the problem showing up when I accessed m.
I want to be able to run TerminateThread on the thread B without my
object C being corrupted.
In general, functions like TerminateThread (supposing the
semantics I think it has) can't be made to work, and should only
be used as a last resort. What you need is 1) some sort of
shared variable which the thread polls from time to time, and 2)
some way of "unblocking" the thread so that it can poll.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34