Använda timerobjekt

Följande bild illustrerar användningen av en meddelandetimer för att konfigurera ett tidsgränsintervall för en åtgärd och sedan vänta medan andra drivrutinsrutiner bearbetar en I/O-begäran.

Som föregående bild visar måste en drivrutin tillhandahålla lagring för det tidsinställda objektet, som måste initieras av ett anrop till KeInitializeTimer med en pekare till lagringen. En drivrutin gör vanligtvis detta anrop från sin AddDevice-rutin.

Inom ramen för en viss tråd, till exempel en tråd som skapats av en drivrutin eller en tråd som begär en synkron I/O-åtgärd, kan drivrutinen vänta på sitt tidsinställda objekt enligt föregående bild:

1. Tråden anropar KeSetTimer med en pekare till det tidsinställda objektet och ett givet DueTime-värde uttryckt i enheter med 100 nanosekunder. Ett positivt värde för DueTime anger en absolut tidpunkt då det tidsinställda objektet ska tas bort från kernelns timerkö och anges till tillståndet Signaled. Ett negativt värde för DueTime anger ett intervall i förhållande till den aktuella systemtiden.

   Observera att tråden (eller drivrutinen som körs i en systemtråd) skickar en NULL-pekare för DPC-objektet (visas tidigare i bilden som illustrerar användning av timer- och DPC-objekt för en CustomTimerDpc-rutin) när den anropar KeSetTimer om den väntar på timerobjektet i stället för att köa en CustomTimerDpc-rutin .

2. Tråden anropar KeWaitForSingleObject med en pekare till det tidsinställda objektet, vilket placerar tråden i väntetillstånd medan det tidsinställda objektet finns i kernelns timerkö.

3. Den angivna DueTime upphör att gälla.

4. Kärnan tar bort timerobjektet från kön, sätter det till 'Signalerat' tillstånd och ändrar trådens tillstånd från väntande till redo.

5. Kärnan skickar tråden för körning så snart en processor är tillgänglig: det vill säga att ingen annan tråd med högre prioritet för närvarande är i redo-tillstånd och det inte finns några kärn-lägesrutiner som ska köras på en högre IRQL.

Drivrutinsrutiner som körs på IRQL >= DISPATCH_LEVEL kan tidsbegränsa förfrågningar genom att använda ett timerobjekt med ett associerat DPC-objekt för att köa en drivrutinslevererad CustomTimerDpc-rutin. Endast drivrutinsrutiner som körs inom en icke-linjär trådkontext kan vänta på ett icke-nollintervall på ett tidsinställt objekt, enligt föregående bild.

Precis som alla andra trådar representeras en drivrutinsskapad tråd av ett kerneltrådsobjekt, som också är ett dispatcher-objekt. Därför behöver en drivrutin inte ha sin drivrutinsskapade tråd som använder ett tidsinställt objekt för att frivilligt försätta sig i väntetillstånd för ett visst intervall. I stället kan tråden anropa KeDelayExecutionThread med ett intervall från anroparen. För mer information om denna teknik, se Enhetspollning.

Rutinerna DriverEntry, Reinitialize och Unload körs också i en systemtrådskontext, så drivrutiner kan anropa KeWaitForSingleObject med ett drivrutinsinitierat timerobjekt eller KeDelayExecutionThread medan de initierar eller avlastar. En enhetsdrivrutin kan anropa KeStallExecutionProcessor under ett mycket kort intervall (helst något mindre än 50 mikrosekunder) om den måste vänta tills enheten uppdaterar tillståndet under initieringen.

Drivrutiner på högre nivå använder dock vanligtvis en annan synkroniseringsmekanism i sina DriverEntry - och Reinitialize-rutiner i stället för att använda ett tidsinställt objekt. Drivrutiner på högre nivå bör alltid utformas för att lägga sig över alla drivrutiner på lägre nivå av en viss typ eller typ av enhet. Därför tenderar en drivrutin på högre nivå att bli långsam att läsa in om den väntar på ett tidsinställt objekt eller anropar KeDelayExecutionThread eftersom en sådan drivrutin måste vänta tillräckligt länge för att rymma den långsammaste möjliga enheten som stöder det. Observera också att ett "säkert" men minsta intervall för en sådan väntan är mycket svårt att avgöra.

På samma sätt bör PnP-drivrutiner inte vänta på att andra åtgärder ska utföras, utan i stället använda PnP-chefens meddelandemekanism .