[Win32] Timers

[Vovka]

Как много таймеров программа может создавать? Имеются в виду waitable timers & timer queue timers.
Представьте, что есть некий сервер, в нём есть понятие "юзерской сессии". Число одновременно существующих сессий не превысит нескольких тысяч, а чаще будет намного меньше.
Если этот сервер будет создавать по таймеру на каждую юзерскую сессию, это нормально, или слишком большой расход ресурсов? Правильно ли я понимаю, что timer queue timers несколько более экономные с точки зрения системных ресурсов?

[KVA]

А зачем по таймеру на сессию? Не проще ли какой-нибудь session manager написать, который будет периодически проверять все сессию на предмет timeout?

[Vovka]

А зачем по таймеру на сессию? Не проще ли какой-нибудь session manager написать, который будет периодически проверять все сессию на предмет timeout?

Ну да, если мне тут скажут, что нехрен таймеры плодить, то так и сделаю.
Просто хотел сравнить два решения, плюсы и минусы. Учитывая, что по трудоёмкости они примерно равны.

[blanko27]

По-моему, таймер в Windows-е постоянно принадлежит какому-то из тредов. Т.е. просто таймера без треда не бывает. Для создания 100 независимых таймеров понадобится 100 независимых тредов. Никак не могу вспомнить, что получится, если одному и тому же треду назначить несколько таймеров?

[lx_uk]

По-моему, таймер в Windows-е постоянно принадлежит какому-то из тредов. Т.е. просто таймера без треда не бывает. Для создания 100 независимых таймеров понадобится 100 независимых тредов. Никак не могу вспомнить, что получится, если одному и тому же треду назначить несколько таймеров?

waitable timers & timer queues это объекты ядра. Один или несколько потоков (и процессов) могут владеть несколькоми handle'ами для одного и того же таймера. Ну и использовать несколько waitable таймеров в одном потоке тоже никто не запрещает.

[blanko27]

... использовать несколько waitable таймеров в одном потоке тоже никто не запрещает.

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

[lx_uk]

... использовать несколько waitable таймеров в одном потоке тоже никто не запрещает.

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

Насколько мне известно, то такой привязки не существует. Т.е. таймеры сами по себе в ядре (и срабатывание таймера - это "ядерные" дела) и потоки, оперирующие handle'ами таймеров тоже сами по себе.

[lx_uk]

Как много таймеров программа может создавать? Имеются в виду waitable timers & timer queue timers.
Представьте, что есть некий сервер, в нём есть понятие "юзерской сессии". Число одновременно существующих сессий не превысит нескольких тысяч, а чаще будет намного меньше.
Если этот сервер будет создавать по таймеру на каждую юзерскую сессию, это нормально, или слишком большой расход ресурсов? Правильно ли я понимаю, что timer queue timers несколько более экономные с точки зрения системных ресурсов?

"Что касается исходного вопроса ..." (с)

Пока на ум приходит только одно - написат утилитку, которая будет создавать таймеры до полного исчерпания ресурсов. И смотреть сколько она сможет их создать, насколько будет расходоваться память и т.п.

[Vovka]

Пока на ум приходит только одно - написат утилитку, которая будет создавать таймеры до полного исчерпания ресурсов. И смотреть сколько она сможет их создать, насколько будет расходоваться память и т.п.

Это я уже писал.
Waitable timers - больше 600 000 штук, timer queue timers - больше 2 млн.

[Victor]

Sometimes applications need to perform certain tasks at certain times. Windows offers a waitable timer kernel object that makes it easy to get a time-based notification. Many programmers create a waitable timer object for each time-based task that the application will perform, but this is unnecessary and wastes system resources. Instead, you can create a single waitable timer, set it to the next due time, and then reset the timer for the next time, and so on. However, the code to accomplish this is tricky to write. Fortunately, you can let the new thread pool functions manage this for you.

Jeffrey Richter: Programming Applications for MS Windows

[Vovka]

Sometimes applications need to perform certain tasks at certain times. Windows offers a waitable timer kernel object that makes it easy to get a time-based notification. Many programmers create a waitable timer object for each time-based task that the application will perform, but this is unnecessary and wastes system resources. Instead, you can create a single waitable timer, set it to the next due time, and then reset the timer for the next time, and so on. However, the code to accomplish this is tricky to write. Fortunately, you can let the new thread pool functions manage this for you.

Jeffrey Richter: Programming Applications for MS Windows

Да, тоже хорошая идея.
Только вот я думаю, для этого нужно завести достаточно навороченную структуру данных (по-моему, приоритетную очередь с возможностью изменения приоритета, или уделения элемемента с произвольного места). И при большом кол-ве сессий операции над очередью будут не такими быстыми, как хотелось бы. Плюс необходимость эксклюзивного доступа к этой очереди, а значит - бОльшая вероятность блокировок.