0

I am working in timer from System.Timers namespace in wpf application.I want some backend behaviour to execute with timers and call in n milliseconds.

Timer sampleTimer = new Timer();
sampleTimer.Elapsed += (sender, e) => CallElapsedEvent();
sampleTimer.Interval = 10000; //called every 10 seconds
sampleTimer.Enabled = true;

public void CallElapsedEvent(){
   Console.WriteLine(DateTime.Now + " - CallElapsedEvent called");
}

Here is the output of the code

16:45:09 - CallElapsedEvent called
16:45:32 - CallElapsedEvent called
16:45:32 - CallElapsedEvent called

Expected behaviour is that after 9th second , it must fire again at 19.But it is called after an interval of 23 seconds and that too twice(at exactly the same sec).This is happening occassionally and causes some unexpected exception.Why is that happening so?

From what I read about ,it allocates thread pool thread every n interval seconds.If elapsed event is not finished it allocates some other new thread.So, in my case is there are no other free worker threads available at 19th second and waits for the thread.

Why is that happening so and is there any way to enter only one thread to fire at a time?

Clemens
  • 123,504
  • 12
  • 155
  • 268
Sowmiya Pr
  • 37
  • 5
  • 1
    Timers are not guaranteed, except that the callback will be made 'at least' after the specified interval. That being said, your situation is unusual. Are you sure you are creating a `System.Timers.Timer`, and not a `System.Threading.Timer` ? – Neil Aug 02 '22 at 13:37
  • @Neil A `System.Threading.Timer` would need the callback passed into the constructor so this is definitely `System.Timers.Timer` – DavidG Aug 02 '22 at 13:49
  • @Clemens I want a mutithreaded timer without disturbing the UI thread as in my case it is not updating the UI and does some work only in backend. – Sowmiya Pr Aug 02 '22 at 13:49
  • @Neil Yes..I am using timer from System.Timers.Timer namespace. – Sowmiya Pr Aug 02 '22 at 13:50
  • Console.WriteLine in a WPF app is not ideal. It takes a lock and requires the debugger to be responsive. One basic reason it is not responsive is it being busy downloading PDB files, that can easily take 20+ seconds. Get ahead by disabling the symbol server and a decent logging library. – Hans Passant Aug 02 '22 at 14:02
  • Print hash code of the sender. It looks like you instantiate more than one timer – Boppity Bop Aug 02 '22 at 14:34
  • Another thing you can check is `e.SignalTime`, when was the event actually raised. – DavidG Aug 02 '22 at 14:38
  • Related: [Synchronizing a timer to prevent overlap](https://stackoverflow.com/questions/684200/synchronizing-a-timer-to-prevent-overlap) – Theodor Zoulias Aug 02 '22 at 15:09
  • Suggest you also look into the new `System.Threading.PeriodicTimer`, Nick Chapsas did a recent video on it. – FreddyFlares Aug 03 '22 at 13:00
  • Are you using the built-in thread pool (`ThreadPool.QueueUserWorkItem`)? The `System.Timers.Timer` also uses that thread pool, you might got into a situation where that thread pool is 'out of threads', and in some situations it takes time to create new ones – Aviran Ben David Nov 12 '22 at 07:48

0 Answers0