How to stop a thread

Jon Slaughter <Jo***********@Hotmail.comwrote:

<snip>

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 Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jon Slaughter <Jo***********@Hotmail.comwrote:

<snip>

>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

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 Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jon Slaughter <Jo***********@Hotmail.comwrote:

<snip>

>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

BTW, what does this code have over using ThreadPools?

Jon Slaughter <Jo***********@Hotmail.comwrote:

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

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jon Slaughter <Jo***********@Hotmail.comwrote:

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 Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jon Slaughter <Jo***********@Hotmail.comwrote:

>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.

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.

>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.

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 Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jon Slaughter <Jo***********@Hotmail.comwrote:

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

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.

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 Slaughter <Jo***********@Hotmail.comwrote:

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.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jon Slaughter <Jo***********@Hotmail.comwrote:

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too