0

At the moment my application has 15 (independent of each other) threads with the following structure

while(true)
{
    //do repeating work
    Thread.Sleep(x time);
}

Recently I learnt a little of Quartz and I wonder would it be better for performance to remove these threads with while loops and organise "//do repeating work" as Quartz job that at the end recursively schedules next call of this job?

eXPerience
  • 346
  • 1
  • 3
  • 19

2 Answers2

1

If you are using while(true) and Thread.Sleep you will have a lot of threads that a lot of time will be blocked (sleeping), wouldn't it be better that if some thread is not needed now for specific operation it will be free to do another?

You should use your threads carefully, they are an expensive resource of your app!

While I'm not sure exactly how Quartz internally works I'm sure it isn't blocking a lot of threads for no reason and it will save you the need to manage all the threads by yourself in an efficient way.

You can compare the usage of Quartz to the usage of a timer (which doesn't block threads for no reason either and also should be prefered over using while(true) and Thread.Sleep) with a few more advantages that timer is missing:

  • Timers have no persistence mechanism.
  • Timers have inflexible scheduling (only able to set start-time & repeat interval, nothing based on dates, time of day, etc.
  • Timers don’t utilize a thread-pool (one thread per timer)
  • Timers have no real management schemes - you’d have to write your own mechanism for being able to remember, organize and retreive your tasks by name, etc.

Taken from Quartz.NET - Frequently Asked Questions

Community
  • 1
  • 1
YuvShap
  • 3,825
  • 2
  • 10
  • 24
1

The answer depends on architecture of your application and nature of your "repeating work". Using of threads has a lot of advantages: you can dispatch pieces of work independently without additional overhead for manage queue of tasks, you can assign different priorities for different threads, mark them as background or foreground and so on. In short - you get flexibility in exchange for some loss of efficiency, which is usually can be ignored for 15 threads.

What I can advice: use ManualResetEvent.WaitOne instead of Thread.Sleep - it allows you signal to all your thread to shutdown correctly and immediately when your application stops or restarts.

olk
  • 199
  • 1
  • 2
  • 8
  • I wrote while(true)" to make it look more generic, it's actually "while(!_appExit)" where – eXPerience Oct 23 '16 at 09:22
  • where "_appExit" is boolean which is changed before exitting – eXPerience Oct 23 '16 at 09:23
  • It is not about escape of cycle, it is about not waiting for Sleep finishing. To shut down promptly with while(predicate) you have to sleep for short timeouts and it could cause performance impact. On the other hand, with WaitOne you can "wake up" immediately after event rising. – olk Oct 23 '16 at 13:55
  • Ahh ok, I got you now:) Thanks a lot for the tip:) – eXPerience Oct 25 '16 at 09:07