Queued Timers
-
I am using the System.Threading.Timer timer. Now if I have a interval set quite low say 10ms it is possible for my timer event handler to be queued as they cannot be prcessed because the UI thread is busy or another application is running. When the UI thread becomes free it then processes all the queued events at the same time. Is it possible to determine programmatically the number of timer event handlers that are being queued. I want to be able to determine when there is a build up of queued event handlers. Some code to demonstrate this would be useful. Also, is it possible to limit the number of timer event handlers that are queued? Thanks, Liam
-
I am using the System.Threading.Timer timer. Now if I have a interval set quite low say 10ms it is possible for my timer event handler to be queued as they cannot be prcessed because the UI thread is busy or another application is running. When the UI thread becomes free it then processes all the queued events at the same time. Is it possible to determine programmatically the number of timer event handlers that are being queued. I want to be able to determine when there is a build up of queued event handlers. Some code to demonstrate this would be useful. Also, is it possible to limit the number of timer event handlers that are queued? Thanks, Liam
You could start a separate thread to do the actual work of the timer, that way the thread that is waiting for the event is never busy. This if course only works if the code is thread safe, as you could have several threads running at the same time. You can use a counter to see how many threads are running. Increase the counter when a task starts and decrease it when it finishes. If the code can't be made fully thread safe, you could queue the events yourself to be able to keep track of them. Still using a separate thread to do the work (to keep the main thread response to the events), but don't start a new thread until the previous finishes. --- b { font-weight: normal; }
-
You could start a separate thread to do the actual work of the timer, that way the thread that is waiting for the event is never busy. This if course only works if the code is thread safe, as you could have several threads running at the same time. You can use a counter to see how many threads are running. Increase the counter when a task starts and decrease it when it finishes. If the code can't be made fully thread safe, you could queue the events yourself to be able to keep track of them. Still using a separate thread to do the work (to keep the main thread response to the events), but don't start a new thread until the previous finishes. --- b { font-weight: normal; }
I found the question a little odd considering the Timer he's using doesn't use events. It uses a callback delegate executed on a seperate thread out of the thread pool. So, my question would be, does each tick get its own thread? If so, then in theory, a 10ms time interval could exhaust the thread pool if the callback code takes more than 10ms to execute. What happens to the Timer then? Does the callback get queued up waiting for the thread pool? Does this queue have an upper limit...the size of the stack, maybe? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
I found the question a little odd considering the Timer he's using doesn't use events. It uses a callback delegate executed on a seperate thread out of the thread pool. So, my question would be, does each tick get its own thread? If so, then in theory, a 10ms time interval could exhaust the thread pool if the callback code takes more than 10ms to execute. What happens to the Timer then? Does the callback get queued up waiting for the thread pool? Does this queue have an upper limit...the size of the stack, maybe? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
OK my terminology may be wrong. I use the following so I use the the wording "event handler" tmrTimersTimer.Elapsed += new ElapsedEventHandler(tmrTimersTimerElapsedHandler); No each tick does not get it's own thread. The callback code takes about 1-2 ms so should complete in plenty of time. Now if another thread has the processor when my timer elapses it will queue. It will continue to queue timer callbacks. When my code gets the CPU back it will empty the queue and execute all the callbacks. What I was hoping to achieve was to interrogate the queue that holds the timer callbacks.
-
OK my terminology may be wrong. I use the following so I use the the wording "event handler" tmrTimersTimer.Elapsed += new ElapsedEventHandler(tmrTimersTimerElapsedHandler); No each tick does not get it's own thread. The callback code takes about 1-2 ms so should complete in plenty of time. Now if another thread has the processor when my timer elapses it will queue. It will continue to queue timer callbacks. When my code gets the CPU back it will empty the queue and execute all the callbacks. What I was hoping to achieve was to interrogate the queue that holds the timer callbacks.
OK. Now you've got me confused. Which timer are you using??? System.Threading.Timer - From your original post. Uses a callback delegate, not an event. System.Timers.Timer - Uses an event called
Elapsed. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome -
OK. Now you've got me confused. Which timer are you using??? System.Threading.Timer - From your original post. Uses a callback delegate, not an event. System.Timers.Timer - Uses an event called
Elapsed. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming GnomeDave, sorry for the mixed up information I think I am confusing myself too. What I have found is both timers:- System.Threading.Timer System.Timers.Timer Will queue and "handler code" if it cannot be processed immediately. the "handler code" will then be processed when CPU time is avaliable. Whereas System.Windows.Forms.Timer Does not queue and the "handler code" is essentially lost. So I my question applies to both System.Threading.Timer System.Timers.Timer Can I find out if there is a queue of "handlers" (either a callback delegate or an event handler) waiting to be processed?
-
Dave, sorry for the mixed up information I think I am confusing myself too. What I have found is both timers:- System.Threading.Timer System.Timers.Timer Will queue and "handler code" if it cannot be processed immediately. the "handler code" will then be processed when CPU time is avaliable. Whereas System.Windows.Forms.Timer Does not queue and the "handler code" is essentially lost. So I my question applies to both System.Threading.Timer System.Timers.Timer Can I find out if there is a queue of "handlers" (either a callback delegate or an event handler) waiting to be processed?
Threading.Timers uses the ThreadPool to execute the callback code. You could try to call ThreadPool.GetMaxThreads and ThreadPool.GetAvailableThreads to see how many are in use, but I doubt it'll be that accurate. Timers.Timer uses Events to notify your app of the Timer Tick, I THINK by sending WM_TIMER messages to your apps message pump. You might try looking into GetQueueStatus[^] to see if it'll return the number of WM_TIMER messages you want. There is no queue of callbacks maintained anywhere. They are executed by the ThreadPool, which does not keep track of the source, or type, of callback to be executed. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome