Timers in .Net

[m08pvv]

А теперь в примере с двумя таймерами соберём мусор после создания таймеров и… Ничего не выводится, т.к. на таймеры нет ссылок и сборщик мусора их любезно убрал.

[m08pvv]

Да и в примере с 1000 таймеров тоже нет ссылок и сборщик мусора любезно убирает весь список со всеми таймерами.

[f0bos]

Так как проект запущен в режиме «Debug» то все эти переменные будут «живы» до выхода из метода.

[m08pvv]

Это понятно, что в дебаге они будут живы, но не редки случаи, когда люди смотрят, что в дебаге работает, компилят в релиз и получают тыкву.

[deilux]

Мне кажется правильно было бы сделать об этом пометку в тексте статьи. Те, кто благодаря вашей статье наконец-то разберутся, как же работает таймер и что это такое, скорее всего очень удивятся подобному поведению GC.

[HomoLuden]

А можно ли с помощью таймера ядра работать с отсечками менее 15 миллисекунд?

[m08pvv]

Windows — не ОСРВ, поэтому вообще проблематично что-либо гарантировать.
Ну а на тему таймеров была уже хорошая статья.

[m08pvv]

Ещё есть документик от Microsoft на тему таймеров.

[ad1Dima]

А например в WinCE это будет работать, или там для этого нужно другие механизмы использовать?

[m08pvv]

Если использовать хардварный таймер, а не софтовый, то вполне можно добиться высокой точность. А если софтовый таймер, то надо учитывать, что всегда есть задержки.
Ещё есть хорошее сравнение разных систем.

[mayorovp]

Это приводит к добавлению экземпляра класса System.Threading.TimerQueueTimer в его внутреннюю очередь(являющуюся чем-то вроде LinkedList).

Вот именно это-то момент и является для меня самым интересным — какую структуру данных они используют. Была бы гарантия, что там нормальная куча — использовал бы их, а так пришлось писать свой велосипед.

[deilux]

А чем вас не устроил LinkedList?

[f0bos]

Там не используется LinkedList, способ внутреннего хранения таймеров схож с работой LinkedList. Раз такой интерес к этому способу хранения, я допишу об этом позже.

[deilux]

Подождите, здесь явно какое-то более интересная интрига! Ждём ответа автора корневого комментария!

[mayorovp]

Тем, что на десяти тысячах таймеров он будет тормозить.

[deilux]

Насколько я понимаю, при реализации такого механизма таймеров, планировщику нужно после каждого срабатывания таймера последовательно и полностью пробегаться по коллекции и оценивать хранящиеся там значения интервалов. Во всех типах коллекций последовательный перебор работает более-менее одинаково же…

[mayorovp]

Это только до тех пор, пока коллекция неупорядоченная — в упорядоченной не требуется последовательного перебора. А в древовидных еще и вставка с удалением работают быстрее (чем в упорядоченных списках).

[deilux]

Искать в неупорядоченном списке на 10К элементов — действительно гиблое дело. Но кто сказал что реализация очереди таймеров опирается на поиск?

[mayorovp]

Никто не говорил. Более того, я не понял, что вы сейчас сказали.

[deilux]

Я лишь пытаюсь понять, зачем было изобретать собственный велосипед.

[mayorovp]

Чтобы работал быстрее, я же сказал об этом.

[Razbezhkin]

Недавно заметил такую особенность: когда создаешь объект System.Timers.Timer и запускаешь его, то все в порядке, пока веб сервер, в домене приложения которого создан таймер, не обрабатывает большое количество запросов. Если же веб-сервер находиться под нагрузкой (например нагрузочное тестирование с 500 одновременных подключений/запросов) то таймер перестает генерировать событие Elapsed. с чем это может быть связано?

[mayorovp]

Событие Elapsed генерируется в потоке пула. Если потоки пула оказались все заняты запросами и в итоге закончились — событие Elapsed будет ждать в очереди.