Freigeben über

  • Artikel

[Newsletter-Archiv ^] [< Band 1, Nummer 1] [Band 1, Nummer 3 >]

Der Systems Internals Newsletter Band 1, Nummer 2

http://www.sysinternals.com

15. Mai 1999 – In dieser Ausgabe:

  1. NEUERUNGEN BEI SYSTEM INTERNALS

    • SDelete
    • BlueScreen-Bildschirmschoner Win2K-Update
    • „Linux und das Unternehmen“
    • „Innenansichten von NT-Hilfsprogrammen“
    • Meine Mai-Kolumne im Windows NT Magazin
    • Nicht ganz so neue Sachen

  2. INTERNALS-NEUIGKEITEN

    • Dr. GUI's schlechte Manieren am Krankenbett
    • WinDev '99 East
    • Numega Driver Works Release steht unmittelbar bevor
    • Beta 3 DDK veröffentlicht
    • Win2K „Queued Spinlocks“

  3. BALD VERFÜGBAR

    • Win2K System File Protector (SFP)

SPONSOR: WINTERNALS SOFTWARE

Der Systems Internals Newsletter wird von Winternals Software gesponsert (im Web unter http://www.winternals.com.). Winternals Software ist der führende Entwickler und Anbieter von erweiterten Systemtools für Windows NT/2K. Zu den Winternals Software-Produkten gehören FAT32 für Windows NT 4.0, ERD Commander (Startdatenträgerfunktion für Windows NT; Notfalldiskette) und NTRecover.

Guten Tag,

Willkommen zur zweiten Ausgabe des Systems Internals Newsletters. Der Newsletter hat derzeit 2700 Abonnenten, und die Zahlen steigen weiter.

Seit dem letzten Newsletter hat Microsoft offiziell Windows 2000 Beta 3 veröffentlicht. Die Buildnummer des Beta 3-Kernels ist 2031, während die des Kernels der ersten Version von NT 4.0 1381 und die von NT 3.51 1025 war. . Was ich seltsam (und etwas ärgerlich) finde, ist, dass Microsoft die Buildnummer jedes Mal erhöht, wenn sie einen vollständigen Build des Betriebssystems erstellen (jeden Arbeitstag), die gemeldete Buildnummer des Kernels jedoch die des ersten öffentlichen Release widerspiegelt. Obwohl z. B. die tatsächliche Buildnummer des NT 4.0 Service Pack 5-Kernels viel höher ist als 1381, meldet der Kernel immer noch 1381 als Buildnummer.

Die Veröffentlichung der Beta 3 von Windows 2000 soll ein Weckruf an die Entwicklergemeinde sein. Microsoft hat angekündigt, dass es Windows 2000 im Oktober ausliefern wird und dass die Beta 3 die mit allen Funktionen ausgestattete Auslieferungsversion darstellt, sodass die Entwickler mit der Entwicklung neuer Produkte beginnen können, ohne befürchten zu müssen, dass sich die Dinge unter ihren Füßen ändern werden.

Windows 2000 enthält eine Reihe neuer APIs, mehrschichtiger Dienste und Kernel-Verbesserungen. Eine Änderung, die vor allem für Entwickler von Gerätetreibern sichtbar sein wird, ist, dass sich der Blue Screen of Death (BSOD) geändert hat. In früheren Versionen von NT zeigte der BSOD Informationen zur Linkzeit und zur Ladeadresse für alle Treiber auf einem System sowie ein Abbild des Stapels an, wie er zum Zeitpunkt des Absturzes vorhanden war. In Windows 2000 werden nur der Stoppcode und die zugehörige(n) Adresszeile(n) (Adresszeilen übersetzen einen oder mehrere der Stoppcode-Parameter in Orte innerhalb von Gerätetreibern) zusammen mit einer ausführlichen Meldung angezeigt. In der Supportmeldung wird empfohlen, das BIOS und die Festplatteneinstellungen zu überprüfen sowie Defragmentierungssoftware und Virenscanner zu deaktivieren, um einen erneuten Absturz zu vermeiden. Die Microsoft Premier Support Services (PSS) haben aufgrund ihrer Erfahrungen und der Rückmeldungen von Kunden bestimmt, dass der BSOD im Stil von NT 4 nicht geeignet ist, die Ursache eines Absturzes zu ermitteln.

Ich persönlich fand die Liste der geladenen Treiber und insbesondere das Stapelabbild sehr nützlich, wenn ich Fehlerberichte von Anwendern erhielt. Auf diese Weise erhält man diese Informationen viel einfacher und schneller, als von Anwendern ein mehrere Megabyte großes Absturzabbild anfordern zu müssen. Ich habe die Absturzursache oft anhand des Stapelabbilds isoliert und die Treiberversionen, die Benutzer geladen haben, anhand der in der Treiberliste angezeigten Versionsinformationen verifiziert. Ich bin neugierig, was Sie denken: Würden Sie es begrüßen, wenn der BSOD im Stil von NT 4 in Windows 2000 übertragen würde, oder ist das neue BSOD-Format ausreichend? Schicken Sie mir eine E-Mail, wenn Sie eine Meinung haben. Über die Ergebnisse dieser informellen Umfrage werde ich im nächsten Newsletter berichten. Wenn ich schon beim Thema BSODs bin, sollten Sie sich unbedingt das Windows 2000-Update des beliebten BlueScreen-Bildschirmschoners von Systems Internals ansehen, das in dieser Ausgabe behandelt wird.

Vielen Dank!

-Mark

NEUERUNGEN BEI SYSTEM INTERNALS

SDELETE

Als Teil der Erfüllung der Anforderungen der C2-Sicherheitseinstufung implementiert Windows NT 4.0 den „Objektwiederverwendungsschutz“. Das bedeutet, dass NT Datei- und Arbeitsspeicherressourcen, die Anwendungen zuweisen, auf Null setzt, wenn die Anwendungen zum ersten Mal auf die Ressourcen zugreifen. Dadurch wird verhindert, dass eine Anwendung z. B. eine große Datei erstellt und deren Inhalt untersucht, um festzustellen, was zuvor auf der Festplatte gespeichert war. Der Objektwiederverwendungsschutz erstreckt sich jedoch nicht auf den Schutz von Ressourcen, auf die Anwendungen zugreifen können, die standardressourcenbezogene APIs umgehen oder die das Betriebssystem ganz umgehen. Sie können zum Beispiel einen Festplatten-Editor wie DiskProbe aus dem Resource Kit verwenden, um den Inhalt nicht zugewiesener Teile einer Festplatte zu untersuchen. So können Sie Daten sehen, die zuvor zu gelöschten Dateien gehörten.

In vielen Umgebungen ist eine Funktion für „sicheres Löschen“ erforderlich. Mit dieser Funktion können Benutzer vertrauliche Daten dauerhaft löschen, sodass sie für Tools, die die Schutzfunktionen des Betriebssystems umgehen, nicht sichtbar sind. Die Einführung des verschlüsselnden Dateisystems (Encrypting File System, EFS) hat den Bedarf an einer sicheren Löschfunktion in Windows 2000 deutlich gemacht. Wenn Sie eine zuvor unverschlüsselte Datei verschlüsseln, löscht EFS beim Freigeben der Datenträgerzuordnungen nicht den Inhalt der Datenträgerzuordnungen, die die unverschlüsselten Daten der Datei enthielten. Somit existiert, auch wenn die aktive Version einer Datei, die Sie verschlüsseln, sicher ist, die alte Version der Datei immer noch in den nicht zugeordneten Bereichen eines Datenträgers, bis sie zufällig durch neue Dateidaten überschrieben wird, die NTFS diesen Bereichen zuweist.

Um diese Lücke zu schließen, habe ich SDelete (Secure Delete, Sicheres Löschen) geschrieben. Es ist ein Befehlszeilentool, mit dem Sie nicht nur Standarddateien sicher löschen können, sondern auch alle zuvor gelöschten Daten, die sich in den nicht zugeordneten Bereichen eines Datenträgers befinden, sicher löschen können. Darüber hinaus arbeitet es mit komprimierten, verschlüsselten Dateien sowie Dateien mit geringer Datendichte (sparse) von Windows NT/2000, was die Verwendung der Defragmentierungs-API erfordert. SDelete hält den „Clearing and Sanitizing“-Standard DOD 5220.22-M des Verteidigungsministeriums ein, damit Sie sicher sein können, dass Ihre Daten nach dem Löschen für immer gelöscht sind.

Ich stelle SDelete zusammen mit dem vollständigen Quellcode und einer Beschreibung seiner Funktionsweise zur Verfügung, damit Sie nachvollziehen können, wie es die Defragmentierungs-API nutzt, und damit Sie meine Behauptungen überprüfen können, dass es verhindert, dass Ihre sensiblen gelöschten Daten wiederhergestellt werden können.

Die Dokumentation zur Defragmentierungs-API von Windows NT/2000 finden Sie unter http://www.sysinternals.com/defrag.htm.. SDelete zusammen mit dem vollständigen Quellcode können Sie unter http://www.sysinternals.com/sdelete.htm. herunterladen.

BLUESCREEN-BILDSCHIRMSCHONER WIN2K-UPDATE

Die Änderungen, die Microsoft am Layout des NT-Startbildschirms und des Blue Screen of Death (BSOD) in Windows 2000 vorgenommen hat, haben ein größeres Update des BlueScreen-Bildschirmschoners von Systems Internals erforderlich gemacht. Um Ihnen weiterhin ein Höchstmaß an BSOD-Realismus bieten zu können, habe ich Version 2.0 des Bildschirmschoners veröffentlicht. Sie spiegelt nicht nur die Änderungen am BSOD-Format wider, sondern ahmt auch den Startbildschirm von Windows 2000 genau nach, komplett mit rotierenden Statuskreis und Aktualisierungen der Statusanzeige. Er wirkt so echt, dass der Bildschirmschoner sogar Windows 2000-Experten und -Entwickler täuscht. Natürlich zeigt der BlueScreen-Bildschirmschoner unter NT 4.0 immer noch die BSOD- und Startbildschirme von NT 4.0 an.

Wie habe ich den Startbildschirm von Windows 2000 so perfekt nachgebildet und gleichzeitig nicht gegen das Urheberrecht verstoßen? Ich habe die Bitmap-Grafiken für den Start von Windows 2000 nicht in den Bildschirmschoner integriert. Stattdessen verwende ich DirectX, um den Grafikmodus während der Startsequenz auf den von Windows 2000 verwendeten Modus umzuschalten, und verweise dann auf die Bitmap-Ressourcen der Windows 2000-Kerneldatei „ntoskrnl.exe“. Diese Ressourcen (Sie können sie anzeigen, indem Sie die Ressourcen von „ntoskrnl.exe“ in Visual Studio öffnen) sind diejenigen, die vom Kernel angezeigt werden, was eine Änderung gegenüber der Vorgehensweise von Windows 9x darstellt, wo Startgrafiken eigentlich separate Dateien sind. Es sieht nicht so aus, als ob Computer-OEMs die Möglichkeit haben werden, die Starterfahrung in Windows 2000 anzupassen...

Sie können den BlueScreen-Bildschirmschoner unter http://www.sysinternals.com/bluescreen.htm. herunterladen. Wenn Sie eine lustige Geschichte haben, wie Sie jemanden mit dem Bildschirmschoner getäuscht haben, geben Sie sie bitte weiter.

Weitere Informationen über das Wie und Warum von BSODs finden Sie in meiner Kolumne „Inside the Blue Screen“ (Innenansichten des Bluescreens) im Windows NT Magazine NT Internals vom Dezember 1997. Ein Link auf der Seite mit den Veröffentlichungen von Systems Internals, http://www.sysinternals.com/publ.htm, führt Sie zur Onlineversion dieser Kolumne. Die Seite enthält auch Links zu anderen Onlinepräsentationen von Artikeln und Kolumnen, die ich verfasst habe.

„LINUX UND DAS UNTERNEHMEN“

Die enorme Resonanz der Linux-Community auf meinen Artikel in der April-Ausgabe des Windows NT Magazine über die Skalierbarkeitsmängel des Linux-Kernels hat das Magazin veranlasst, die Onlineversion des Artikels früher als geplant zu veröffentlichen. Einen Link zu dem Artikel „Linux und das Unternehmen“ finden Sie im Abschnitt „Artikel“ auf http://www.sysinternals.com/publ.htm.. Der Artikel beschreibt mehrere Einschränkungen der aktuellen Version des Linux-Kernels (2.2x), darunter das Fehlen eines effizienten Event-Waiting-Mechanismus, eine erhebliche Serialisierung von Systemaufrufen, das Fehlen asynchroner E/A sowie eine schlechte Implementierung der Socket-API „sendfile“(in NT heißt diese „TransmitFile“). Die Kombination dieser Einschränkungen verhindert, dass Linux bei Unternehmensanwendungen wie Webservern, Datenbankservern und E-Mail-Servern in puncto Leistung mit NT und anderen UNIX-Distributionen konkurrieren kann.

„INNENANSICHTEN VON NT-HILFSPROGRAMMEN“

Wenn Sie Filemon, Regmon oder HandleEx verwendet haben und mehr darüber wissen wollten, welche Informationen sie Ihnen liefern und wie sie implementiert sind, dann wird Sie meine Februar-Kolumne „Inside NT Utilities“ (Innenansichten von NT-Hilfsprogrammen) im Windows NT Magazine interessieren. In dieser Kolumne wird das Innenleben dieser Tools beschrieben, und im Falle von Regmon und Filemon erfahren Sie etwas über die Fehlercodes und Abfragetypen, die diese bei der Erfassung von Registrierungs- oder Dateisystemaktivitäten protokollieren. Ein Link zur Onlineversion dieses Artikels, die soeben verfügbar geworden ist, findet sich unter http://www.sysinternals.com/publ.htm..

MEINE MAI-KOLUMNE IM WINDOWS NT-MAGAZIN

Haben Sie sich jemals gefragt, wie Windows NT/2000 den Inhalt der Registrierung im Arbeitsspeicher (In-Memory) oder auf der Festplatte organisiert? Die aktuelle (Mai) Ausgabe des Windows NT Magazine enthält meine Kolumne „Inside the Registry“ (Innenansichten der Registrierung), in der Sie dies und mehr erfahren. So erfahren Sie beispielsweise, wie das Kernel-Modus-Subsystem von Configuration Manager (das für die Verwaltung der Registrierung zuständige Subsystem) Schlüssel nachschlägt, Wertdaten speichert, die Suche optimiert und die Integrität der Registrierungsdateien auf der Festplatte schützt. Windows NT Magazine, http://www.winntmag.com, ist bei Borders und Barnes and Nobles erhältlich.

NICHT GANZ SO NEUE SACHEN

Nicht lange nach der Veröffentlichung der Beta 2 von Windows 2000 habe ich den geprüften (Debug-)Build der Kernel-Imagedatei (ntoskrnl.exe) genommen, eine Zeichenfolgensuche im Kernel durchgeführt und so eine Liste der Namen der Quelldateien erhalten, die zur Erstellung des Kernels verwendet wurden. Der geprüfte Build des NT/2000-Kernels enthält zahlreiche Assert-Anweisungen (Konsistenzüberprüfungen), die den Dateinamen der Datei enthalten, in der sich das Assert befindet. Wenn man davon ausgeht, dass praktisch jede Datei von Bedeutung im Kernel-Quelltext mindestens einen Assert enthält, ist die Liste ziemlich umfassend. Das Übertragen der Liste in ein Java-Skript hat mir eine nette, Explorer-ähnliche Baumansicht (Treeview) der Verzeichnisstruktur des Windows 2000-Quellbaums geliefert. Sie finden ihn unter http://www.sysinternals.com/nt5src.htm..

INTERNALS-NEUIGKEITEN

DR. GUI'S SCHLECHTE MANIEREN AM KRANKENBETT

In der März/April-Ausgabe der Microsoft Developer Network News pariert Dr. GUI die Frage eines Lesers, der wissen möchte, wie ein Treiber seine Threads zur Verwendung einer bestimmten CPU zwingen (affinitize) kann. Dr. GUI antwortet, dass es keine Möglichkeit gibt, die Anzahl der Prozessoren auf einem System aus einem Treiber zu bestimmen, und dass ein Treiberthread nicht bestimmen kann, auf welchem Prozessor er läuft. Leider hat Dr. GUI diese Diagnose vermasselt (vielleicht sollte Dr. GUI bei GUIs bleiben).

Der NT-Kernel (ntoskrnl.exe) exportiert eine Variable namens „KeNumberProcessors“, die in NTDDK.H wie folgt definiert ist:

extern PCCHAR KeNumberProcessors;

Sie kann in einem Treiber wie folgt direkt referenziert werden:

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

Um festzustellen, auf welchem Prozessor ein Treiberthread läuft, verwenden Sie „KeGetCurrentProcessorNumber()“, einen weiteren Kernelexport, der nicht nur in NTDDK.H definiert, sondern sogar im DDK dokumentiert ist!

Dr. GUI hat das falsche Medikament für dieses Leiden verordnet, woraufhin ich den Dr. höflich per E-Mail darauf hingewiesen habe. Überraschenderweise hat Dr. GUI die E-Mail nicht einmal zur Kenntnis genommen. Mal sehen, ob der gute Dr. den Fehler in der nächsten Ausgabe einräumt...

WINDEV '99 EAST

Die East Coast Edition von 1999 der führenden Konferenz für Windows-Entwickler nähert sich schnell. Die WinDev '99 East findet vom 14. bis 18. Juni im Boston Cambridge Marriot statt. Eine Reihe großer Namen der Windows-Entwicklung sprechen, darunter Jeff Richter, Jeff Prosise und Don Box. Ich werde zusammen mit Jamie Hanrahan und Brian Catlin im Bereich der Gerätetreiber teilnehmen. Zu meinen Präsentationen gehören ein ganztägiges Tutorial über NT Internals sowie eine zum Schreiben von Windows NT/2K-Dateisystemtreibern und eine über komplexere Probleme bei der Entwicklung von Gerätetreibern. Kommen Sie vorbei, und sagen Sie Hallo!

NUMEGA DRIVER WORKS RELEASE STEHT UNMITTELBAR BEVOR

Compuware NuMega Labs steht kurz vor der Veröffentlichung eines leistungsstarken neuen Windows 9x/NT/2K-Gerätetreiber-Entwicklungskits, DriverStudio. DriverStudio kombiniert alle vorhandenen Gerätetreibertools von NuMega, einschließlich DriverAgent, DriverWorks, SoftICE und VtoolsD, und fügt den neuen BoundsChecker für Treiber und FieldAgent (nur Windows NT/2K) hinzu.

Die Gerätetreiberversion von BoundsChecker bietet eine umfassende Überwachung jeder Kernel-API, die Ihr Treiber verwendet, und Sie können damit die Interaktionen Ihres Treibers mit jedem anderen Gerätetreiber auf dem System überwachen. Mit FieldAgent können Sie die Treiberversion von BoundsChecker auf Clientsystemen bereitstellen, sodass Clients Ablaufverfolgungen für Sie sammeln können, die Sie dann analysieren können. In Kürze werden TrueTime für Treiber und TrueCoverage für Treiber – Tools, mit denen Sie auf einfache Weise die Leistung Ihrer Gerätetreiber optimieren und deren Abdeckung testen können – als kostenloses Update für DriverStudio-Kunden erscheinen.

Dieses Paket ist das ultimative Treiberentwicklungskit, und ich kann es nur wärmstens empfehlen (ich nehme am Betaprogramm teil). Weitere Informationen finden Sie unter http://www.numega.com..

BETA 3 DDK VERÖFFENTLICHT

In Verbindung mit der Veröffentlichung von Windows 2000 Beta 3 hat Microsoft das Windows 2000 Beta 3 DDK (Device Driver Kit) zum kostenlosen Download zur Verfügung gestellt. Sie können sich das DDK unter http://www.microsoft.com/ddk/ddk2kb3.htm. herunterladen. Ich hoffe, dass das SDK bald folgen wird, da die Beta 3 eine Reihe von Win32-APIs enthält, die in der April-Ausgabe von MSDN nicht dokumentiert sind.

WIN2K „QUEUED SPINLOCKS“

Windows 2000 verwendet für seine globalen Sperren einen neuen Spinlock-Typ namens „Queued Spinlock“ (Spinlock in Warteschlange). Die globalen Sperren in Windows 2000 sind dieselben wie die in Windows NT 4.0 und umfassen:

  • KiDispatcherLock: die Scheduler-Datenbanksperre
  • KiContext-SwapLock: die Tread-Swap-Sperre
  • MmPfnLock: die physische Seitenframedatenbank-Sperre
  • MmSystemSpaceLock: die Kernel-Modus-Adressraumsperre
  • CcMasterSpinLock: das globale Spinlock des Cache-Managers
  • CcVacbSpinLock: die Sperre des Zuordnungsarrays des Cache-Managers

Auf einem Einzelprozessor funktionieren Queued Spinlocks genau wie normale Spinlocks. Auf dem Multiprozessorbuild von NT unterscheiden sich die Queued Spinlocks jedoch deutlich. Wie die Standard-Spinlocks sind auch die Queued Spinlocks im HAL implementiert. Der Kernel ruft die HAL-Funktion KeAcquireQueuedSpinlock auf, um einen Queued Spinlock zu empfangen, und ruft KeReleaseQueuedSpinlock auf, um einen Queued Spinlock freizugeben. KeAcquireSpinlock und KeReleaseSpinlock, die HAL-Funktionen, die der Kernel zum Erlangen und Freigeben von Standard-Spinlocks verwendet, benötigen die Adresse des angegebenen Spinlocks als Parameter. Im Gegensatz dazu akzeptieren die Queued Spinlock-Funktionen die Indexnummer eines globalen Spinlocks. Der Kernel initialisiert die globalen Spinlocks in einem Array, wobei jedes Spinlock eine vordefinierte Indexnummer hat, die der Kernel verwendet, um sie gegenüber dem HAL zu identifizieren. Daher können Queued Spinlocks nicht von Gerätetreibern definiert und verwendet werden, da es keine Möglichkeit gibt, das Array globaler Queued Spinlocks zu erweitern.

In Windows 2000 besitzt jede Prozessorsteuerungsregion (PCR) in einem SMP (es gibt eine PCR für jeden Prozessor) ein Array mit so vielen Einträgen, wie es Queued Spinlocks gibt. Jeder Arrayeintrag enthält zwei Felder: einen Zeiger auf das Queued Spinlock, dem er entspricht (das Feld „spinlock“), und das Feld „queue“ (Warteschlange). Wenn ich mich in der folgenden Beschreibung auf die Felder „spinlock“ und „queue“ beziehe, meine ich damit die Felder, die dem Arrayeintrag für das Spinlock zugeordnet sind, das erlangt oder freigegeben wird.

KeAcquireQueuedSpinlock funktioniert folgendermaßen: Die Funktion versucht, das Spinlock zu erlangen, indem sie die CPU-Anweisung „interlocked-exchange“ verwendet, um die Adresse der PCR des aktuellen Prozessors im Spinlock abzulegen. Wenn das Spinlock aktiv ist, hat die Funktion als Teil der exchange-Vorgangs die Adresse der PCR eines anderen Prozessors. Dann identifiziert sich die Funktion als „wartend“ (waiting), indem sie das niedrige Bit des spinlock-Felds in ihrer eigenen PCR umschaltet. Als Nächstes legt sie die Adresse ihres eigenen PCR im queue-Feld des PCR ab, den sie aus dem Spinlock abgerufen hat. Schließlich wartet sie in einer Busy-Schleife (ausgelastet), bis das niedrige Bit in seinem spinlock-Feld ausgeschaltet wird. Wenn das Bit ausgeschaltet ist, wurde dem aktuellen Prozessor das Spinlock gewährt, weshalb sie zum Aufrufer der Acquire-Funktion zurückkehrt.

Nachdem ein Prozessor ein Queued Spinlock erlangt und die Verarbeitung abgeschlossen hat, die er während der aktiven Sperre durchführen wollte, ruft er KeReleaseQueuedSpinlock auf. KeReleaseQueuedSpinlock sucht im queue-Feld nach dem angegebenen Spinlock im PCR des aktuellen Prozessors. Wenn das queue-Feld ungleich Null ist, hat ein anderer Prozessor seine PCR dort „queued“ (in die Warteschlange eingereiht). KeReleaseQueuedSpinlock löscht das niedrige Bit des spinlock-Felds für die wartende PCR, löscht dann sein eigenes queue-Feld und kehrt zurück. Durch das Löschen des niedrigen Bits im spinlock-Feld der wartenden PCR wurde der nächsten CPU in der Reihenfolge signalisiert, dass sie die Sperre übernehmen kann. Wenn das queue-Feld Null war, wartet kein anderer Prozessor auf die Sperre, und KeReleaseQueuedSpinlock führt einfach einen „interlocked-exchange“-Vorgang durch, um das globale Spinlock zu löschen.

Beim Betrieb von Queued Spinlocks „stellen sich Prozessoren in einer Schlange an“ und warten auf ein aktives Spinlock. Jeder Prozessor stellt sich selbst in die Warteschlange, indem er seinem Vorgänger mitteilt, dass er wartet. Dadurch erhält das Erlangen eines Queued Spinlocks eine deterministische Reihenfolge. Die Prozessoren erlangen das Spinlock in der Reihenfolge, in der sie es anfordern. Bei Standard-Spinlocks gibt es keine solche Reihenfolge. Queued Spinlocks haben noch einen weiteren bedeutenden Vorteil. Während ein Prozessor in einer Busy-Schleife (spinning) darauf wartet, dass in seinem spinlock-Feld das niedrige Bit gelöscht wird, führt er die Busy-Schleife im privaten Speicher seines eigenen Prozessors aus. Wenn ein Prozessor auf ein Standard-Spinlock wartet (busy-wait), führt er die Busy-Schleife auf dem globalen Spinlock selbst aus, das von allen Prozessoren gemeinsam genutzt wird. Daher haben Queued Spinlocks bessere Multiprozessor-Buseigenschaften, da während der Wartezeit (busy-wait) kein gemeinsamer Zugriff auf Cachezeilen erfolgt. Darüber hinaus gibt es aufgrund der Warteschlangeneigenschaften von Queued Spinlocks in der Regel weniger Bussperrvorgänge als bei Standard-Spinlocks, wenn eine Sperre von mehreren Prozessoren angefochten wird.

Queued Spinlocks sind eine von mehreren Verbesserungen, die Microsoft an der Multiprozessorskalierbarkeit von Windows 2000 vorgenommen hat.

BALD VERFÜGBAR

Windows 2000 enthält zahlreiche Funktionen, die das System widerstandsfähiger gegen Bedienungsfehler und fehlerhafte Anwendungen machen. Eine davon ist, dass viele der DLLs und Treiber in den Verzeichnissen %systemroot%\system32 und %systemroot%\system32\drivers durch einen Watchdog namens „System File Protector (SFP)“ geschützt sind. Sie können sein Vorhandensein überprüfen, indem Sie in das Verzeichnis system32 wechseln und ntoskrnl.exe umbenennen. Der Watchdog erwacht und benachrichtigt Sie, dass er eine Manipulation an einer geschützten Systemdatei erkannt hat und diese nun repariert. Wenn Sie das Verzeichnis noch einmal überprüfen, werden Sie feststellen, dass ntoskrnl.exe auf magische Weise ersetzt wurde. Wie das funktioniert, werde ich Ihnen nächstes Mal erklären.

Vielen Dank, dass Sie den Systems Internals Newsletter gelesen haben.

Veröffentlicht Samstag, 15. Mai 1999, um 19:15 Uhr von ottoh

[Newsletter-Archiv ^] [< Band 1, Nummer 1] [Band 1, Nummer 3 >]