OpenNETCF.Threading.ThreadEx.Abort() problem

  • Thread starter Thread starter Davide
  • Start date Start date
D

Davide

Hi to everyone,
this is my c# code:

if ( m_Thread.IsAlive )
{
try
{
m_Thread.Abort();
}catch
{
}
m_Thread = null;

where m_Thread is an instance of OpenNETCF.Threading.ThreadEx

now if I call
GC.Collect()

the program crash :( :(

Have you any suggestion???

thanks,
Davide

ps: I need to use abort method because of I'm in a situation where one thread (main thread) need to
interrupt a thread(slave thread) in non-synchronized way(decided by the user)
 
Well, I'd rewrite my thread so that you can use an event to notify the
thread that it should terminate itself, rather than trying to use Abort
before deciding that you "have to" use Abort. I've got a lot of threaded
code in my applications, drivers, etc. and *none* of it ever terminates a
thread in this way.

Can you tell us why you're calling GC.Collect()? You really shouldn't have
to call that. Please also tell us what happens when the program crashes.
Is an exception fired? If so, what are its characteristics? Run this in
the debugger and get us as much information as possible.

Paul T.
 
So,
ok.
Can you suggest me a way to end a thread without using an Abort()?
Note: in the function thread there is a call function that can block the thread
for some seconds.
So the well know approach

while ( something && exitThread )
do something

Can't be used because of the "do something" can be 3 or 4 seconds.
Well, I'd rewrite my thread so that you can use an event to notify the
thread that it should terminate itself, rather than trying to use Abort
before deciding that you "have to" use Abort. I've got a lot of threaded
code in my applications, drivers, etc. and *none* of it ever terminates a
thread in this way.
Click to expand...
Since


the GC.Collect() is used for debug purpose, but this is not the problem, there
are many other GC.Collect() used around my program and none of them cast an exception.
Only when I have introduced the Abort() call it introduced me a problem.
do you have a debugger for ARM4 that can be used with Visual Studio.net???
Nice, give me the link :) :) :)
 
Well, the thread, when it's not doing its work, might instead wait, using
WaitForSingleObject() (which is wrapped in OpenNETCF, too), on a global
event. When the main thread wants the thread to exit, it would set the
event, causing the thread to return from WaitForSingleObject() and, upon
checking the return value, realize that it's time to exit. It would then
simple return. If the thread is waiting for data from a socket as part of
its work, the main thread might set the event and close the socket, assuring
that, even if the socket is blocked, it will return control to the thread
and the thread can see that it's time to leave. If the thread is waiting
for serial data from a serial port, the main thead might set the event and
close the port handle. If the thread is performing some mathematical
operations, it could periodically check the status of the event and exit if
the event was set.

In your 3 second case, what's the big deal? The goal is simply to get the
thread to exit, not to have it exit within x milliseconds, right? You can
certainly wait in the main thread for the thread to exit
(WaitForSingleObject( threadHandle )), if you want to, but you're not
*required* to.

If you have the crash while running your program in the VS.NET debugger,
what happens? VS.NET exits? The program exits silently? An exception is
thrown? As far as I know, none of us is a mind reader.

Paul T.
 
Paul said:
Well, the thread, when it's not doing its work, might instead wait, using
WaitForSingleObject() (which is wrapped in OpenNETCF, too), on a global
event. When the main thread wants the thread to exit, it would set the
event, causing the thread to return from WaitForSingleObject() and, upon
checking the return value, realize that it's time to exit. It would then
simple return. If the thread is waiting for data from a socket as part of
its work, the main thread might set the event and close the socket, assuring
that, even if the socket is blocked, it will return control to the thread
and the thread can see that it's time to leave. If the thread is waiting
for serial data from a serial port, the main thead might set the event and
close the port handle. If the thread is performing some mathematical
operations, it could periodically check the status of the event and exit if
the event was set.
Click to expand...

You assume this: "When it's not doing its work", this is the problem!!
My thread always work.

this is the code:

int now = DateTime.Now.Second + DateTime.Now.Minute * 60;
int timeLimit = now + 60;

do
{
//perform a connection with start tracking
App.GpsReceiver.StartTracking();
now =DateTime.Now.Second + DateTime.Now.Minute * 60;
if ( App.GpsReceiver.IsTracking() )
{
//the connection goes ok!
this.PostGpsConnection(true);
return;
}
}
while ( timeLimit > now && !App.GpsReceiver.IsTracking() );
the problem is App.GpsReceiver.StartTracking();
this fuction doesn't return immediatly but it can be 4-5-6-7 or even 20 seconds long.
(it perform a special handshake between the pocketpc and the gps)
So as you may understant, if I insert a flag like this:

while ( !threadStop && timeLimit > now && !App.GpsReceiver.IsTracking() );

or like this
WaitForSingleObject(Whatever,1000)

the exit from thread can get after very long time for the moment of required stop.

In your 3 second case, what's the big deal? The goal is simply to get the
thread to exit, not to have it exit within x milliseconds, right? You can
certainly wait in the main thread for the thread to exit
(WaitForSingleObject( threadHandle )), if you want to, but you're not
*required* to.



If you have the crash while running your program in the VS.NET debugger,
what happens? VS.NET exits? The program exits silently? An exception is
thrown? As far as I know, none of us is a mind reader.
Click to expand...
The program fire an exception, now I haven't to program in my hand, so tomorrow I will give you
more details ;)
 
PLEASE ACTUALLY READ MY WHOLE MESSAGE BEFORE DECIDING THAT YOU DON'T LIKE
WHAT I SAID.

My response to it taking 20 seconds to StartTracking is SO WHAT! Why are
you so concerned about exiting the thread within some particular period of
time? Is there no API on your GPS object to terminate tracking? If there
is, the main thread, consistent with the four or five examples I gave you,
could terminate that process after setting the exit flag. If not, live with
it.

Paul T.
 
Paul said:
PLEASE ACTUALLY READ MY WHOLE MESSAGE BEFORE DECIDING THAT YOU DON'T LIKE
WHAT I SAID.
Click to expand...

I read you entire post,I'm not english man, so maybe I don't understand something.
sorry if I offend you. :(
My response to it taking 20 seconds to StartTracking is SO WHAT! Why are
you so concerned about exiting the thread within some particular period of
time? Is there no API on your GPS object to terminate tracking? If there
is, the main thread, consistent with the four or five examples I gave you,
could terminate that process after setting the exit flag. If not, live with
it.
Click to expand...

Thanks for the reply, :)

Davide
 
Just a thought but doesn't Thread.Abort raise a ThreadAbortException in the
target thread? If you are not catching this in your worker method could it
be this unhandled exception that your are seeing? I hasten to add that I
have never used OpenNETCF's threading stuff so maybe this is not the case
here.
 
It definitely throws (a BestPracticeViolationException in this case) but I
see in his code he's catching.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate
 
Back
Top