[RESOLVED] Multiple period infinite timer

Hi Folks

Im looking for some advice on how to structure my program which will use threads (Im still only learning about threads though).

I have a bunch of jobs that need to do one step then each job needs to wait a certain time (all may be different) then run the next step in the job, then wait again.
The job threads can be started at any time, i.e. whenever the user wants to start a new work item and can all have different wait periods.

I thought instead of having each work item have a thread that then needs to sleep whenever the time period needs to start there could just be a single timer thread and a single work item thread and a bunch of work item context/state objects. This way a new work item would have a context created, do its first step, then register a (relative) time with the timing thread (like setting an alarm) and then stop. Then when the timing thread reaches the relevant time it raises an event which identifies the work item, reads the related context object and runs the next step which may register another new alarm time.

With multiple jobs this would then require multiple "alarms" and a timer that runs forever, until it's own thread is told to abort (e.g. at application closing).

First off does this sound like a "good VB" way of doing things?
Can a timer be made to behave this way? What sort of timer is best (Im thinking system.threading.timer)?
Do I need to specifically create a thread for a timer or is one created by the system when a timer is run (Im thinking the system does)?

Im currently thinking that this could be very simple by creating the relative times by just reading the current timer value, adding whatever period the work item needs to wait then adding it to a list or array. Then the timer tick event can check the array and see if the new current timer value is greater than any of the times listed.

Does that sound OK? It sounds a bit clunky to me, like their may be a more efficient way of doing things - like maybe somehow creating an event for each relative time and having the timer raise the event whenever it passes a relative time.... hmmm mainly I think I'd like to be able to get rid of the need to search a list of the alarm times that is required by the former approach as if the list starts to become long the search loop could run long enough that another "alarm" should occur while it is busy

Thanks for any input :)

Edit: Meant to mention that times could be on the scale of seconds to hours

Edit 2: Found that system.threading.timer does create its own thread but uses the thread pool - ruling out priority elevation which would most likely be wanted for a timer thread that performs as intended here (It's little thing like this that make me unsure if my design idea is "good VB" or not).

Why does it need to stop and wait?

-tg

Hi techgnome

Each job/work item in the program reads some data from a db and uses it to build commands that it sends to an embedded server. Once the commands are sent the embedded system starts performing some actions. The action needs to run for X amount of time (as determined by the info from the DB) so the work item needs to either stop or wait, for X amount of time, then do it all again for the next action the embedded system should perform

i.e. Each work item has a set of actions that need to be executed at certain, sequential, times.

I was thinking rather than having something (a thread) running for each work item there could just be a function that used the required context object for a work item that would perform this functionality for whichever work item - thus only one thread would be needed (or more if the function needs to run again for another work item before it has finished its previous iteration)

Thanks

You can certainly build it this way. Any timer with sufficient resolution will suffice. However, your initial description made it sound like there is little advantage to the timer. If you know how long each thread will need to sleep, there is no penalty at all to using Thread.Sleep on the thread (as long as it is not the UI thread), so what advantage would you gain by dealing with the timer, which is clearly fairly complicated.

Hi Shaggy Hiker

I was thinking that if I have, say, 150 embedded systems to run and each one needs a thread, that's 150 threads, plus extras that may be used for R/W to the DB or Tcp Connections.
Whereas if I do it the timer way There is just the timer and threads for however many systems need to have their settings changed at a particular point in time. Obv. this could possibly be the full 150 sometimes, but would most often be a lot less.

The thing is I want it to be as scalable as possible. Currently I would expect a maximum of about 30-ish systems but would like to be able to scale to possibly several 200 or so...

Do you think implementing in this way would gain me much in this regard, vs dev time/complexity ?