Thread killing problem

[J.K. Baltzersen]

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 .

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.

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.

I would greatly appreciate any tips that would lead to my being able
to do so.

Thank you very much in advance for any help.

Best regards,
J.K. Baltzersen

[yanlinlin]

Re: Thread killing problem

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

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 .
>
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.
>
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.
>
I would greatly appreciate any tips that would lead to my being able
to do so.
>
Thank you very much in advance for any help.
>
Best regards,
J.K. Baltzersen

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.

[J.K. Baltzersen]

Re: Thread killing problem

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:
>
>
>
>
>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>
Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -
>
- Show quoted text -

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

Thanks again.

[yanlinlin]

Re: Thread killing problem

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:
>
>
>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>
My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.
>
Thanks again.

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 notifying

DWORD WINAPI TheThreadProc(L PVOID) // 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
WaitForSingleOb ject(hThread);
// ...
}

Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.

[J.K. Baltzersen]

Re: Thread killing problem

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:
>
>
>
>
>

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

>

Thanks again.

>
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 notifying
>
DWORD WINAPI TheThreadProc(L PVOID) // 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
   WaitForSingleOb ject(hThread);
   // ...
>
}
>
Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.- Hidequoted text -
>
- Show quoted text -

Thanks.

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. In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.

Again, thanks.

[J.K. Baltzersen]

Re: Thread killing problem

On Dec 26, 3:01 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:
>
>
>
>
>

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

>

Thanks again.

>

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 notifying

>

DWORD WINAPI TheThreadProc(L PVOID) // 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
   WaitForSingleOb ject(hThread);
   // ...

>

}

>

Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.- Hide quoted text -

>

- Show quoted text -

>
Thanks.
>
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. In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.
>
Again, thanks.- Hide quoted text -
>
- Show quoted text -

I've tried a solution with SuspendThread as well. There seems to be
some of the same problems with that. 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.

[yanlinlin]

Re: Thread killing problem

On Dec 26, 10:01 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:
>
>
>

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

>

Thanks again.

>

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 notifying

>

DWORD WINAPI TheThreadProc(L PVOID) // 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
WaitForSingleOb ject(hThread);
// ...

>

}

>

Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.- Hide quoted text -

>

- Show quoted text -

>
Thanks.
>
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. In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.
>
Again, thanks.

Since exception is within a thread, I'm afraid you can not do like
that.

[yanlinlin]

Re: Thread killing problem

On Dec 26, 10:10 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 3:01 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:
>
>
>

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notify the
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

>

Thanks again.

>

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 notifying

>

DWORD WINAPI TheThreadProc(L PVOID) // 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
WaitForSingleOb ject(hThread);
// ...

>

}

>

Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.- Hide quoted text -

>

- Show quoted text -

>

Thanks.

>

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. In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.

>

Again, thanks.- Hide quoted text -

>

- Show quoted text -

>
I've tried a solution with SuspendThread as well. There seems to be
some of the same problems with that. 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.

Use ResumeThread to wake up the suspened thread. Or use CreateEvent
and WaitForSingleOb ject instead of sleep for long time.

[J.K. Baltzersen]

Re: Thread killing problem

On Dec 26, 4:49 pm, yanlinlin <yanlinli...@gm ail.comwrote:

On Dec 26, 10:10 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:
>
>
>
>
>

On Dec 26, 3:01 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:

>

On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

>

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 .

>

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.

>

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.

>

I would greatly appreciate any tips that would lead to my being able
to do so.

>

Thank you very much in advance for any help.

>

Best regards,
J.K. Baltzersen

>

Don't use TerminateThread . Use event or something else to notifythe
thread to exit by itself instead.- Hide quoted text -

>

- Show quoted text -

>

My thread is not event oriented. It runs from start to end unless some
exception is thrown. Could I tell the thread to throw an exception, by
sending a message to it, at an arbitrary point? I would rather avoid
introducing checkpoints where the thread decides whether to continue
or exit.

>

Thanks again.

>

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 notifying

>

DWORD WINAPI TheThreadProc(L PVOID) // 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
   WaitForSingleOb ject(hThread);
   // ...

>

}

>

Since TerminateThread can not guarantee variables in thread be
destroied correctly, let the thread exit by itself is the right way.- Hide quoted text -

>

- Show quoted text -

>

Thanks.

>

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. In that way we would be using the
existing exception handling system. The thread would exit upon
catching the exception.

>

Again, thanks.- Hide quoted text -

>

- Show quoted text -

>

I've tried a solution with SuspendThread as well. There seems to be
some of the same problems with that. 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.

>
Use ResumeThread to wake up the suspened thread. Or use CreateEvent
and WaitForSingleOb ject instead of sleep for long time.- Hide quoted text -
>
- Show quoted text -

When I try to access the member variables of object C while thread B
is under suspension, I get the same problem -- seemingly at least --
as I get when I have terminated the thread with TerminateThread .

[Kenneth Porter]

Re: Thread killing problem

yanlinlin <yanlinlin82@gm ail.comwrote in news:f2315d85-ee13-425b-85e2-
fb5d5a0cad97@b4 0g2000prf.googl egroups.com:

>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. In that way we would be using the
>existing exception handling system. The thread would exit upon
>catching the exception.
>>
>Again, thanks.

>
Since exception is within a thread, I'm afraid you can not do like
that.

You might be able to, but it's going to be platform-specific. Under the
hood, an exception on a 386 is typically implemented using the machine's
native exception machinery, and that same machinery is also used for OS-
specific asynchronous exceptions like task termination and keyboard
interrupt. One's compiler may have support for intercepting these kinds of
exceptions. For example, Windows compilers typically support "structured
exception handling" (SEH) which can "catch" these kinds of exceptions.

[Tomás Ó hÉilidhe]

Re: Thread killing problem

"J.K. Baltzersen" <jornbalt@pvv.o rgwrote in comp.lang.c++:

At a later point the process A creates the thread B.
>
The thread B has access to the object C.

The C++ standard doesn't mention anything about threads, however there
are C++ communities built up dedicated to portable multi-threaded
programming.

To achieve portable multi-threaded programming, they produce a "cross-
platform library" which people can use in developing an application that
can run on a wide variety of system.

There's currently no newsgroup in place for discussing cross-platform
programming in C++, which is why I've proposed the creation of
comp.lang.c++.c ross-platform. Voting should start in the next day or two
(there's a load of red tape crap at the minute).

I'd appreciate if you'd vote.

--
Tomás Ó hÉilidhe

[James Kanze]

Re: Thread killing problem

On Dec 26 2007, 10:42 am, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

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 "cancellati on 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.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: Thread killing problem

On Dec 26 2007, 3:10 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 3:01 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

On Dec 26, 2:04 pm, yanlinlin <yanlinli...@gm ail.comwrote:

On Dec 26, 7:20 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:
On Dec 26, 12:00 pm, yanlinlin <yanlinli...@gm ail.comwrote:
On Dec 26, 5:42 pm, "J.K. Baltzersen" <jornb...@pvv.o rgwrote:

[...]

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 notifying

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(L PVOID) // 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
WaitForSingleOb ject(hThread);
// ...
}

You need to synchronize the access to flag if you want this to
work. My own solution is generally to implement a
"terminateReque sted" function, which throws an exception if
flag is true, e.g.:

void
terminateReques ted()
{
boost::mutex::s coped_lock lock( ourTerminationM utex ) ;
if ( ourTerminateReq uestedFlag ) {
throw TerminateReques tException() ;
}
}

and

void
requestTerminat ion()
{
boost::mutex::s coped_lock lock( ourTerminationM utex ) ;
ourTerminateReq uestedFlag = 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.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: Thread killing problem

On Jan 5, 8:33 pm, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

"J.K. Baltzersen" <jornb...@pvv.o rgwrote in comp.lang.c++:

At a later point the process A creates the thread B.

The thread B has access to the object C.

The C++ standard doesn't mention anything about threads,
however there are C++ communities built up dedicated to
portable multi-threaded programming.

The current working draft of the C++ standard does mention
threads, and threads will be part of the next version of the
standard. I believe that it is still hoped that this version
will become official before the end of 2009 (so that it will be
C++0x, and not C++1x), although the schedule is very, very
tight.

Long before the current draft, Boost offered a portable
interface to threads, and before that, there was Ace, and
doubtlessly many others.

To achieve portable multi-threaded programming, they produce a
"cross-platform library" which people can use in developing an
application that can run on a wide variety of system.

There's currently no newsgroup in place for discussing cross-platform
programming in C++,

There's this group. Why do you keep claiming that this group
doesn't exist?

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Tomás Ó hÉilidhe]

Re: Thread killing problem

James Kanze <james.kanze@gm ail.comwrote in comp.lang.c++:

The current working draft of the C++ standard does mention
threads, and threads will be part of the next version of the
standard. I believe that it is still hoped that this version
will become official before the end of 2009 (so that it will be
C++0x, and not C++1x), although the schedule is very, very
tight.

I've been out of the C++ loop for about a year or two. Is there a summary
anywhere on the web of all the new features that will make it into the
next standard?

>There's currently no newsgroup in place for discussing cross-platform
>programming in C++,

>
There's this group. Why do you keep claiming that this group
doesn't exist?

Because people get told to shut up if they ask how to interface with a
USB device in C++.

--
Tomás Ó hÉilidhe