Re: Thread killing problem
On Dec 26 2007, 3:10 pm, "J.K. Baltzersen" <jornb...@pvv.org> wrote:
On Dec 26, 3:01 pm, "J.K. Baltzersen" <jornb...@pvv.org> wrote:
On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gmail.com> wrote:
On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.org> wrote:
On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gmail.com> wrote:
On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.org> wrote:
[...]
Sorry to misguide you. What I mean about the event is not
the event supported by OS, but just a notification. Maybe
you can do it like this:
volatile bool flag = false; // this is a global variable for notifyi=
ng
The volatile isn't necessary. Or rather, it isn't sufficient,
and once you have a sufficient mechanism, it isn't necessary.
(Also, most compilers---VC++, g++ and Sun CC, at least---don't
implement any significant semantics for it anyway.)
DWORD WINAPI TheThreadProc(LPVOID) // this is the thread proc
{
// ...
while ( ! flag)
{
// ...
if (flag) break;
// ...
}
return 0;
}
void Foo()
{
HANDLE hThread = CreateThread(...);
// ...
flag = true; // Set the variable to let the thread exit by itself=
WaitForSingleObject(hThread);
// ...
}
You need to synchronize the access to flag if you want this to
work. My own solution is generally to implement a
"terminateRequested" function, which throws an exception if
flag is true, e.g.:
void
terminateRequested()
{
boost::mutex::scoped_lock lock( ourTerminationMutex ) ;
if ( ourTerminateRequestedFlag ) {
throw TerminateRequestException() ;
}
}
and
void
requestTermination()
{
boost::mutex::scoped_lock lock( ourTerminationMutex ) ;
ourTerminateRequestedFlag = true ;
}
(This more or less supposes some sort of thread object, of which
these functions are members.)
Since TerminateThread can not guarantee variables in
thread be destroied correctly, let the thread exit by
itself is the right way.
However, redesigning this application to check for an exit flag at
every second (or whatever we might choose) would be very costly. So I
was hoping there could be a simpler way, such as sending an exception
to the thread that is to exit.
The problem is that all but the simplest classes have class
invariants that must be maintained, and that during non-const
functions, these class invariants are temporarily not
maintained: the rule is only that the invariants must hold on
entry and on exit of each function, but not during execution of
the member functions themselves. (If maintaining the invariants
involves modifying several separate state objects, there's no
possible way that they could hold all of the time during a
member function.)
In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.
I've tried a solution with SuspendThread as well. There seems to be
some of the same problems with that.
Again, I'm not 100% sure about the semantics of the function (I
generally work on Posix based systems, or more recently on
Linux), but unless the suspention is somehow differed if you are
in a critical section, the lock won't be released, and no other
thread will be able to access the objects protected by the lock.
I've also thought about putting the thread to sleep for such a
long time that it won't wake up before the entire process has
exited. However, I haven't found a way of putting a thread to
sleep from outside.
And putting it to sleep won't solve the problem either, because
the sleeping thread will still have the lock.
--
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