Używanie procedury CustomTimerDpc

Aby wyłączyć wcześniej ustawiony obiekt czasomierza, sterownik wywołuje moduł KeCancelTimer. Ta rutyna usuwa obiekt czasomierza z kolejki czasomierza systemu. Ogólnie rzecz biorąc, obiekt czasomierza nie jest ustawiony na stan zasygnalizowany, a rutyna CustomTimerDpc nie jest kolejkowana do wykonania. Jeśli jednak czasomierz wkrótce wygaśnie po wywołaniu modułu KeCancelTimer , wygaśnięcie może wystąpić, zanim keCancelTimer będzie mieć możliwość uzyskania dostępu do kolejki czasowej, w tym przypadku wystąpi sygnalizowanie i kolejkowanie DPC.

Ponowne wywołanie KeSetTimer lub KeSetTimerEx z wcześniej określonymi wskaźnikami Timer i Dpc przed wygaśnięciem wcześniej określonego interwału ma następujące skutki:

• Jądro usuwa obiekt timera z kolejki timera bez ustawienia obiektu w stan sygnalizowany ani dodawania do kolejki procedury CustomTimerDpc.

• Jądro ponownie ustawia obiekt czasomierza w kolejce czasomierza przy użyciu nowej wartości DueTime .

Użycie tego samego obiektu czasomierza do różnych celów może spowodować warunki wyścigu lub poważne błędy kierowcy. Załóżmy na przykład, że sterownik określa pojedynczy obiekt czasomierza, aby skonfigurować wywołanie procedury CustomTimerDpc i skonfigurować oczekiwania w wątku dedykowanym sterownika. Za każdym razem, gdy dedykowany wątek sterownika wywołuje KeSetTimer, KeSetTimerEx lub KeCancelTimer dla wspólnego obiektu zegara, wątek anuluje wywołania procedury CustomTimerDpc, jeśli obiekt zegara został już w kolejce do wywołania CustomTimerDpc.

Jeśli sterownik ma procedury CustomTimerDpc i oczekuje na obiekty czasomierza w niearbitralnym kontekście wątku, powinien:

• Nigdy nie używaj obiektu czasomierza wrażliwego na kontekst wątku w kontekście niearbitarycznym ani odwrotnie.

• Przydziel oddzielny obiekt czasomierza dla każdej procedury CustomTimerDpc . Każdy zestaw wątków sterowników lub procedur sterowników, które są wywoływane w kontekście konkretnego wątku, powinien mieć własny zestaw obiektów czasomierza "waitable".

Jeśli używasz procedury CustomTimerDpc, wybierz dokładnie interwał, który sterownik przekazuje w wywołaniach do KeSetTimer lub KeSetTimerEx. Ponadto należy wziąć pod uwagę wszystkie możliwe skutki wywołania funkcji KeCancelTimer z użyciem tego samego obiektu czasomierza z dowolnej procedury sterownika, która dokonuje tego wywołania, szczególnie na platformach SMP.

Należy pamiętać o następujących faktach dotyczących procedur CustomTimerDpc :

Tylko jedno wystąpienie obiektu DPC reprezentującego określoną procedurę DPC może być zakolejkowane do wykonania w dowolnym momencie.

Jeśli druga procedura sterownika wywołuje keSetTimer lub KeSetTimerEx, aby uruchomić tę samą procedurę CustomTimerDpc przed upływem interwału określonego przez pierwszy obiekt wywołujący, procedura CustomTimerDpc jest uruchamiana tylko po upływie interwału określonego przez drugi obiekt wywołujący. W takich okolicznościach customTimerDpc nie wykonuje żadnej pracy, dla której pierwsza rutyna o nazwie KeSetTimer lub KeSetTimerEx.

W przypadku sterowników, które mają procedury CustomTimerDpc i używają okresowych czasomierzy:

Sterownik nie może zwolnić okresowego czasomierza z procedury DPC. Sterowniki mogą cofnąć przydział tylko dla nieokresowych timerów z procedury DPC.

Należy wziąć pod uwagę następujące wytyczne projektowe dla sterowników, które mają procedury CustomDpc i CustomTimerDpc :

Aby zapobiec warunkom wyścigu, nigdy nie przekazuj tego samego wskaźnika Dpc ani do KeSetTimer, ani do KeSetTimerEx oraz KeInsertQueueDpc.

Innymi słowy, załóżmy, że procedura StartIo sterownika wywołuje KeSetTimer lub KeSetTimerEx aby umieścić w kolejce procedurę CustomTimerDpc, a ISR sterownika wywołuje KeInsertQueueDpc jednocześnie z innego procesora z tym samym wskaźnikiem Dpc. Ta rutyna DPC będzie uruchamiana, gdy poziom IRQL na procesorze spadnie poniżej DISPATCH_LEVEL lub gdy upłynie interwał czasomierza, w zależności, co nastąpi wcześniej. Bez względu na to, co nastąpi jako pierwsze, niektóre niezbędne zadania dla StartIo lub ISR mogą zostać po prostu pominięte przez procedurę DPC.

Ponadto DPC używane przez dwie standardowe procedury sterowników o bardzo różnych funkcjach miałyby mniejszą wydajność niż oddzielne procedury CustomTimerDpc i CustomDpc . DPC musiałby określić, które operacje należy wykonać, w zależności od warunków, które spowodowały kolejkę procedury StartIo lub ISR. Testowanie tych warunków w DPC spowoduje użycie dodatkowych cykli procesora CPU.