Arbeitswarteschlangen-Verteilermechanismen
RDBSS verwendet Windows-Kernelarbeitswarteschlangen, um Vorgänge auf mehreren Threads für die spätere Ausführung zu verteilen. Netzwerk-Miniumleitungstreiber können die Arbeitswarteschlangen verwenden, die von RDBSS für den Versand von Vorgängen für spätere Ausführung Standard enthalten sind.
RDBSS stellt mehrere Routinen bereit, die den in RDBSS verwendeten Verteilermechanismus implementieren. Diese Routinen können auch von Netzwerk-Miniumleitungstreibern verwendet werden.
RDBSS verfolgt die Arbeitsaufgaben auf Geräteobjektbasis. Dadurch kann RDBSS die Rennbedingungen verarbeiten, die mit dem Laden und Entladen von Netzwerk-Miniumleitungen verbunden sind. Dies bietet auch einen Mechanismus in RDBSS, mit dem verhindert wird, dass ein einzelner Netzwerk-Miniumleitungsmodul unfair alle Ressourcen verwendet.
Es gibt bestimmte Szenarien, in denen die Versendung von Arbeitsaufgaben unvermeidlich ist. Um häufige Speicherzuweisungen zu vermeiden und Vorgänge in diesen Szenarien freizugeben, wird die WORK_QUEUE_ITEM als Teil einer anderen Daten zugeordnet. In anderen Szenarien, in denen die Verteilung selten ist, zahlt es sich aus, die Speicherzuweisung zu vermeiden, bis sie erforderlich ist. Die IMPLEMENTIERUNG der RDBSS-Arbeitswarteschlange bietet beide Szenarien in Form von Verteiler- und Arbeitswarteschlangenanforderungen. Bei der Versendung mithilfe der RxDispatchToWorkerThread-Routine muss vom Aufrufer kein Speicher für die WORK_QUEUE_ITEM zugewiesen werden. Für die Veröffentlichung mithilfe der RxPostToWorkerThread-Routine muss der Speicher für die WORK_QUEUE_ITEM vom Aufrufer zugewiesen werden.
Es gibt zwei häufige Fälle des Verteilens von Vorgängen an Arbeitsthreads:
Verwenden Sie für einen sehr seltenen Vorgang die RxDispatchToWorkerThread-Routine , um Arbeitsspeicher zu sparen, indem Sie speicheraktivieren und arbeitsspeicherfrei für das Arbeitswarteschlangenelement freigeben, wenn sie benötigt wird.
Wenn ein Vorgang wiederholt verteilt wird, verwenden Sie die RxPostToWorkerThread-Routine , um Zeit zu sparen, indem Sie die WORK_QUEUE_ITEM im Rahmen der zu verteilenden Datenstruktur im Voraus zuweisen.
Der Kompromiss zwischen den beiden Verteilervorgängen ist Zeit im Vergleich zum Raum (Speichernutzung).
Der Verteilermechanismus in RDBSS bietet mehrere Ebenen von Arbeitswarteschlangen pro Prozessor. Die folgenden Arbeitswarteschlangenebenen werden derzeit unterstützt:
Kritisch
Delayed
HyperCritical
Die Unterscheidung zwischen kritisch und verzögert ist eine prioritätsstufe. Die HyperCritical-Ebene unterscheidet sich von den anderen beiden Ebenen darin, dass die Routinen nicht blockieren sollten (auf eine Ressource warten). Diese Anforderung kann nicht erzwungen werden, sodass die Wirksamkeit des Versandmechanismus auf die implizite Zusammenarbeit der Kunden beruht.
Die Implementierung der Arbeitswarteschlange in RDBSS basiert auf einer KQUEUE-Implementierung. Die zusätzliche Unterstützung umfasst die Regulierung einer Reihe von Threads, die aktiv auf die Arbeitsaufgaben warten. Jede Arbeitswarteschlangendatenstruktur wird aus nicht seitenseitigem Poolspeicher zugeordnet und verfügt über einen eigenen Synchronisierungsmechanismus (ein Spinlock).
Neben Buchführungsinformationen (z. B. Warteschlangenstatus und Typ) Standard rdBSS statistiken, die über die Lebensdauer der Arbeitswarteschlange gesammelt werden. Dies kann wertvolle Informationen zur Optimierung einer Arbeitswarteschlange bereitstellen. Die Anzahl der elemente, die verarbeitet wurden, die Anzahl der Elemente, die verarbeitet werden müssen, und die kumulierte Warteschlangenlänge ist strukturiert. Die kumulierte Warteschlangenlänge ist eine wichtige Metrik und stellt die Summe der Anzahl der Elemente dar, die jedes Mal verarbeitet werden müssen, wenn eine zusätzliche Arbeitsaufgabe in die Warteschlange gestellt wurde. Die kumulierte Warteschlangenlänge dividiert durch die Summe der Gesamtanzahl der verarbeiteten Elemente und die Anzahl der zu verarbeitenden Elemente gibt einen Hinweis auf die durchschnittliche Warteschlangenlänge. Ein Wert, der wesentlich größer als ein Wert ist, bedeutet, dass die Mindestanzahl der Arbeitsthreads, die der Arbeitswarteschlange zugeordnet sind, erhöht werden kann. Ein Wert, der viel kleiner als ein Wert ist, bedeutet, dass die maximale Anzahl von Arbeitsthreads, die der Warteschlange zugeordnet sind, verringert werden kann.
Die Arbeitswarteschlange beginnt in der Regel in einem aktiven Zustand und wird fortgesetzt, bis entweder eine nicht wiederherstellbare Situation aufgetreten ist (z. B. fehlende Systemressourcen), oder wenn sie in den inaktiven Zustand wechselt. Wenn ein Rundown initiiert wird, wechselt er in den Status "rundown-in-progress".
Die Ausführung der Arbeitswarteschlangen ist nicht abgeschlossen, wenn die Threads nach unten gedreht wurden. Die Beendigung der Threads muss sichergestellt werden, bevor die Datenstrukturen heruntergerissen werden können. Die Implementierung der Arbeitswarteschlange in RDBSS folgt einem Protokoll, in dem jeder der spunenden Threads einen Verweis auf das Threadobjekt im Rundown-Kontext speichert. Der rundownausstellende Thread (der nicht zur Arbeitswarteschlange gehört) wartet auf den Abschluss aller Threads, bevor die Datenstrukturen abgerissen werden.
Die aktuelle Implementierung von RxDispatchToWorkerThread - und RxPostToWorkerThread-Warteschlangen funktioniert auf demselben Prozessor, von dem der Anruf stammt.
Die folgenden RDBSS-Routinen für die Arbeitswarteschlangen-Verteilerung sind enthalten.
| Routine | Beschreibung |
|---|---|
Diese Routine ruft eine Routine im Kontext eines Arbeitsthreads auf. Der Speicher für die WORK_QUEUE_ITEM wird von dieser Routine zugewiesen. |
|
Diese Routine ruft die Routine im Kontext eines Arbeitsthreads auf. Der Speicher für die WORK_QUEUE_ITEM muss vom Aufrufer zugewiesen werden. |
|
Diese Routine zerreißt den Dispatcherkontext für einen Netzwerk-Miniumleitungsmodul. Beachten Sie, dass diese Routine nur unter Windows Server 2003 und Windows XP verfügbar ist. |