Windows Service: Timer vs Thread
-
Hello All, I was wanting to start a discussion about best practice when creating threads in a Windows Service. I have a service that has multiple process running at the same time (6-10). Is it better to use timers or threads? I personally prefer threads because I can end them all with a single line of code where as if have to end each timer individually. Plus with threads, you don't have to worry about it calling it self until you want it to. Does anybody have any other thoughts on this? What's a better way to go and why? Which is lighter on PC usage and memory? etc etc Thanks in advance, Bryan
-
Hello All, I was wanting to start a discussion about best practice when creating threads in a Windows Service. I have a service that has multiple process running at the same time (6-10). Is it better to use timers or threads? I personally prefer threads because I can end them all with a single line of code where as if have to end each timer individually. Plus with threads, you don't have to worry about it calling it self until you want it to. Does anybody have any other thoughts on this? What's a better way to go and why? Which is lighter on PC usage and memory? etc etc Thanks in advance, Bryan
BBatts wrote:
Is it better to use timers or threads?
When the timer fires it uses a thread.
BBatts wrote:
Plus with threads, you don't have to worry about it calling it self until you want it to.
Huh? If the thread is running and not blocked then it is fact running. If you weren't saying that I am not sure what you are saying because the execution flow is always in one thread or another.
BBatts wrote:
because I can end them all with a single line of code
Not sure what that means exactly. At least sometimes one can't just end threads arbitrarily and sometimes one must end them in a certain order. But the same applies to timers but only to the extent that they too are using threads.
-
BBatts wrote:
Is it better to use timers or threads?
When the timer fires it uses a thread.
BBatts wrote:
Plus with threads, you don't have to worry about it calling it self until you want it to.
Huh? If the thread is running and not blocked then it is fact running. If you weren't saying that I am not sure what you are saying because the execution flow is always in one thread or another.
BBatts wrote:
because I can end them all with a single line of code
Not sure what that means exactly. At least sometimes one can't just end threads arbitrarily and sometimes one must end them in a certain order. But the same applies to timers but only to the extent that they too are using threads.
"When the timer fires it uses a thread." Yes. To be more specific a timer is an object the fires a thread periodically. "Huh? If the thread is running and not blocked then it is fact running" If the thread your timer has fired takes longer to execute than the interval level of a timer it will fire again. Unless, of course, you disable it. Where as if one is using a System.Thread there is more direct control over when and how the thread is fired. I can't think of any reason to use a Timer as opposed to System.Thread...in a windows service. I guess that was the point of my post.
-
Hello All, I was wanting to start a discussion about best practice when creating threads in a Windows Service. I have a service that has multiple process running at the same time (6-10). Is it better to use timers or threads? I personally prefer threads because I can end them all with a single line of code where as if have to end each timer individually. Plus with threads, you don't have to worry about it calling it self until you want it to. Does anybody have any other thoughts on this? What's a better way to go and why? Which is lighter on PC usage and memory? etc etc Thanks in advance, Bryan
-
Hello All, I was wanting to start a discussion about best practice when creating threads in a Windows Service. I have a service that has multiple process running at the same time (6-10). Is it better to use timers or threads? I personally prefer threads because I can end them all with a single line of code where as if have to end each timer individually. Plus with threads, you don't have to worry about it calling it self until you want it to. Does anybody have any other thoughts on this? What's a better way to go and why? Which is lighter on PC usage and memory? etc etc Thanks in advance, Bryan
-
Quote:
I have a service that has multiple process running at the same time (6-10)
is it multiple thread or process..??and what are you trying to achieve with timer or thread..? can you please be bit more specific..
vikas da
Yes. It performs varies disk related services. Clean Up, Archive, Backup, etc etc. There can be up to 6 process running at the same time. I currently create and fire 6 System.Threads on the Start() event. Each thread has a loop that keeps it running with a Thread.Delay, so they look something like this:
private void WorkerThread_DoWork()
{
while (contiueWorking)
{
//Perform Some TaskSystem.Threading.Thread.Sleep(10000);}
}The task may or may not take longer than 10 seconds to complete, depending on the amount of data that is being managed. So, my question is (and admittedly I'm stumbling trying to ask it) would it be better to have 6 timers in this situation or should I stick with the threads? Or am I simply overthinking it.
-
Yes. It performs varies disk related services. Clean Up, Archive, Backup, etc etc. There can be up to 6 process running at the same time. I currently create and fire 6 System.Threads on the Start() event. Each thread has a loop that keeps it running with a Thread.Delay, so they look something like this:
private void WorkerThread_DoWork()
{
while (contiueWorking)
{
//Perform Some TaskSystem.Threading.Thread.Sleep(10000);}
}The task may or may not take longer than 10 seconds to complete, depending on the amount of data that is being managed. So, my question is (and admittedly I'm stumbling trying to ask it) would it be better to have 6 timers in this situation or should I stick with the threads? Or am I simply overthinking it.
I'd be using Timers for this purpose. As it's by far easier to control the execution of the timer instead of a thread. I generally use the System.Threading.Timer with the following callback pattern: Initialize it like that:
// Declaration:
System.Threading.Timer _timer;//Initialization:
_timer = new System.Threading.Timer(OnTimer, null, 10000, System.Threading.Timeout.Infinite);And this callback method
private void OnTimer(object state) {
try {
// Do your stuff here
} catch (Exception ex) {
// Errorhandling
} finally {
// the first parameter is the delay until the callback method will be called again
// the second parameter defines the interval in which it will be rais. Timeout.Infition -> Disabled
_timer.Change(10000, System.Threading.Timeout.Infinite);
}
}To stop the timer just call:
_timer.Change(System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite);
If you use it like that it should never ever be called concurrently as after the first event the timer is disabled until you manually reenable it (i.e. in the finally clause) Greetings
-
I'd be using Timers for this purpose. As it's by far easier to control the execution of the timer instead of a thread. I generally use the System.Threading.Timer with the following callback pattern: Initialize it like that:
// Declaration:
System.Threading.Timer _timer;//Initialization:
_timer = new System.Threading.Timer(OnTimer, null, 10000, System.Threading.Timeout.Infinite);And this callback method
private void OnTimer(object state) {
try {
// Do your stuff here
} catch (Exception ex) {
// Errorhandling
} finally {
// the first parameter is the delay until the callback method will be called again
// the second parameter defines the interval in which it will be rais. Timeout.Infition -> Disabled
_timer.Change(10000, System.Threading.Timeout.Infinite);
}
}To stop the timer just call:
_timer.Change(System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite);
If you use it like that it should never ever be called concurrently as after the first event the timer is disabled until you manually reenable it (i.e. in the finally clause) Greetings
-
"When the timer fires it uses a thread." Yes. To be more specific a timer is an object the fires a thread periodically. "Huh? If the thread is running and not blocked then it is fact running" If the thread your timer has fired takes longer to execute than the interval level of a timer it will fire again. Unless, of course, you disable it. Where as if one is using a System.Thread there is more direct control over when and how the thread is fired. I can't think of any reason to use a Timer as opposed to System.Thread...in a windows service. I guess that was the point of my post.
BBatts wrote:
System.Thread there is more direct control over when and how the thread is fired.
How exactly do you "fire" a thread in the above? How exactly do you think that process is different than what a timer does?
BBatts wrote:
I can't think of any reason to use a Timer as opposed to System.Thread...in a windows service
Because one wants an action to occur based on something associated with time. For example running a process every hour or once a day.