Pull to refresh

Comments 23

А теперь в примере с двумя таймерами соберём мусор после создания таймеров и… Ничего не выводится, т.к. на таймеры нет ссылок и сборщик мусора их любезно убрал.
Да и в примере с 1000 таймеров тоже нет ссылок и сборщик мусора любезно убирает весь список со всеми таймерами.
Так как проект запущен в режиме «Debug» то все эти переменные будут «живы» до выхода из метода.
Это понятно, что в дебаге они будут живы, но не редки случаи, когда люди смотрят, что в дебаге работает, компилят в релиз и получают тыкву.
Мне кажется правильно было бы сделать об этом пометку в тексте статьи. Те, кто благодаря вашей статье наконец-то разберутся, как же работает таймер и что это такое, скорее всего очень удивятся подобному поведению GC.
А можно ли с помощью таймера ядра работать с отсечками менее 15 миллисекунд?
Windows — не ОСРВ, поэтому вообще проблематично что-либо гарантировать.
Ну а на тему таймеров была уже хорошая статья.
А например в WinCE это будет работать, или там для этого нужно другие механизмы использовать?
Если использовать хардварный таймер, а не софтовый, то вполне можно добиться высокой точность. А если софтовый таймер, то надо учитывать, что всегда есть задержки.
Ещё есть хорошее сравнение разных систем.
Это приводит к добавлению экземпляра класса System.Threading.TimerQueueTimer в его внутреннюю очередь(являющуюся чем-то вроде LinkedList).
Вот именно это-то момент и является для меня самым интересным — какую структуру данных они используют. Была бы гарантия, что там нормальная куча — использовал бы их, а так пришлось писать свой велосипед.
А чем вас не устроил LinkedList?
Там не используется LinkedList, способ внутреннего хранения таймеров схож с работой LinkedList. Раз такой интерес к этому способу хранения, я допишу об этом позже.
Подождите, здесь явно какое-то более интересная интрига! Ждём ответа автора корневого комментария!
Тем, что на десяти тысячах таймеров он будет тормозить.
Насколько я понимаю, при реализации такого механизма таймеров, планировщику нужно после каждого срабатывания таймера последовательно и полностью пробегаться по коллекции и оценивать хранящиеся там значения интервалов. Во всех типах коллекций последовательный перебор работает более-менее одинаково же…
Это только до тех пор, пока коллекция неупорядоченная — в упорядоченной не требуется последовательного перебора. А в древовидных еще и вставка с удалением работают быстрее (чем в упорядоченных списках).
Искать в неупорядоченном списке на 10К элементов — действительно гиблое дело. Но кто сказал что реализация очереди таймеров опирается на поиск?
Никто не говорил. Более того, я не понял, что вы сейчас сказали.
Я лишь пытаюсь понять, зачем было изобретать собственный велосипед.
Чтобы работал быстрее, я же сказал об этом.
Недавно заметил такую особенность: когда создаешь объект System.Timers.Timer и запускаешь его, то все в порядке, пока веб сервер, в домене приложения которого создан таймер, не обрабатывает большое количество запросов. Если же веб-сервер находиться под нагрузкой (например нагрузочное тестирование с 500 одновременных подключений/запросов) то таймер перестает генерировать событие Elapsed. с чем это может быть связано?
Событие Elapsed генерируется в потоке пула. Если потоки пула оказались все заняты запросами и в итоге закончились — событие Elapsed будет ждать в очереди.
Only those users with full accounts are able to leave comments. Log in, please.