контрольный счетчик для таких элементов: его значение должно увеличиваться перед вызовом QueueUserWorkItem и уменьшаться после выполнения функции рабо чего элемента. Выгрузка DLL допустима только после того, как этот счетчик обиулится.

Сценарий 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.

Прототип Вашей функции обратного вызова должен выглядеть так:

Вы должны вызывать ее даже для «одноразовых» таймеров, если они уже сработа ли Параметр 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, а это значит, что, как и в предыдущем случае, Вы должны по мнить о возможности тупиковых ситуаций, — будьте осторожны.