How to stop a thread

[Jon Slaughter]

I'm using Thread and ThreadStart to create a thread for testing purposes and
I do not want to use a pool because the thread exists for the life time of
the app. Eventually I might move on to using pools but at this point I'm
just testing some timing issues.

in any cause the thread is simply a counter,


static void counter()

{

while (true)

{

clicks++;

//Delayer(10000);

//Thread.Sleep(0);

Thread.SpinWait(100);


}


}



Now my main program "profiles" this thread by computing how many clicks it
does in a specified time. It does this and does some statistics and then
returns a result and then tries to exit. The problem is, when I use SpinWait
as a delayer my app never exists but just sits there. If I use Delayer then
I can abort the thread and everything works fine. I do understand abort
isn't the best way but in this case I don't really have any other option
that I know of. What else can I do besides use pools?

Every site I have visted says that Thread.Abort is evil yet how else can you
stop a thread(I know theres a scope issue but in this case its not working
either).

I'd like to use SpinWait since it seems to be slightly more stable than my
delayer(which is a unmanaged C++ function that uses nops)... But doesn't do
me any good if I can't stop the thread with it ;/

Any ideas?



Thanks,

Jon

 

[Jon Skeet [C# MVP]]

Every site I have visted says that Thread.Abort is evil yet how else can you
stop a thread(I know theres a scope issue but in this case its not working
either).

You stop a thread by indicating to it that you want it to stop, and
letting it do so in its own time.

See http://pobox.com/~skeet/csharp/threads/shutdown.shtml

 

[Jon Slaughter]

You stop a thread by indicating to it that you want it to stop, and
letting it do so in its own time.

See http://pobox.com/~skeet/csharp/threads/shutdown.shtml

Why do I need to go through all this work just to stop a simple thread for
simple testing purposes? It seems like too much over kill...

Why could't I then just use

while(!ShouldStop)
{

}

in my thread and then set ShouldStop to true in my main app when I want it
to stop? That should do the same thing as the class you use but stop the
thread.

I imagine I do not have to even lock ShouldStop because its not
critical(thread is only reading and main app is only writing).

You know, I know there are better ways.. but I'm not looking for a better
way but just something that works and is the least amount of work...
remember, this isn't for production but for simple testing and I don't
really care if its not the best. I do want something that works of course
and doesn't cause any real problems. (Like Abort throws an exception but I
really don't care about that because I can ignore it)

Jon

 

[Jon Slaughter]

You stop a thread by indicating to it that you want it to stop, and
letting it do so in its own time.

See http://pobox.com/~skeet/csharp/threads/shutdown.shtml

BTW, what does this code have over using ThreadPools?

 

[Jon Skeet [C# MVP]]

BTW, what does this code have over using ThreadPools?

It's a completely separate set of properties - you could use this code
(or something very like it) with a ThreadPool thread if you wanted.
However, I prefer long-running threads to be managed separately - the
ThreadPool is really designed to have short tasks running on it.

 

[Jon Skeet [C# MVP]]

Why do I need to go through all this work just to stop a simple thread for
simple testing purposes? It seems like too much over kill...

Um, you don't have to do the work. I've done it all for you - you just
need to cut and paste.

Why could't I then just use

while(!ShouldStop)
{

}

in my thread and then set ShouldStop to true in my main app when I want it
to stop? That should do the same thing as the class you use but stop the
thread.

Yes, you can indeed do that if you want.

I imagine I do not have to even lock ShouldStop because its not
critical(thread is only reading and main app is only writing).

It needs to either use a volatile variable or use a lock. Either will
do, but you do need one of them, otherwise there's no guarantee that
the worker thread will "see" the new value written by the main app.

You know, I know there are better ways.. but I'm not looking for a better
way but just something that works and is the least amount of work...

I suspect you've taken longer posting this reply than cutting and
pasting my code would have taken.

remember, this isn't for production but for simple testing and I don't
really care if its not the best. I do want something that works of course
and doesn't cause any real problems. (Like Abort throws an exception but I
really don't care about that because I can ignore it)

I've provided you something that works and doesn't cause problems.

 

[Jon Slaughter]

Um, you don't have to do the work. I've done it all for you - you just
need to cut and paste.


Yes, you can indeed do that if you want.


It needs to either use a volatile variable or use a lock. Either will
do, but you do need one of them, otherwise there's no guarantee that
the worker thread will "see" the new value written by the main app.


I suspect you've taken longer posting this reply than cutting and
pasting my code would have taken.

lol, true. But then I'd have to figure out how to use your code Not that
its a bad thing but I actually have seen your code before.

I've provided you something that works and doesn't cause problems.

Depends on how you define problems.

Thing is, I have code that works just fine for my purposes of testing at
this point and I don't feel like re writing it to use your code if I don't
have to. The issue is not making the threads better but just getting it to
shut down so when I run the app it doesn't hang or cause an exception that
VS ends up bitching about(or makes the OS unstable or something like that).
Later on when I end up having to implement the code in a real app I'll
rewrite it to use ThreadPool... or if your lucky maybe even your code.


Thanks,
Jon

 

[Jon Slaughter]

It's a completely separate set of properties - you could use this code
(or something very like it) with a ThreadPool thread if you wanted.
However, I prefer long-running threads to be managed separately - the
ThreadPool is really designed to have short tasks running on it.

Well, which do you think I should use for my application? I will be sending
a series of commands and data to the parallel port. Basically just toggling
some port values. Most commands are a few bits long but sometimes I'll need
to send several commands at once and in some cases I'll need to send several
kb of data(or potentially even in the Mb's). The main issue is that in some
cases I might have to send at a very low rate and so it could potentially
take several mins to send the data.

I know I do not need a thread for this but I was thinking of putting the
commands in thread as to make the gui more responsive and between each
command I could give back more time. Whats important here is not the time
between each command but a consistant frequency(that is controllable).

I'm thinking that chances are I do not even need a thread for all this and
probably will try both methods. But if I do use threads do you think I
should use ThreadPool or your class? I originally had the idea of just
using one thread and start and stop it as needed when a command was read to
send instead disbatching a new thread for each command(which might have sync
issues).

Anyways, I'm kinda new to all this threading stuff so thats why I'm asking.

Thanks,
Jon

 

[Jon Skeet [C# MVP]]

Depends on how you define problems.

Thing is, I have code that works just fine for my purposes of testing at
this point and I don't feel like re writing it to use your code if I don't
have to. The issue is not making the threads better but just getting it to
shut down so when I run the app it doesn't hang or cause an exception that
VS ends up bitching about(or makes the OS unstable or something like that).
Later on when I end up having to implement the code in a real app I'll
rewrite it to use ThreadPool... or if your lucky maybe even your code.

If it's only at the end of the application, just make them background
threads when you start them - then they'll just die automatically.

 

[Jon Skeet [C# MVP]]

Well, which do you think I should use for my application? I will be sending
a series of commands and data to the parallel port. Basically just toggling
some port values. Most commands are a few bits long but sometimes I'll need
to send several commands at once and in some cases I'll need to send several
kb of data(or potentially even in the Mb's). The main issue is that in some
cases I might have to send at a very low rate and so it could potentially
take several mins to send the data.

It sounds like a separate thread is a good thing here.

I know I do not need a thread for this but I was thinking of putting the
commands in thread as to make the gui more responsive and between each
command I could give back more time. Whats important here is not the time
between each command but a consistant frequency(that is controllable).

I'm thinking that chances are I do not even need a thread for all this and
probably will try both methods. But if I do use threads do you think I
should use ThreadPool or your class?

As I said, they're orthogonal issues - using a threadpool thread
doesn't prohibit you from using my code, or vice versa.

I originally had the idea of just
using one thread and start and stop it as needed when a command was read to
send instead disbatching a new thread for each command(which might have sync
issues).

Anyways, I'm kinda new to all this threading stuff so thats why I'm asking.

I suggest you read my threading tutorial from the start:
http://pobox.com/~skeet/csharp/threads