Сценарий 2: вызов функций через определенные интервалы времени
Иногда какие-то операции приходится выполнять чсрсз определенные промежутки времени. В Windows имеется объект ядра "ожидаемый таймер", который позволяет легко получатьуведомления по истечении заданного времени. Многие программис ты создают такой объект для каждой привязанной к определенному времени задаче, но это ошибочный путь, ведущий к пустой трате системных ресурсов. Вместо этого
Вы можете создать единственный ожидаемый таймер и каждый раз перенастраивать его на другое время ожидания. Однако такой код весьма непрост. К счастью, теперь эту работу можно поручить новым функциям пула потоков.
Чтобы какой-то рабочий элемент выполнялся через определенные интервалы времени, первым делом создайте очередь таймеров, вызвав функцию:
HANDLE CreateTimerQueue();
Очередь таймеров обеспечивает организацию набора таймеров. Представьте, что один исполняемый файл предоставляет несколько сервисов. Каждый сервис может потребовать создания таймеров, скажем, для определения того, какой клиент перестал отвечать, для сбора и обновления некоей статистической информации по расписа нию и т. д, Выделять каждому сервису ожидаемый таймер и отдельный поток крайне неэффективно. Вместо этого у каждого сервиса должна быть своя очередь таймеров (занимающая минимум системных ресурсов), а поток компонента поддержки тайме ра и объект ядра "ожидаемый таймер" должны разделяться всеми сервисами. По окон чании работы сервиса его очередь вместе со всеми созданными в ней таймерами просто удаляется.
Вы можете создавать таймеры в очереди, вызывая функцию:
ROOL CreateTimerQueueTimer( PHANDLE phNewTimer, HANDLE hTimerQueue, WAITORTIMERCALLBACK pfnCallback, PVOID pvContext, DWORD dwOueTime, DWORD dwPeriod, ULONG dwFlags);
Во втором параметре Вы передаете описатель очереди, в которую нужно помес тить новый таймер. Если таймеров немного, в зтом параметре можно передать NULL и вообще не вызывать CreateTimerQueue, Такое значение параметра заставит функцию CreateTimerQueueTimer использовать очередь по умолчанию и упростит программи рование.
Параметры pfnCallback и pvContext указывают на Вашу функцию обратного вызова и данные, передаваемые сй в момент срабатывания таймера. Параметр dwDue Time задает время первого срабатывания, a dwPeriod — время последующих срабаты ваний. (Передача в dwDueTime нулевого значения заставляет систему вызвать Вашу функцию по возможности немедленно, что делает функцию CreateTimerQueueTimer похожей на QueueUserWorkItem,) Если dwPeriod равен 0, таймер сработает лишь раз, и рабочий элемент будет помещен в очередь только единожды. Описатель нового тай мера возвращается в пареметре phNewTimer.
Прототип Вашей функции обратного вызова должен выглядеть так:
VOID WINAPI WaitOrTimerCallback( PVOTD pvContext, BOOL fTimerOrWaitFired);
Когда она вызывается, параметр fTimerOrWaitFired всегда принимает значение TRUE, сообщая тем самым, что таймер сработал.
Теперь поговорим о параметре dwFlags функции CreateTimerQueueTimer. Он сооб щает функции, как обрабатывать рабочий элемент, помещаемый в очередь. Вы може те указать флаг WT_EXECUTEDEFAULT, если хотите, чтобы рабочий элемент был об работан одним из потоков пула, контролируемых компонентом поддержки других операций, WT_EXECUTEINIOTHREAD — если в определенный момент нужно выдать
асинхронный запрос на ввод-вывод, или WT_EXECUTEINPERSISTENTTHREAD — если элементом должен заняться один из постоянных потоков. Для рабочего элемента, требующего длительного времени обработки, следует задать флаг WT_EXECUTELONG FUNCTION
Вы можете пользоваться еще одним флагом, WT_EXECUTEINTIMERTHREAD, кото рый нуждается в более подробном объяснении. Как видно из таблицы 11-1, пул пото ков включает компонент поддержки таймера Этот компонент создает единственный объект ядра "ожидаемый таймер", управляя временем его срабатывания, и всегда со стоит из одного потока Вызывая CreateTimerQueueTimer, Вы заставляете его пробу диться, добавить Ваш таймер в очередь и перенастроить объект ядра "ожидаемый таймер". После этого поток компонента поддержки таймера переходит в режим "тре вожного" ожидания АРС-вызова от таймера.
Обнаружив АРС-вызов в своей очереди, поток пробуждается, обновляет очередь таймеров, перенастраивает объект ядра "ожи даемый таймер", а зачем решает, что делать с рабочим элеменюм, который теперь следует обработать.
Далее поток проверяет наличие следующих флагов: WT_EXУCUTEDEFAULT, WT_EXE CUTEINTOTHREAD, WT_EXECUTEINPERSISTENTTHREAD, WT_EXECUTELONGFUNCTION и WT_EXECUTEINTIMERTHREAD И сейчас Вы, наверное, поняли, что делает флаг WT_EXECUTEINTIMERTHREAD: он заставляет поток компонента поддержки таймера обработать рабочий элемент. Хотя такой механизм обработки элемента более эффек тивен, он очень опасен! Пока выполняется функция рабочего элемента, поток ком понента поддержки таймера ничем другим заниматься не может Ожидаемый таймер будет по-прежнему ставить АРС-вызовы в соответствующую очередь потока, но эти рабочие элементы не удастся обработать до завершения текущей функции. Так что, поток компонента поддержки танмера годится для выполнения лишь "быстрого" кода, не блокирующего этот ресурс надолго.
Флаги WT_EXECUTEINIOTHREAD, WT_EXECUTEINPERSISTENTTHREAD и WT_EXE CUTEINTIMERTHREAD являются взаимоисключающими. Если Вы не перелаете ни один из этих флагов (или используете WT_EXECUTEDEFAULT), рабочий элемент помеща ется в очередь одною из потоков в компоненте поддержки других операций (не свя занныхс вводом-выводом), Kpоме того, WT_EXECUTELONGFUNCTION игнорируется, если задан флаг WT_EXECUTEINTIMERTHREAD.
Ненужный таймер удаляется с помощью функции.
BOOL DeleteTimerQueueTimer( HANDLE hTimerQueue, HANDLE hTimer, HANDLE hCompletionEvent);
Вы должны вызывать ее даже для "одноразовых" таймеров, если они уже сработа ли Параметр hTimerQueue указывает очередь, в которой находится таймер, a hTimer — удаляемый таймер, последний описатель возвращается CreateTtmetQuetteTtmer при создании таймера
Последний параметр, hCompletionEvent, определяет, каким образом Вас следует уведомлять об отсутствии необработанных рабочих элементов, поставленных в оче редь этим таймером.
Если в нем передать INVALID_HANDLE_VALUE, функция Delete TimerQueueTimer вернет управление только после обработки всех поставленных в очередь элементов. Задумайтесь, что это значит: удалив таймер в процессе обработ ки запущенного им рабочего элемента, Вы создаете тупиковую ситуацию, так? Вы ждете окончания его обработки и сами жс прерываете ее! Вот почему ноток может
удалить таймер, только если это не он обрабатывает рабочий элемент, поставленный в очередь данным таймером.
Кроме того, используя поток компонента поддержки таймера, никогда не удаляй те какой-либо из таймеров во избежание взаимной блокировки. Попытка удалить таймер приводит к тому, что в очередь этого потока помещается АРС-уведомление. Но если поток ждет удаления таймера, то сам удалить его он уже не в состоянии — вот и тупик.
Вместо значения INVALID_HANDLE_VALUE в параметре hCompletionEvent можни передать NULL. Это подскажет функции, что таймер следует удалить — и чем раньше, тем лучше. В таком случае DeleteTimerQueueTimer немедленно вернет управление, но Вы не узнаете, когда будут обработаны все элементы, поставленные в очередь этим таймером. И, наконец, в параметре hCompletionEvent можно передать описатель объек та ядра "событие". Тогда DeleteTimerQueueTimer немедленно вернет управление, а по ток компонента поддержки таймера освободит событие, как только будут обработа ны все элементы из очереди, Но прежде чем вызывать DeleteTimerQueueTimer, Вы дол жны позаботиться о том, чтобы это событие находилось в занятом состоянии, иначе Ваша программа ошибочно решит, что всс элементы уже обработаны.
Вы можете изменять время первого и последующих срабатываний существующе го таймера, используя функцию:
BOOL ChangeTimerQueueTimer( HANDLF hTimerQueue, HANDLE hTimer, ULONG dwDueTime, ULONG dwPeriod);
Ей передаются описатели очереди и самого таймера, который надо перенастро ить, а также параметры dwDueTime и dwPeriod (время срабатывания и периодичность). Учтите: эта функция нс влияет на уже сработавший "одноразовый" таймер.
Вы може те применять ее совершенно свободно, без всяких опасений насчет тупиковых ситу аций.
Для удаления очереди таймеров предназначена функция:
BOOL DeleteTimerQueueEx( HANDLE hTimerQueue, HANDLE hCompletionEvent);
Она принимает описатель существующей очереди и удаляет все таймеры в ней, избавляя от необходимости вызова DeleteTimerQueueTimer для каждого таймера по отдельности. Параметр hCompletionEvent идентичен такому же параметру функции DeleteTimerQueueTimer, а это значит, что, как и в предыдущем случае, Вы должны по мнить о возможности тупиковых ситуаций, — будьте осторожны.
Прежде чем рассматривать следующий вариант, позвольте обратить Ваше внима ние на несколько нюансов. Компонент поддержки таймера создает объект ядра "ожи даемый таймер", и тот посылает АРС-вызовы в очередь, а не переходит в свободное состояние. Иначе говоря, операционная система постоянно ставит АРС-вызовы в оче редь, и события таймера никогда не теряются. Такой механизм гарантирует, что на писанная Вами функция обратного вызова будет срабатывать с заданной периодич ностью. Только имейте в виду, что все это происходит с использованием множества потоков, а значит, какие-то части этой функции, видимо, потребуют синхронизации.
Если Вас это не устраивает и Вы хотите, чтобы новый вызов помещался в очередь, скажем, через 10 секунд после завершения обработки предыдущего, создавайте в кон це функции рабочего элемента однократно срабатывающие таймеры. Или единствен
ный таймер, ни с длительным временем ожидания, а в конце все той же функции вызывайте ChangeTimerQueueTimer для псренастройкитаймера
