Почему Threading.Timer делегирует остановку?

Question

Приложение WPF запускает Threading.Timer в начале процесса загрузки. Интервал таймера составляет 100 мс, а код в делегате таймера обычно занимает около 70 мс (он выполняет ряд операций в циклах for, некоторые из которых связаны с чтением из последовательного порта). После запуска таймера остальная часть приложения инициализируется (типы, зарегистрированные в каркасе DI, создание представлений, режимы просмотра, различные другие функции инициализации). За эти несколько секунд код, выполняемый в пределах делегата таймера, полностью «ложится». Он никогда не выходит из строя, и ни один из его серийных прочтений не проходит (это просто удача) - код таймера просто приостанавливает выполнение в течение примерно 3 секунд.

Я могу только предположить, что весь этот материал для запуска (в потоке пользовательского интерфейса) получает более высокий приоритет, не позволяя потоку таймера получать какое-либо время процессора. Могу ли я что-нибудь сделать? Запуск таймера позже в процессе начальной загрузки может быть вариантом, но я хотел сначала изучить другие решения.

На боковой ноте, как Threading.Timer обрабатывает «повторное включение» (если это правильный термин), т. Е. Таймер «галочки», пока предыдущий вызов все еще запущен? Выполняет ли следующий вызов «очередь в очереди» и запускается, когда предыдущий завершается, или мне нужно самому справиться с этим?

Answer 1

1) Таймер запускает свои задачи, как только это будет необходимо, нет очереди. Вы можете проверить это самостоятельно с планированием что-то вроде этого:

Console.WriteLine("Sleep"); 
Thread.Sleep(10000); 
Console.WriteLine("Awaken"); 

Вы увидите некоторые результаты, как это с периодом 1 секунду:

Sleep 
Sleep 
Sleep 
Sleep 
Sleep 
Sleep 
Awaken 
Awaken 
Awaken 
Awaken 
... 

2) Вы можете изменить приоритет потока, но это, вероятно, выиграл Вы ничего хорошего не делаете. Все таймеры .net не предназначены для использования в режиме реального времени. Так что нет, вы ничего не можете с этим поделать.