Synkroniseringsexempel

Följande exempel illustrerar vad en minidrivrutin behöver göra när det gäller synkronisering och innehåller exempel på när synkronisering inte ska användas:

• Exempel ett: Minidriver med en fungerande ISR

  Om strömklass-synkronisering är aktiverad anropas alla inträdespunkter för minidrivrutinen på en förhöjd IRQL-nivå med KeSynchronizeExecution, vilket innebär att IRQ-nivån för adaptern och alla lägre IRQ-nivåer maskeras när minidrivrutinen kör sin kod. Därför är det absolut nödvändigt att minidrivrutinen endast utför ett begränsat arbete i det här läget.

  Minidrivrutinen ska inte köra kod som vanligtvis tar mer än 10 till 20 mikrosekunder vid förhöjd IRQL. Om du använder felsökningsversionen av stream.sysloggar strömklassen den tid som spenderas vid upphöjd IRQL och anger om drivrutinen tillbringar för mycket tid där. Om minidrivern helt enkelt behöver programmera DMA-maskinvaruregistren för en begäran, eller bara behöver läsa portar i sin ISR, är det vanligtvis acceptabelt att utföra all sin bearbetning vid höjd IRQL.

  Om minidrivern behöver utföra bearbetning som tar mer än några mikrosekunder, till exempel en minidriver som överför data via PIO, bör minidrivern använda StreamClassCallAtNewPriority för att schemalägga ett DISPATCH_LEVEL-anrop. I återanropet kan minidrivrutinen ta upp till 1/2 till 1 millisekund för att utföra bearbetningen. En sak att komma ihåg när man befinner sig i det här läget är att DISPATCH_LEVEL-återanrop inte synkroniseras med ISR.

  Den här bristen på synkronisering är inte ett problem om maskinvaran förblir stabil när minidrivern kommer åt resurser (till exempel portar eller en kö) vid återanropet och i ISR. Men om instabilitet kan vara ett problem måste minidrivrutinen använda StreamClassCallAtNewPriority för att schemalägga ett återanrop med hög prioritet, där DISPATCH_LEVEL-återanropet berör gemensamma resurser med de resurser som används av ISR.

  Observera att ett återanrop med hög prioritet motsvarar anropet KeSynchronizeExecution. KeSynchronizeExecution kräver att minidrivern refererar till flera parametrar som StreamClassCallAtNewPriority inte gör, men i allmänhet resulterar de båda i samma beteende.

  Om minidrivern ibland bara behöver köra kod som tar mer än 1/2 till 1 millisekund eller ibland behöver anropa tjänster på PASSIVE_LEVEL (till exempel vid initiering) kan inställningen StreamClassCallAtNewPriority sättas till LÅG prioritet för att hämta en PASSIVE_LEVEL tråd. Observera att en återkallning med låg prioritet inte synkroniseras med något och att minidrivrutinen kan ta emot nya begäranden (förutsatt att parametern ReadyForNextRequest NotificationType väntar) eller ett ISR-anrop när man utför en återkallning med låg prioritet.

• Exempel två: Minidrivrutin utan ISR

  Om streamklassynkronisering är aktiverad anropas alla minidrivrutinens startpunkter på DISPATCH_LEVEL. Minidrivern kan utföra bearbetning i upp till cirka 1/2 till 1 millisekund utan behov av att justera prioriteten. Om minidrivrutinen bara ibland behöver köra kod som tar mer än 1/2 millisekund eller ibland behöver anropa tjänster vid PASSIVE_LEVEL (till exempel vid initiering) kan StreamClassCallAtNewPriority med låg prioritet användas för att skaffa en arbetstråd vid PASSIVE_LEVEL. Observera att en callback med låg prioritet inte synkroniseras med något och att minidrivrutinen kan ta emot nya begäranden (förutsatt att parametern ReadyForNextRequest NotificationType väntar) när ett callback med låg prioritet körs.

• När Stream-klasssynkroniseringinteska användas

  Följande är exempel på situationer där synkronisering av strömklass inte ska användas. Dessa inkluderar:

  • När drivrutiner ofta (mer än cirka 20 procent av de begäranden som minidrivrutinen tar emot) behöver utföra bearbetning som tar mer än 1 millisekund, eller ofta behöver anropa tjänster på PASSIVE_LEVEL, till exempel Microsoft DirectDraw-tjänster. När du använder felsökningsversionen av stream.syskommer stream-klassen att kontrollera båda dessa fall och stoppa om de identifieras med synkronisering aktiverad.

  • När minidrivrutinen är ett filter utan associerad hårdvara. En sådan minidriver bör köras på PASSIVE_LEVEL eftersom ingen underliggande maskinvara behöver synkroniseras och minidrivern utför vanligtvis mycket bearbetning. Det är enklare att göra en egen synkronisering i det här fallet än att slösa på omkostnader med hjälp av strömklasssynkronisering. Om det behövs kan du använda mutexes för att skydda dina köer.

    Buggar i synkroniseringskod kan ofta vara svåra att hitta, och i vissa miljöer (till exempel NT-baserade operativsystem som körs på system med flera processorer) kan buggar visas först efter många timmars stress. Baserat på erfarenhet av leverantörer är detta inte den typ av saker som de flesta leverantörer har möjlighet eller önskan att felsöka. Endast drivrutinsskrivare som är bekanta med att skriva helt asynkrona WDM-enhetsdrivrutiner bör försöka utföra sin egen synkronisering.

  • När minidrivrutinen är en buss-på-buss-drivrutin (till exempel en USB- eller 1394-kringutrustningsdrivrutin) som egentligen inte behöver oroa sig för synkronisering av den faktiska maskinvaran, utan bara anropar begäranden till nästa lager vid PASSIVE_LEVEL och tar emot återkopplingar vanligtvis på DISPATCH_LEVEL.