How do I schedule events for execution ?

[pamelafluente]

Hi guys!

I want to do a large number of scheduled task (say 80). Each task can
be run at a certain time every given weekday. For instance at 10am and
5pm on each monday, etc.

I would like to ask what is the best approach to check and run the
scheduled events.

The first (perhaps silly) thing that come up in my mind is to use a
Timer and on the"Tick" event to check if there are task that need to be
fired.

However this approach seems awkward and it would waste a lot of
resources. I think that if I keep busy my program checking at each tick
whether there are task to run, I would only degrade the whole
performance of the program (which must do several other heavy tasks).

Could anyone be so kind as to suggest me what is the best approach to
this problem. Is there a way to have the events fired directly at the
given times without using the times stuff, or using it more
appropriately ?

Thank you very much in advance.

-Pam

 

[Cor Ligthert [MVP]]

Pam,

Why does one of the timers use a lot of resources?

The first thing I would use in your situation (given that the task are in
one program otherwise it would be the scheduler)

And if it is a windowsform just the windowsform timer.

Just my thought,

Cor

 

[pamelafluente]

-All task to be executed are stored in one program.
-It's a windows application.
-The number of scheduled task can ve very high.

The naive approach I first thought of is to define a Timer. Then in the
"Tick" handler to place the code that examines all task and decides if
there are task which need to be executed.

I was thinking that placing this check loop (which could be quite long)
in the Tick event (and therefore executing it several times per
second), would be an awkward approach, in the sense that I would keep
busy a thread just doing a loop which most the times is not aeven
followed by the execution of any of the scheduled tasks.

In this sense I was feeling that there is a waste of resources.

1. What is the best approach to do that?

2. When I start a new tast do I have to create a new thread to run it.
Or is it automatically assigned to a new one by the Tick handler?

-Pam

Cor Ligthert [MVP] ha scritto:

 

[Cor Ligthert [MVP]]

Pamela,

I never had your problem. The main problem is in my idea not the timer, it
is the ammount of memory you are consequently allocating.

I think that I would create a windowform program (the most easiest solution)
or windowservice that uses a timmer.

Than use that program to start depending on the timer your other program
passing a parameter what it has to do.

That program should than start with a sub main. If you don't know how, than
reply, Herfried has given much samples for that in this newsgroup.

I hope this helps,

Cor

 

[pamelafluente]

I have the suspect that the tick event open a new thread for each task.

Can anyone confirm that?
or is it necessary (or advisable) to manually create a new thread to
execute a scheduled task?

Also what is the advisable timer interval, in order not to bother to
much the main appication?

As what you, Cor, suggest, I am not clear on the reason to call a sub
main. Wouldn't be a new thread just the same thing?

-Pam

 

[R. MacDonald]

Hello, Pam,

Re: > In this sense I was feeling that there is a waste of resources.

Perhaps you could determine the interval of time until the next
scheduled event during one pass. Then use something like

System.Threading.Thread.Sleep(timToSleep)

to wait until the scheduled time. Of course, this requires a little
more coding to allow for things like dynamically adding/deleting
scheduled items and the host system being occasionally shut down.

Cheers,
Randy

 

[pamelafluente]

This approach sounds a lot more intelligent and efficient than the my
naive one.

So what about * forgetting about the TIMER * and, anytime a new
sheduled task is defined by the user, I create a new thread and let it
sleep until the event must be fired?

Any other smart suggestion?

 

[pamelafluente]

As pointed out by Randy, one problem with the sleep approach is related
to system or program shut down. Assume that I have programmed a thread
to weak up in 14 hours, 13 minutes, 30 seconds. What about if the
system is shut down abruptly (for instance by a * power interruption *
due to a black out ) and then restarted after 5 hours?

Any idea to handle that?

Can we program that a thread should start at a given time instead of
expressing the duration of the sleep period?

 

[Al Reid]

As pointed out by Randy, one problem with the sleep approach is related
to system or program shut down. Assume that I have programmed a thread
to weak up in 14 hours, 13 minutes, 30 seconds. What about if the
system is shut down abruptly (for instance by a * power interruption *
due to a black out ) and then restarted after 5 hours?

Any idea to handle that?

Can we program that a thread should start at a given time instead of
expressing the duration of the sleep period?

A few questions.

1) Are we talking tens or hundreds of tasks?
2) What is the precision of the start times? I would expect it to be minutes, not hours.
3) What is the impact of a scheduled task starting one minute late?
4) Will another task be started before the previous task has completed or do they need to run in sequence.

Based on the answers to the above, I really don't think that the resources used to loop through the task list will be that great.
There is probably no need to fire the timer more frequently than about every 29 seconds. If multiple tasks will run concurrently,
then consider spawning them as separate threads or tasks, otherwise, they can all be executed from the scheduler's thread.

Just my $0.02.

Al Reid

 

[Herfried K. Wagner [MVP]]

I want to do a large number of scheduled task (say 80). Each task can
be run at a certain time every given weekday. For instance at 10am and
5pm on each monday, etc.

I would like to ask what is the best approach to check and run the
scheduled events.

Wrapper Classes for the Windows Task Scheduler
<URL:http://mvps.org/emorcillo/en/code/shell/tasksched.shtml>

A New Task Scheduler Class Library for .NET
<URL:http://www.codeproject.com/csharp/TSNewLib.asp>

Task Scheduler Library for .NET
<URL:http://www.codeproject.com/csharp/taskschedulerlibrary.asp>

Task Scheduler for .NET
<URL:http://www.msjogren.net/dotnet/eng/samples/misc.asp>

 

[R. MacDonald]

Hi, Pam,

As Al points out, there are a number of important factors that can
influence how you choose to design your solution. But the problems of
system shutdowns and dynamically adding/deleting tasks will be pretty
much the same whether you choose to use a timer, sleep a single thread,
or sleep multiple threads.

If it is important to be able to run pre-sheduled tasks after a shutdown
then you will need to save a reference to the tasks and their absolute
times in persistent storage and reload/reschedule the saved tasks when
the scheduling application restarts.

Cheers,
Randy

 

[pamelafluente]

1) Are we talking tens or hundreds of tasks?

Actually, depending on how the program is used, the could even become
thousands.

2) What is the precision of the start times? I would expect it to be minutes, not hours.

Yes minutes would be fine

3) What is the impact of a scheduled task starting one minute late?

I guess would be acceptable.

4) Will another task be started before the previous task has completed or do they need to run in sequence.

They are independent, for now.

Based on the answers to the above, I really don't think that the resources used to loop through the task list will be that great.
There is probably no need to fire the timer more frequently than about every 29 seconds. If multiple tasks will run concurrently,
then consider spawning them as separate threads or tasks, otherwise, they can all be executed from the scheduler's thread.

Well, based on my previous experiences with timers and doing the loop
every few seconds, I would rather to avoid that solution, because I
think it's ugly and cumbersome. I like the idea of a task viewed as a
sleeping thread until the "fire time". This should also be neater to
program. The problem now would be to find a solution to the "power
interruption" (abrupt shutdown) problem. That is, how do I restore my
thread running so that the firetime remains unchanged?

 

[pamelafluente]

R. MacDonald ha scritto:

Hi, Pam,

As Al points out, there are a number of important factors that can
influence how you choose to design your solution. But the problems of
system shutdowns and dynamically adding/deleting tasks will be pretty
much the same whether you choose to use a timer, sleep a single thread,
or sleep multiple threads.

If it is important to be able to run pre-sheduled tasks after a shutdown
then you will need to save a reference to the tasks and their absolute
times in persistent storage and reload/reschedule the saved tasks when
the scheduling application restarts.

Can you suggest a general approch which allow to deal with any kind of
interruption. I don't mean ordinary system shutdown. (Clearly if the
application is by ordinarily mean I can persist the closing times and
then restore the threads when the application is restarted.) I mean a
sudden loss of power which shut off suddenly the machine for a few
hours.

 

[pamelafluente]

Thank you Herfried, I already saw the first 3. Actually I would like to
program the scheduler within the app, and not by using the OS
scheduler.

But actually this could suggest a mixed solution to be able to resume
after a power loss...

Any idea?

 

[Al Reid]

Actually, depending on how the program is used, the could even become
thousands.

Still should not be a big problem

Yes minutes would be fine

Then there is no reason to fire the timer more than a little more than twice per minute (Nyquist sampling theory)

I guess would be acceptable.

Ok


They are independent, for now.

Then you probably need to spawn a thread or task when it's time to run the scheduled task.

Well, based on my previous experiences with timers and doing the loop
every few seconds, I would rather to avoid that solution, because I
think it's ugly and cumbersome. I like the idea of a task viewed as a
sleeping thread until the "fire time". This should also be neater to
program. The problem now would be to find a solution to the "power
interruption" (abrupt shutdown) problem. That is, how do I restore my
thread running so that the firetime remains unchanged?

Just my opinion, based on the limited info in this thread, but it seems you are making this more complicated than necessary.

If you use the timer approach and spawn the task, this should not be a problem. Just make sure that the scheduler runs on reboot.
If you want to be fancy, you can keep track of task launch and completion status and upon restarting the scheduler task, examine the
statuses and restart any tasks that did not cpmplete. Yau may even consider making the scheduler a Windows Sercice.

 

[pamelafluente]

If you use the timer approach and spawn the task, this should not be a problem. Just make sure that the scheduler runs on reboot.
If you want to be fancy, you can keep track of task launch and completion status and upon restarting the scheduler task, examine the
statuses and restart any tasks that did not cpmplete. Yau may even consider making the scheduler a Windows Sercice.

Thank you Al, if I will decide for the timer approach I will certainly
do as you suggest. However, I still am afraid that the continuous loop
would unnecessaily suck.

I have a simple idea based on Rod suggestion.

Let's make a simple example.

---------------------------------------------------------------------------------------------------
Assume now is Sunday, 10:00am. The users schedule Task1 to be to fire
each Monday at 10:00am.

When the user schedule the task, I can persist the schedule information
on a file.

I can start a thread with SLEEP = 24 hours, and at the same time write
on the file
that Task1 need to be run each Monday at 10:00am.

In case of (normal or abnormal) program termination, when the user
restart the program
I can read the file. Assume that the program is restarted on Monday
8:00:
I can reprogram Task1 on a new thread with SLEEP 2 hours.
---------------------------------------------------------------------------------------------------

What do you think of this approach. Seems simple and effective (in
theory) and I would avoid the continuous loop...


-Pam

 

[Al Reid]

Thank you Al, if I will decide for the timer approach I will certainly
do as you suggest. However, I still am afraid that the continuous loop
would unnecessaily suck.

I have a simple idea based on Rod suggestion.

Let's make a simple example.

---------------------------------------------------------------------------------------------------
Assume now is Sunday, 10:00am. The users schedule Task1 to be to fire
each Monday at 10:00am.

When the user schedule the task, I can persist the schedule information
on a file.

I can start a thread with SLEEP = 24 hours, and at the same time write
on the file
that Task1 need to be run each Monday at 10:00am.

In case of (normal or abnormal) program termination, when the user
restart the program
I can read the file. Assume that the program is restarted on Monday
8:00:
I can reprogram Task1 on a new thread with SLEEP 2 hours.

You seem to be worried about the cpu resources required to scan for tasks that need to run (up to thousands) every 29 or 30 seconds.
I don't see that as a real issue. You are willing to use the resources to spawn thousands of sleeping tasks/threads, sitting arounf
in memory, using resources, just waiting for the opportunity to run. It seems to me that that approach is more resource hungry and
perhaps, more prone to causing system problems. If you spawn the task/thread only when required, the overall system resources would
be minimized, as only the currently running tasks are loaded and running.

Again, just my $0.02.

 

[pamelafluente]

mmm, You may be right...

.... I would like to hear some other opinion before deciding.

What do you other guys think ?

-Pam


Al Reid ha scritto:

 

[pamelafluente]

Really a sleeping thread is sucking resources?

-Pam

 

[Al Reid]

Really a sleeping thread is sucking resources?

-Pam

I'm not sure about "sucking", but it is surely using system resources, not necessarily CPU time, but memory (real/virtual), handles
and other assorted OS resources.