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:

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

[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
pa***********@libero.it wrote:

-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:

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]

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]

<pa***********@libero.it> wrote in message news:11**********************@g14g2000cwa.googlegr oups.com...

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]]

<pa***********@libero.it> schrieb:

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>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[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

pa***********@libero.it wrote:

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?

[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?
Just my $0.02.

Al Reid

[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]

<pa***********@libero.it> wrote in message news:11**********************@z14g2000cwz.googlegr oups.com...

1) Are we talking tens or hundreds of tasks?
Actually, depending on how the program is used, the could even become
thousands.

Still should not be a big problem

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

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)

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

I guess would be acceptable.

Ok

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.

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

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?

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.

Just my $0.02.

Al Reid

[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]

<pa***********@libero.it> wrote in message news:11*********************@g44g2000cwa.googlegro ups.com...

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...

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.
-Pam

[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:

<pa***********@libero.it> wrote in message news:11*********************@g44g2000cwa.googlegro ups.com...

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...

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.

-Pam

[pamelafluente]

Really a sleeping thread is sucking resources?

-Pam

[Al Reid]

<pa***********@libero.it> wrote in message news:11**********************@o13g2000cwo.googlegr oups.com...

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.

[Jevon]

I have previously looked into this a bit, and came up with something along
the lines of the following (I've read the rest of the thread up to this
point, and you still seem stuck on the idea of a loop and/or lots of
threads. I don't know how your tasks are stored, but have you thought about:

Upon initialisation and/or startup and/or addition/change to the list of
tasks:
Cancel current timer if not startup.
Re-order tasks by next run time.
Do tick code.

Do tick code:
Check for tasks that should already have run (now > next run time) and run
them if necessary - i.e. if there's been a power failure.
Update the next run time for the task, and insert it into the list in
the correct location (i.e. so you don't mess up the ordering).
Find the task with the next soonest run time and set a timer to run once and
fire at that time which calls Do tick code.
You will need to check what happens if you set a timer with a negative
value - this could happen with tasks that are sheduled to start very close
together - you'd check for tasks that should have run, find the next time,
and by the time the timer has been set up, that time has already passed. In
this instance, the program might never fire the tick code again, and
effectively stall.

With this way, you only need to loop through as many tasks that should have
already run but haven't yet - you stop when you get to the first task with a
"next run time" > now.

Does that make sense? This was written very quickly, so might have a mistake
or two :)

Jevon
<pa***********@libero.it> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

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

[pamelafluente]

Must say that I didn't think about such a way of using the timer. I
like it very much. It's somehow a solution in between what we have
discussing so far. Seems an efficient one...

Leave the word to the others...

-Pam

[Cor Ligthert [MVP]]

> 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?

Splits your program, one is the scheduler and one is the one which is doing
the jobs.

What they have to do is what activity is scheduled, you can pass that, which
is accepted by using a sub main and not the normal initializing from a
mainform (with inbuild sub main) as is standard done in VBNet.

By that you create seperate programs which run on their own threads (as long
as you allow multiple programs with the same name active, what is standard).

Timers are not starting a new threads. (Although some timers run on their
own thread).

I hope this helps,

Cor

[pamelafluente]

Thank you very much to all.

You have been really helpful with this matter.

I am gonna to assemble my solution taking the best from all of your
generous suggestions !!!

THANKS!!!