How are services that run on a schedule implemented?

Quartz.NET did not try, try, suddenly like it =)

Usually "Right" everyone has their own, my thoughts are as follows:

1. Short intervals (seconds, minutes)

The set of tasks for short time intervals is usually fixed and the tasks are closely related. Therefore, the option proposed by you will be quite appropriate, but there are drawbacks: When the service is restarted, all tasks will be interrupted in an arbitrary location, unless a special service termination code is provided for, the timers will be restarted. To change the intervals, you must restart the service, unless a special command is provided for this.

The advantages include the possibility of direct data transfer between tasks using the usual data types, a sufficiently high accuracy of time response, for ultra-short intervals you can use a timer based on StopWatch , which has the maximum accuracy of time measurement.

An alternative can be a set of console programs (one task - one program) launched using the system scheduler. For short intervals, the advantages of this method are very doubtful, if at all.

2. Average intervals (hours, days)

The set of tasks for such intervals sometimes requires changes in the set of actions performed, as well as forcing tasks to schedule me, which also imposes a number of requirements on the applied solution.

In the service with internal timers, it is necessary to provide special methods for managing the list of tasks to be performed, forcing individual tasks to be started, for saving the schedule in spite of an unplanned launch. It is also worth noting that the service will constantly hang in the memory and expend resources, especially sad if somewhere there is a slight leak that was not immediately detected.

For a set of programs working on the system scheduler, nothing extra needs to be done, this functionality is already incorporated in the system scheduler. In any case, the system task scheduler is always running, but your tasks will consume resources only at run time, the problem of permanent memory leaks during long-term work is absent. Adding and deleting tasks is not difficult. You can update programs to perform tasks independently of each other. An increase in performance is possible due to the launch of particularly difficult tasks on individual computers. The disadvantages - the need to exchange data between related tasks through files. Given the length of the intervals, file sharing is not very scary, but it will take time to develop the protocol and file format.

3. Long intervals (weeks, months, years)

A set of tasks is almost guaranteed to change in the course of work, and tasks are rarely related to each other, or combined into one big task. Other participants may not agree with me, but for me personally, at such intervals it is simply inconvenient to use a monolithic service. In addition, the service will have to provide for the synchronization of time, at least with the system clock, and the calendar, if you want to run the task, for example, once a week, or on the first days of months. The system scheduler in this case frees the developer from having to write anything other than the code of the tasks to be performed.

4. Indefinite intervals or event work

Of course, this option has little relevance to timers, but as part of comparing the two approaches, it is worth considering.

In service it is necessary to provide the code listening necessary events. The processed events can be moved to the configuration, but adding or deleting actions without rebuilding and reinstalling the service can no longer be done.

The system scheduler can also trigger by events, but is limited to events that the operating system monitors. To add something of your own, you will have to determine and register in the system log the source of events, event codes, maybe even a separate event log, etc. In some difficult cases, the result is worth the time spent. Also, for complex cases of event handling, you can write your scheduler, which will respond to everything you need and run programs to process tasks instead of the system scheduler.

In general, for work on events, we can assume that both methods are equivalent.

Own task scheduler.

In some cases, using the system scheduler is not very convenient. Then you can implement your own. The idea is quite simple:

• one timer with a fixed minimum step, for example, once a second.
• On the event of the timer compare the current time with the schedule of scheduled tasks.
• we run in a separate thread or process the execution of tasks whose time is less than or equal to the current one.