Använda en CustomTimerDpc-rutin

Om du vill inaktivera ett tidigare angivet tidsinställt objekt anropar en drivrutin KeCancelTimer. Den här rutinen tar bort det tidsinställda objektet från systemets timerkö. Vanligen är det tidsinställda objektet inte inställt på det signalerade tillståndet och CustomTimerDpc-rutinen är inte köad för att köras. Men om timern är på väg att löpa ut när KeCancelTimer anropas kan utlösning inträffa innan KeCancelTimer har en chans att komma åt tidskön, i vilket fall signalerande och DPC-köning kommer att inträffa.

Att återkalla KeSetTimer eller KeSetTimerEx, med tidigare angivna Timer - och Dpc-pekare , innan det tidigare angivna intervallet upphör att gälla, har följande effekter:

• Kerneln tar bort timern från tidtagarkön, utan att sätta objektet i signalerat tillstånd eller köa CustomTimerDpc-rutinen.

• Kerneln sätter tillbaka timerobjektet i timerkön med hjälp av det nya DueTime-värdet.

Om du använder samma timerobjekt för olika ändamål kan det orsaka kapplöpningseffekter eller allvarliga drivrutinsfel. Anta till exempel att en drivrutin anger ett enda timerobjekt både för att konfigurera ett anrop till en CustomTimerDpc-rutin och för att konfigurera väntetider i en drivrutinsspecifik tråd. När den drivrutinsspecifika tråden anropar KeSetTimer, KeSetTimerEx eller KeCancelTimer för det vanliga timerobjektet, skulle tråden avbryta anrop till CustomTimerDpc-rutinen , om det tidsinställda objektet redan stod i kö för ett CustomTimerDpc-anrop .

Om en drivrutin har CustomTimerDpc-rutiner och även väntar på tidsinställda objekt i en icke-linjär trådkontext bör den:

• Använd aldrig ett trådkontextkänsligt tidsinställt objekt i en icke-arbiträr trådkontext eller vice versa.

• Allokera ett separat timerobjekt för varje CustomTimerDpc-rutin . Varje uppsättning drivrutinstrådar eller drivrutinsrutiner som anropas i en icke-linjär trådkontext bör ha en egen uppsättning "väntebara" timerobjekt.

Om du använder en CustomTimerDpc-rutin väljer du noggrant det intervall som drivrutinen skickar i anrop till KeSetTimer eller KeSetTimerEx. Tänk dessutom på alla möjliga effekter av ett anrop till KeCancelTimer med samma timerobjekt från alla drivrutinsrutiner som gör det här anropet, särskilt på SMP-plattformar.

Tänk på följande om CustomTimerDpc-rutiner :

Endast en instansiering av ett DPC-objekt som representerar en viss DPC-rutin kan placeras i kö för körning när som helst.

Om en andra drivrutin anropar KeSetTimer eller KeSetTimerEx för att köra samma CustomTimerDpc-rutin innan intervallet som anges av den första anroparen upphör att gälla, körs CustomTimerDpc-rutinen endast efter att intervallet som anges av den andra anroparen upphör att gälla. Under dessa omständigheter utför CustomTimerDpc inget av det arbete som den första rutinen med namnet KeSetTimer eller KeSetTimerEx för.

För drivrutiner som har CustomTimerDpc-rutiner och använder periodiska timers:

En drivrutin kan inte frigöra en periodisk timer från en DPC-rutin. Drivrutiner kan endast deallokera icke-periodiska timers från en DPC-rutin.

Överväg följande designriktlinjer för drivrutiner som har både CustomDpc - och CustomTimerDpc-rutiner :

För att förhindra tävlingsförhållanden ska du aldrig skicka samma Dpc-pekare till KeSetTimer, KeSetTimerEx eller KeInsertQueueDpc.

Anta med andra ord att en drivrutins StartIo-rutinanropar KeSetTimer eller KeSetTimerEx för att köa en CustomTimerDpc-rutin , och förarens ISR anropar KeInsertQueueDpc samtidigt från en annan processor med samma Dpc-pekare . DPC-rutinen körs när IRQL på en processor understiger DISPATCH_LEVEL eller tidsintervallet upphör att gälla, beroende på vilket som kommer först. Beroende på vilket som kommer först skulle ett viktigt arbete för StartIo eller ISR helt enkelt tas bort av DPC-rutinen.

Dessutom skulle en DPC som används av två standarddrivrutiner med mycket olika funktioner ha sämre prestandaegenskaper än separata CustomTimerDpc - och CustomDpc-rutiner . DPC skulle behöva avgöra vilka åtgärder som ska utföras, beroende på de villkor som orsakade att StartIo-rutinen eller ISR lade den i kö. Testning för dessa villkor i DPC skulle använda ytterligare CPU-cykler.