Performance: Die Basis im System

Dieser auch als Lock contention bezeichnete Zustand, also der Wettbewerb oder Streit um die Sperren, ist einer der Gründe dafür, dass bei einem Zwei-Prozessor-System eben nicht 200% der Performance eines Ein-Prozessor-Systems erreichbar ist und bei einem Acht-Prozessor-System nicht annähernd die achtfache Performance zu schaffen ist. Die Problematik der Lock Contention wächst überproportional zur Anzahl der Prozessoren. Daher ist eine Optimierung in diesem Bereich unerlässlich. Dafür gibt es zwei Ansätze:

  • Man kann versuchen, die Anzahl der auftretenden Lock-Situationen zu reduzieren.

  • Man kann optimierte Locking-Verfahren nutzen, um den Aufwand für das Handling von Locks zu reduzieren.

Microsoft hat beim Windows Server 2003 analysiert, in welchen Situationen es häufiger zu Locks auf Systemebene kommt. Diese Situationen hat man zu reduzieren versucht, indem man sie entweder gänzlich vermeidet, die Anzahl der Situationen für solche Locks reduziert oder zumindest den Code optimiert, für dessen Ausführung die Sperre benötigt wird.

Zusätzlich hat Microsoft auch an verschiedenen alternativen Verfahren gearbeitet. Eines sind die Queued Spinlocks, also die Kombination von Warteschlangen für Locks. Diese wurden bereits für einige wenige Locks mit Windows 2000 eingeführt. Beim Windows Server 2003 gibt es nun weitere Lock-Situationen, in denen mit solchen Warteschlangen gearbeitet wird. Der wesentliche Unterschied liegt darin, dass die Prozessoren, die auf den gesperrten Speicherbereich zugreifen müssen, nun nicht mehr ständig prüfen müssen, ob dieser wieder frei ist, sondern dass alle Anforderungen in eine Warteschlange geschrieben werden, die anschließend der Reihe nach abgearbeitet wird (Bild 2).

Bild 2: Die Arbeitsweise bei Queued Spinlocks.
Bild 2: Die Arbeitsweise bei Queued Spinlocks.

Dieses Konzept hat deutliche Vorteile, da es einerseits zu weniger Prüfungen für den Status des Locks und damit einer Entlastung des Gesamtsystems führt und außerdem der Wettlauf zwischen verschiedenen wartenden Prozessoren entfällt. Falls mehrere Prozessoren warten, gibt es bei normalen Locks solche Konstellationen.

Bisher standen solche Queued Spinlocks allerdings nur für die Microsoft-Entwickler zur Verfügung, die direkt am Kernel gearbeitet haben. Ab dem Windows Server 2003 kann eine spezielle Variante davon, die In-Stack Queued Spinlocks, auch von anderen Entwicklern von Kernel-Code verwendet werden. Das ist hilfreich, wenn mehrere Threads, die auch auf unterschiedlichen Prozessoren laufen können, synchronisiert werden müssen.

Teilweise werden beim Windows Server 2003 für Intel-Prozessoren aber auch Interlocked Operations genutzt. Dabei handelt es sich um spezielle Prozessor-Instruktionen, mit denen Aktualisierungen im Speicher vorgenommen werden können. In diesem Fall übernimmt der Prozessor die Aufgabe, die sonst mit den Spinlocks vom Betriebssystem ausgeführt werden muss. Einige der Kernel-Operationen, für die bisher Spinlocks eingesetzt werden, werden nun auf diese Weise ausgeführt.

Weitere Mechanismen sind Non-Blocking Queues und Pushlocks. Im ersten Fall können Einträge in Warteschlangen im globalen Speicher ohne spezielle Sperren gesetzt werden. Im zweiten Fall können mehrere Prozessoren gemeinsam auf Datenstrukturen zugreifen. Solange sie die Informationen nur lesen, sind keine Sperren erforderlich. Diese müssen nur für den kurzen Zeitraum, in dem Änderungen vorgenommen werden, gesetzt werden. Diese Strukturen werden in einigen Fällen anstelle von Spinlocks genutzt. Auch bei den Pushlocks wird übrigens mit Warteschlangen für die exklusiven Anforderungen der Datenstruktur gearbeitet, die für den ändernden Zugriff erforderlich ist.

Die vielen Varianten, die mit dem Windows Server 2003 eingeführt wurden, machen deutlich, wie komplex die Optimierung des Systems für eine bessere Performance sein kann. Dabei muss man immer berücksichtigen, dass typische Locks nur Bruchteile von Sekunden dauern. Die Masse von Locks, die bei der Verarbeitung auftreten können, führt aber doch zu messbaren Leistungseinbußen, die es zu minimieren gilt.

Gerade bei diesem Thema wird auch klar, warum Microsoft die Anzahl der unterstützten Prozessoren nur langsam steigern kann. Theoretisch könnten zwar mehr oder minder beliebig viele Prozessoren genutzt werden – in der Praxis macht das aber nur Sinn, wenn ein weiterer Prozessor auch zu einem signifikanten Leistungszuwachs führt.