System.Timers.Timer
both runs and raises events on a 'random', thread pool thread. The callbacks and the timer ticks will run concurrently, meaning you would have overlapping execution of these events in your situation where the interval is less than the time the method takes to terminate.
Even though this behavior is different from that which I posted about below, you still don't want to do this. The result will be that the thread pool will eventually become exhausted. It is also probably not your desired functionality.
A solution would be to code it such that concurrent execution is not possible.
- Test some static field to see if an existing iteration is running, and cancel the 'new' instance if so. Testing/setting such a field should be done through a memory barrier.
- Stop the timer upon entering the event, run the code, and then start it again after. If you wish, you can adjust the interval based on how long it took to execute.
- Do not do simple locking to block concurrent executions until former ones are done; that will just go back to the problem I described with the Windows Forms Timer (minus the UI lockup)
Previous Answer
This was the old answer I posted when I thought you were speaking of the Timer in System.Windows.Forms and using it in a Windows Forms program. Because that is not the case, the information below does not apply to you. But I leave it here in case it helps someone else.
Because the Timer control inside the System.Windows.Forms namespace runs on the UI thread, as does its callback, your tick events will pile up, waiting for currently executing operations to complete. You UI will also be locked in the duration.
Therefore, you do not want to do this. Your program will lock up.