System.Threading.Timers VS Windows Service VS Schedule Tasks

For a task that should be done every hour, whi开发者_如何学Pythonch one do you recommend and why?

since system is running real time applications with high load of CPU and memory and I/O, I want best approach with minimum overhead of checking if it is time to do task or not!

Edit: It's possible that the task takes more than one hour to perform it's job so it shouldn't triggered twice.

Edit: I have an application which is doing mass of image processing and I/O on disk and network. the task can be included both in this application or as an external application.

Depends. In general - is the task something which is part of the realtime application? Then a scheduled task triggering the processing or a system.threading.timer may be relevant. Windows service makes no sense AS YOU ALREADY HAVE ONE.

Example:

• Financial trading applciation that regularly does consolidations of open positions every hour. The trading application IS a windows service. I can jsut use a timer to make sure a method in it is called once every hour passses.

Or is it an external task? Like a routine clearning up logfiles.

• Scheduled task. A windows service has overhead 59 minutes of the 60 every hour, so to say, as it blocks memory.

Depends by what "every hour" means. If every hour is an exact time (4PM, 5PM) I would look at a scheduled task. Keep in mind that a scheduled task will be governed by the priority rules on the server. Meaning, if the server has to do a task with a higher priority your scheduled task may not fire exactly when you want it to. The only issue that comes to mind is that this may be a disconnected process from your current process (another separate application running).

From my experience Thread.Sleep() is much more reliable than Timers. It's not impossible to get a Thread to stop and start at an exact time it just takes a little more work.

In my situation we had a windows service where the Thread would sleep for X minutes then check the database to find out if it was time to do something. It was a very stable way for running a task throughout the day. We used a scheduled task in the beginning for simplicity but ran into the service priority issue a couple of times. Which is why we ultimately went to the Thread.Sleep() approach.

If the task is a long running task and could span the entire hour you are looking at a multi-threaded service which gives you a single point of failure for multiple tasks. I would start out with a scheduled task until it proves it can't do the job.