Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
När en drivrutin håller ett spinlock kan det inte orsaka ett maskinvarufel eller utlösa ett programvarufel utan att krascha systemet. Med andra ord får en drivrutins ISR och alla SynchCritSection-rutiner som drivrutinen levererar i ett anrop till KeSynchronizeExecution inte orsaka ett fel eller en trap, till exempel ett sidfel eller ett aritmetiskt undantag, och kan inte generera ett programvaruundantag. En rutin som anropar KeAcquireSpinLock eller KeAcquireInStackQueuedSpinLock kan inte heller orsaka ett maskinvarufel eller skapa ett programvarufel förrän det har släppt sitt executive spin lock och inte längre körs på IRQL = DISPATCH_LEVEL.
Sidindelade data och stödjande rutiner
När man håller ett spinnlås får drivrutinerna inte anropa rutiner som har åtkomst till sida-indelade data. Kom ihåg att drivrutiner kan anropa vissa supportrutiner som får åtkomst till växlingsbara data om och endast om deras anrop sker när de körs på en IRQL som är strikt lägre än DISPATCH_LEVEL. Den här IRQL-begränsningen förhindrar att dessa supportrutiner anropas medan du håller i ett spinnlås. Mer information om IRQL-krav för specifika supportrutiner finns på rutinens referenssida.
Rekursion
Att försöka förvärva ett spinnlås rekursivt är garanterat att orsaka ett dödläge: instansieringen av en rekursiv rutin kan inte frigöra spinnlåset medan en andra instansiering snurrar och försöker förvärva samma spinnlås.
Följande riktlinjer beskriver hur du använder spinnlås med rekursiva rutiner:
Den rekursiva rutinen får inte anropa sig själv när du håller i ett spinnlås, eller får inte försöka skaffa samma spinnlås vid efterföljande anrop.
Medan den rekursiva rutinen har ett spinnlås, får en annan drivrutin inte anropa rekursiv rutinen om rekursion kan orsaka ett dödläge eller kan orsaka att anroparen håller spinnlåset längre än 25 mikrosekunder.
Mer information om rekursiva drivrutinsrutiner finns i Använda Kernel Stack.
Kapslade spinlås-åtkomst
Försök att skaffa ett andra spinnlås samtidigt som du håller i ett annat spinnlås kan också orsaka dödlägen eller dålig drivrutinsprestanda.
Följande riktlinjer beskriver hur förare ska hålla i spinnlås:
Drivrutinen får inte anropa en supportrutin som använder ett spinnlås om inte ett dödläge inte kan inträffa.
Även om ett dödläge inte kan uppstå bör drivrutinen inte anropa en supportrutin som använder ett spinnlås om inte alternativa kodningstekniker inte kan ge jämförbara drivrutinsprestanda och funktioner.
Om en drivrutin gör kapslade anrop för att förvärva spinnlås måste den alltid förvärva spinnlåsen i samma ordning varje gång. Den här ordningen hjälper till att undvika dödlägen.
I allmänhet bör du undvika att använda kapslade spinnlås för att skydda överlappande delmängder eller diskreta uppsättningar med delade data och resurser. Tänk på vad som kan hända om en drivrutin använder två executive spin-lås för att skydda diskreta resurser, till exempel ett par tidsinställda objekt som kan anges individuellt och kollektivt av olika drivrutinsrutiner. Drivrutinen skulle tillfälligt blockeras i en SMP-dator när någon av två rutiner, som var och en höll ett spinnlås, försökte få tag på det andra spinnlåset.
För mer information om användning av kapslade spinnlås, se Lås, Dödlägen och Synkronisering.