|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
How do I schedule events for execution ?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 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 -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: Show quoteHide quote > 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 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 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 > As what you, Cor, suggest, I am not clear on the reason to call a sub Splits your program, one is the scheduler and one is the one which is doing > main. Wouldn't be a new thread just the same thing? > 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 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!!! 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 pamelaflue***@libero.it wrote: Show quoteHide quote > -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 > > 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? 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? <pamelaflue***@libero.it> wrote in message news:1137590881.969877.137220@g14g2000cwa.googlegroups.com... A few questions.> 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? > 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 > 1) Are we talking tens or hundreds of tasks? Actually, depending on how the program is used, the could even becomethousands. > 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. Well, based on my previous experiences with timers and doing the loop> 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. 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? Show quoteHide quote > Just my $0.02. > > Al Reid <pamelaflue***@libero.it> wrote in message news:1137596874.766761.206380@z14g2000cwz.googlegroups.com... Still should not be a big problem> > > 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. Then there is no reason to fire the timer more than a little more than twice per minute (Nyquist sampling theory)> > Yes minutes would be fine > > > 3) What is the impact of a scheduled task starting one minute late? Ok> > 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. Then you probably need to spawn a thread or task when it's time to run the scheduled task.> > 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 Just my opinion, based on the limited info in this thread, but it seems you are making this more complicated than necessary.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? 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. Show quoteHide quote > > > Just my $0.02. > > > > Al Reid > > 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. Thank you Al, if I will decide for the timer approach I will certainly> 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. > 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
Show quote
Hide quote
<pamelaflue***@libero.it> wrote in message news:1137598587.639678.50000@g44g2000cwa.googlegroups.com... 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.> > > 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... > > 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. Show quoteHide quote > -Pam > 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: Show quoteHide quote > <pamelaflue***@libero.it> wrote in message news:1137598587.639678.50000@g44g2000cwa.googlegroups.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 > > <pamelaflue***@libero.it> wrote in message news:1137604113.039563.244460@o13g2000cwo.googlegroups.com... I'm not sure about "sucking", but it is surely using system resources, not necessarily CPU time, but memory (real/virtual), handles> Really a sleeping thread is sucking resources? > > -Pam > and other assorted OS resources. 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 pamelaflue***@libero.it wrote: Show quoteHide quote > 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? > R. MacDonald ha scritto:
> Hi, Pam, Can you suggest a general approch which allow to deal with any kind of> > 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. 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. Show quoteHide quote > <pamelaflue***@libero.it> schrieb:
> I want to do a large number of scheduled task (say 80). Each task can Wrapper Classes for the Windows Task Scheduler> 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. <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/> 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? 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 <pamelaflue***@libero.it> wrote in message Show quoteHide quote news:1137546629.498886.231520@f14g2000cwb.googlegroups.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 > 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 
Other interesting topics
How to check datatable.select
How do menu list with one check looping through datareader ShellExecute in VB2005 How to minimize to system tray ? VS 2003 Keep software running Working with structures and the New keyword Custom Property array of interface? Using SP_Password with VB.NET but keep getting "old (current) password incorrect for user" |
|||||||||||||||||||||||
