Mechanismen voor de afhandeling van werkwachtrijen

RDBSS maakt gebruik van Windows-kernelwerkwachtrijen om bewerkingen op meerdere threads te verzenden voor latere uitvoering. Netwerkstuurprogramma's voor mini-omleiding kunnen gebruikmaken van de werkwachtrijen die door RDBSS worden onderhouden voor verzendingsbewerkingen voor latere uitvoering.

RDBSS biedt verschillende routines die het verzendmechanisme implementeren dat wordt gebruikt in RDBSS. Deze routines kunnen ook worden gebruikt door mini-omleidingsstuurprogramma's van het netwerk.

RDBSS houdt de werkitems per apparaat bij. Hierdoor kan RDBSS de racevoorwaarden verwerken die zijn gekoppeld aan het laden en lossen van netwerk mini-redirectors. Dit biedt ook een mechanisme in RDBSS om te voorkomen dat één mini-omleidingsapparaat van het netwerk oneerlijk gebruikmaakt van alle resources.

Er zijn bepaalde scenario's waarin het verzenden van werkitems onvermijdelijk is. Om frequente geheugentoewijzing en het vrijgeven van geheugen in deze scenario's te voorkomen, wordt de WORK_QUEUE_ITEM toegewezen als onderdeel van andere gegevensstructuren. In andere scenario's waarbij verzending zeldzaam is, betaalt het om geheugentoewijzing te voorkomen totdat deze is vereist. De implementatie van de RDBSS-werkwachtrij ondersteunt beide scenario's door werkwachtrijverzoeken zowel te verzenden als te plaatsen. In het geval van verzending met behulp van de RxDispatchToWorkerThread-routine moet er geen geheugen voor de WORK_QUEUE_ITEM worden toegewezen door de beller. Voor het posten met behulp van de RxPostToWorkerThread-routine moet het geheugen voor de WORK_QUEUE_ITEM worden toegewezen door de beller.

Er zijn twee veelvoorkomende gevallen van taakverdeling aan werkthreads:

• Gebruik voor een zeer onregelmatige bewerking de RxDispatchToWorkerThread-routine om geheugengebruik te besparen door geheugen dynamisch toe te wijzen en geheugen vrij te maken voor het werkwachtrijitem wanneer dit nodig is.

• Wanneer een bewerking herhaaldelijk wordt verzonden, gebruikt u de RxPostToWorkerThread-routine om tijd te besparen door vooraf de WORK_QUEUE_ITEM toe te wijzen als onderdeel van de gegevensstructuur die moet worden verzonden.

De afweging tussen de twee verzendbewerkingen is tijd versus ruimte (geheugengebruik).

Het verzendmechanisme in RDBSS biedt meerdere niveaus van werkwachtrijen per processor. De volgende niveaus van werkwachtrijen die momenteel worden ondersteund:

• Kritisch

• Vertraagd

• Hyperkritisch

Het onderscheid tussen Kritiek en Vertraagd is een van de prioriteiten. Het HyperCritical-niveau verschilt van de andere twee omdat de routines niet mogen worden geblokkeerd (wachten op een resource). Deze vereiste kan niet worden afgedwongen, dus de effectiviteit van het verzendmechanisme is afhankelijk van de impliciete samenwerking van de klanten.

De implementatie van de werkwachtrij in RDBSS is gebouwd rond een KQUEUE-implementatie. De aanvullende ondersteuning omvat de regelering van een aantal draadjes die actief op de werkitems wachten. Elke werkwachtrijgegevensstructuur wordt toegewezen vanuit het geheugen van een niet-gepagineerde pool en heeft een eigen synchronisatiemechanisme (een spinlock).

Naast boekhoudingsinformatie (wachtrijstatus en -type, bijvoorbeeld), onderhoudt RDBSS ook statistieken die worden verzameld over de levensduur van de werkwachtrij. Dit kan waardevolle informatie bieden bij het afstemmen van een werkwachtrij. Het aantal items dat is verwerkt, het aantal items dat moet worden verwerkt en de cumulatieve wachtrijlengte is gestructureerd. De cumulatieve wachtrijlengte is een belangrijke metriek en vertegenwoordigt de som van het aantal items dat moet worden verwerkt telkens wanneer een extra werkitem in de wachtrij is geplaatst. De cumulatieve wachtrijlengte gedeeld door de som van het totale aantal verwerkte items en het aantal te verwerken items geeft een indicatie van de gemiddelde wachtrijlengte. Een waarde die veel groter is dan één geeft aan dat het minimum aantal werkthreads dat aan de werkwachtrij is gekoppeld, kan worden verhoogd. Een waarde die veel kleiner is dan één geeft aan dat het maximum aantal werkthreads dat aan de wachtrij is gekoppeld, kan worden verlaagd.

De werkwachtrij begint meestal in een actieve status en gaat door totdat er een niet-herstelbare situatie is opgetreden (bijvoorbeeld gebrek aan systeembronnen) of wanneer deze overgaat naar de inactieve status. Wanneer een rundown wordt gestart, gaat deze over naar de status rundown-in-progress.

Het overzicht van werkwachtrijen is niet voltooid wanneer de threads zijn afgeschaald. De beëindiging van de threads moet worden gegarandeerd voordat de gegevensstructuren kunnen worden uitgesplitst. De implementatie van de werkwachtrij in RDBSS volgt een protocol waarin elk van de threads die worden uitgesplitst een verwijzing naar het threadobject opslaat in de rundown-context. De rundown-uitgiftethread (die niet tot de werkwachtrij behoort) wacht totdat alle threads zijn uitgesponnen voordat de gegevensstructuren worden uitgesplitst.

De huidige implementatie van RxDispatchToWorkerThread en RxPostToWorkerThread-wachtrijen werken op dezelfde processor waarvan de aanroep afkomstig is.

De volgende RDBSS-routines voor het verzenden van werkwachtrijen zijn onder andere.

Routine	Beschrijving
RxDispatchToWorkerThread	Deze routine roept een routine aan in de context van een werkrolthread. Het geheugen voor de WORK_QUEUE_ITEM wordt toegewezen door deze routine.
RxPostToWorkerThread	Deze routine roept de routine aan in de context van een werkrolthread. Geheugen voor de WORK_QUEUE_ITEM moet worden toegewezen door de beller.
RxSpinDownMRxDispatcher	Deze routine scheurt de dispatchercontext voor een netwerk mini-redirector. Houd er rekening mee dat deze routine alleen beschikbaar is op Windows Server 2003 en Windows XP.