Freigeben über

Verhindern von Fehlern und Deadlocks während der Verwendung von Spin-Sperren

  • Artikel

Während eine Treiberroutine eine Spin-Sperre enthält, kann sie keine Hardwareausnahme auslösen oder eine Softwareausnahme auslösen, ohne dass das System heruntergefahren wird. Anders ausgedrückt: Die ISR eines Treibers und jede SynchCritSection-Routine , die der Treiber in einem Aufruf von KeSynchronizeExecution bereitstellt, dürfen keinen Fehler oder eine Falle verursachen, z. B. einen Seitenfehler oder eine arithmetische Ausnahme, und können keine Softwareausnahme auslösen. Eine Routine, die KeAcquireSpinLock oder KeAcquireInStackQueuedSpinLock aufruft , kann auch keine Hardwareausnahme auslösen oder eine Softwareausnahme auslösen, bis sie ihre Executive Spin-Sperre freigegeben hat und nicht mehr unter IRQL = DISPATCH_LEVEL ausgeführt wird.

Auslagerungsfähige Daten und Supportroutinen

Während sie eine Drehsperre halten, dürfen Treiber keine Routinen aufrufen, die auf ausgelagerte Daten zugreifen. Denken Sie daran, dass Treiber bestimmte Supportroutinen aufrufen können, die auf ausgelagerte Daten zugreifen, wenn ihre Aufrufe während der Ausführung in einem IRQL streng kleiner als DISPATCH_LEVEL. Diese IRQL-Einschränkung schließt das Aufrufen dieser Supportroutinen aus, während eine Drehsperre gilt. Informationen zu IRQL-Anforderungen für eine bestimmte Supportroutine finden Sie auf der Referenzseite der Routine.

Rekursion

Der Versuch, eine Spinsperre rekursiv zu erhalten, führt garantiert zu einem Deadlock: Die haltende Instanziierung einer rekursiven Routine kann die Spinsperre nicht freigeben, während eine zweite Instanziierung spint und versucht, die gleiche Spinsperre zu erhalten.

In den folgenden Richtlinien wird beschrieben, wie Sie Drehsperren mit rekursiven Routinen verwenden:

  • Die rekursive Routine darf sich nicht selbst aufrufen, während sie eine Drehsperre hält, oder sie darf nicht versuchen, die gleiche Drehsperre bei nachfolgenden Aufrufen zu erhalten.

  • Während die rekursive Routine eine Drehsperre enthält, darf eine andere Treiberroutine die rekursive Routine nicht aufrufen, wenn die Rekursion zu einem Deadlock führen oder dazu führen könnte, dass der Aufrufer die Spinsperre länger als 25 Mikrosekunden hält.

Weitere Informationen zu rekursiven Treiberroutinen finden Sie unter Verwenden des Kernelstapels.

Geschachtelte Spin-Lock-Käufe

Der Versuch, eine zweite Spin-Sperre zu erhalten, während eine andere Drehsperre gedrückt wird, kann auch zu Deadlocks oder einer schlechten Treiberleistung führen.

In den folgenden Richtlinien wird beschrieben, wie Treiber Drehsperren halten sollten:

  • Der Treiber darf keine Supportroutine aufrufen, die eine Drehsperre verwendet, es sei denn, ein Deadlock kann nicht auftreten.

  • Selbst wenn kein Deadlock auftreten kann, sollte der Treiber keine Supportroutine aufrufen, die eine Drehsperre verwendet, es sei denn, alternative Codierungstechniken können keine vergleichbare Treiberleistung und -funktionalität bieten.

  • Wenn ein Treiber geschachtelte Aufrufe zum Abrufen von Drehsperren durchführt, muss er die Drehsperren immer in derselben Reihenfolge abrufen, wenn sie erworben werden. Diese Reihenfolge hilft, Deadlocks zu vermeiden.

Im Allgemeinen sollten Sie die Verwendung geschachtelter Spinsperren vermeiden, um überlappende Teilmengen oder diskrete Gruppen freigegebener Daten und Ressourcen zu schützen. Überlegen Sie, was passieren kann, wenn ein Treiber zwei Exekutiv-Spin-Sperren verwendet, um diskrete Ressourcen zu schützen, z. B. ein Paar von Timerobjekten, die von verschiedenen Treiberroutinen einzeln und gemeinsam festgelegt werden können. Der Treiber hat zeitweilig einen Deadlock in einem SMP-Computer ausgeführt, wenn eine von zwei Routinen, die jeweils eine Drehsperre hielt, versuchte, die andere Spinsperre zu erhalten.

Weitere Informationen zum Abrufen geschachtelter Drehsperren finden Sie unter Sperren, Deadlocks und Synchronisierung.