Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wie in der Abbildung zur Verarbeitung von IRPs in geschichteten Treibern dargestellt, ist ein Dateisystem ein zweiteiliger Treiber:
Ein Dateisystemtreiber (File System Driver, FSD), der im Kontext eines Benutzermodusthreads ausgeführt wird, der einen E/A-Systemdienst aufruft
Der E/A-Manager sendet das entsprechende IRP an die FSD. Wenn die FSD eine Abschlussroutine für ein IRP einrichtet, wird ihre Abschlussroutine nicht unbedingt im Kontext des ursprünglichen Benutzermodusthreads aufgerufen.
Eine Reihe von Dateisystemthreads und möglicherweise ein FSP (Dateisystemprozess)
Ein FSD kann eine Reihe von fahrerspezifischen Systemthreads erstellen, aber die meisten FSDs verwenden Systemarbeitsthreads, um Aufgaben zu erledigen, ohne Benutzermodus-Threads zu binden, die E/A-Anforderungen stellen. Jeder FSD kann einen eigenen Prozessadressraum einrichten, in dem seine treiberspezifischen Threads ausgeführt werden, aber die vom System bereitgestellten FSDs vermeiden diese Vorgehensweise, um Systemspeicher zu sparen.
Dateisysteme verwenden in der Regel System-Worker-Threads, um interne Arbeitswarteschlangen von IRPs einzurichten und zu verwalten, die sie an einen oder mehrere Treiber auf tieferer Ebene senden, möglicherweise für verschiedene Geräte.
Während der im Verarbeiten von IRPs in geschichteten Treibern gezeigte Treiber jede IRP in Phasen durch eine Reihe von spezifischen, vom Treiber bereitgestellten Routinen verarbeitet, verwendet er im Gegensatz zum Dateisystem keine Systemthreads. Ein Treiber auf der niedrigsten Ebene benötigt keinen eigenen Threadkontext, es sei denn, das Einrichten seines Geräts für E/A ist ein so langwieriger Prozess, dass er spürbare Auswirkungen auf die Systemleistung hat. Nur wenige untergeordnete oder Zwischentreiber müssen ihre eigenen treiberspezifischen oder gerätededizierten Systemthreads einrichten, und diejenigen, die dies tun, erleiden eine Leistungseinbuße, verursacht durch Kontextwechsel zu ihren Threads.
Die meisten Kernelmodustreiber, wie der physische Gerätetreiber in der Verarbeitung von IRPs in geschichteten Treibern, werden in einem beliebigen Thread-Kontext ausgeführt: in demjenigen, der gerade aktuell ist, wenn sie aufgerufen werden, um ein IRP zu verarbeiten. Daher behalten Treiber in der Regel den Zustand zu ihren E/A-Vorgängen und den Geräten, die sie warten, in einem vom Treiber definierten Teil ihrer Geräteobjekte, der als Geräteerweiterung bezeichnet wird.