471,305 Members | 1,432 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,305 software developers and data experts.

How to stop a thread

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
Sep 9 '07 #1
9 3780
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
Sep 9 '07 #2

"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
Sep 9 '07 #3

"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?
Sep 9 '07 #4
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
Sep 9 '07 #5
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
Sep 9 '07 #6

"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
Sep 9 '07 #7

"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
Sep 9 '07 #8
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
Sep 10 '07 #9
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
Sep 10 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Harald Armin Massa | last post: by
1 post views Thread by Peter Steele | last post: by
3 posts views Thread by Niyazi | last post: by
8 posts views Thread by Tim Bücker | last post: by
26 posts views Thread by Ricardo | last post: by
3 posts views Thread by Saizan | last post: by
reply views Thread by =?Utf-8?B?anAybXNmdA==?= | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.