3

I need to have a thread in my app that will be long running (it is a job scheduler, Cron like) and will be most of the time sleeping. So not much CPU and IO. What would you advise me for this . Does a Task with long running option is the proper way to handle this or should I rely on the old fashion Thread and let that thread lives its own life?

Gennady Vanin Геннадий Ванин
  • 10,136
  • 11
  • 75
  • 106
Dave
  • 1,835
  • 4
  • 26
  • 44
  • Wouldn't a Timer be better for this? Maybe [Quartz.Net](http://quartznet.sourceforge.net/) would be a good option too. – Dirk Jun 01 '13 at 14:23
  • @Dirk: I have tried it but does not really like it. I think it is a bit too heavyweight for this kind of job. Further more I need to maintain states between each call. I could probably have a static variable to store this state but I usually try to avoid them. – Dave Jun 01 '13 at 14:25
  • I dare say neither. Why don't you just schedule your work in the thread pool *when you actually need to* instead of creating a thread which will spend most of its life sleeping or blocked? You can use an OrderedTaskScheduler/LimitedConcurrencyLevelTaskScheduler if you require tasks to execute in the exact order in which they were queued. – Kirill Shlenskiy Jun 01 '13 at 14:42
  • 2
    A thread automatically consumes *one million bytes of both virtual memory and page file space* (remember, thread stacks are committed in the CLR, not just reserved) so your thought that a Timer is *too heavyweight* doesn't make much sense. You're already willing to use the most heavyweight object there is in common usage; almost *everything* is lighter than a single-purpose dedicated thread. – Eric Lippert Jun 01 '13 at 15:07
  • 1
    Or perhaps you meant that Quartz.NET was too heavyweight; I wouldn't know anything about that. But still: you are always better off using the right tool for the job. Timers are for running code after a specific interval, so I would be inclined to use one rather than attempting to write my own. – Eric Lippert Jun 01 '13 at 15:14
  • @EricLippert: I agree. I did not think about Timer when thinking about heavyweight but Quartz.Net. Under the hood I do use Timer for timed operation. You are right what makes me go to the Task or Thread path is that I need to store a state (it is a distributed lease on Azure) as I just want to have a single Cron working across all my workers. I need this scheduler because I need to refresh the lease periodically or elect a new scheduler if the former scheduler crash(which never happen :) ) – Dave Jun 01 '13 at 15:17
  • @EricLippert: Does a Task share the same resource problem as a Thread ? – Dave Jun 01 '13 at 15:18
  • 2
    @Dave: A long-running task can allocate a thread out of the thread pool. The purpose of the pooling strategy is of course to reduce the cost of creating and destroying heavyweight objects like threads. My advice: write the program as seems best to you and as you do, measure its performance *using metrics that are meaningful to your customers*. That way you'll know if one of your choices is causing customer pain. – Eric Lippert Jun 01 '13 at 15:26

1 Answers1

1

A Task with the long running option is fine. It will create a new Thread in the background and you don't have to bother about the details.

user1908061
  • 616
  • 5
  • 12