Asynchrone Disk i/o wird als synchrone unter Windows NT, Windows 2000 und Windows XP angezeigt.

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 156932 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dateioperationen auf Microsoft Windows NT, Windows 2000 und Windows XP kann synchron oder asynchron sein. Ist das Standardverhalten für e/a synchron: eine e/a-Funktion wird aufgerufen und gibt nach Abschluss der e/a. Asynchrone e/a auf der anderen Seite ermöglicht eine e/a-Funktion, die Ausführung sofort wieder an den Aufrufer zurückgeben, aber die e/a ist nicht als vollständige bis zu einem späteren Zeitpunkt. Das Betriebssystem benachrichtigt den Aufrufer, wenn die e/a abgeschlossen ist. Alternativ kann der Aufrufer den Status der ausstehenden e/a-Vorgang mithilfe von Diensten des Betriebssystems ermitteln.

Der Vorteil der asynchronen e/a ist, dass der Aufrufer Zeit zu tun hat Arbeiten Sie oder setzen Sie mehr Anforderungen ab, während der e/a-Vorgang abgeschlossen ist. Die Überlappende e/a Begriff wird häufig für asynchrone e/a und nicht überlappende verwendet. E/a für synchrone e/a. In diesem Artikel werden die Begriffe Asynchronous verwendet und Synchron für e/a-Operationen unter Windows NT. Dieser Artikel geht davon aus dem Reader hat bestimmte Kenntnisse im Umgang mit der Datei-e/a-Funktionen wie CreateFile, ReadFile, WriteFile.

Verhalten sich häufig, asynchrone e/a-Vorgänge ebenso wie synchrone e/a. bestimmte Bedingungen, die in den nachfolgenden Abschnitten wird erläutert, stellen die e/a Vorgänge synchron abgeschlossen. Der Aufrufer hat keine Zeit für den Hintergrund Arbeiten Sie, da die e/a-Funktionen nicht zurückgegeben werden, bis die e/a abgeschlossen ist.

Mehrere Funktionen beziehen sich auf synchrone und asynchrone e/a. In diesem Artikel verwendet ReadFile und WriteFile als Beispiele; gute alternativen wäre ReadFileEx und WriteFileEx. Obwohl nur Disk i/o speziell erläutert, können viele der Prinzipien an andere Typen von e/a, z. B. serial i/o- oder Netzwerk-e/a angewendet werden.

Hinweis: Da Windows 95 nicht unterstützt asynchrone e/a auf Festplatten-Devices (obwohl dies auf andere Typen von e/a-Geräten der Fall ist), dessen Verhalten ist in diesem Artikel nicht behandelt.

Weitere Informationen

Richten Sie asynchrone e/a

FILE_FLAG_OVERLAPPED-Flag muss in CreateFile angegeben werden, wenn die Datei geöffnet wird. Dieses Flag ermöglicht e/a-Operationen für die Datei asynchron durchgeführt werden. Es folgt ein Beispiel:
   HANDLE hFile;

   hFile = CreateFile(szFileName,
                      GENERIC_READ,
                      0,
                      NULL,
                      OPEN_EXISTING,
                      FILE_FLAG_NORMAL | FILE_FLAG_OVERLAPPED,
                      NULL);

   if (hFile == INVALID_HANDLE_VALUE)
      ErrorOpeningFile();
				
Seien Sie vorsichtig beim Codieren für asynchrone e/a, da das System behält sich das Recht, eine Operation synchrone vornehmen, wenn er muss. Aus diesem Grund empfiehlt es beim Schreiben das Programm einen e/a-Vorgang ordnungsgemäß zu behandeln, der synchron oder asynchron ausgeführt werden können. Der Beispielcode demonstriert diese Überlegung.

Es gibt viele Dinge, die ein Programm kann do while waiting for asynchrone Vorgänge abgeschlossen, z. B. queuing zusätzliche Operationen oder tun, Hintergrundarbeiten. Der folgende Code z. B. verarbeitet ordnungsgemäß Vervollständigung für einen Lesevorgang überlappende und nicht überlappend fest. Dies der Fall ist nichts mehr als Warten der ausstehenden e/a abgeschlossen:
   if (!ReadFile(hFile,
                 pDataBuf,
                 dwSizeOfBuffer,
                 &NumberOfBytesRead,
                 &osReadOperation )
   {
      if (GetLastError() != ERROR_IO_PENDING)
      {
         // Some other error occurred while reading the file.
         ErrorReadingFile();
         ExitProcess(0);
      }
      else
         // Operation has been queued and
         // will complete in the future.
         fOverlapped = TRUE;
   }
   else
      // Operation has completed immediately.
      fOverlapped = FALSE;

   if (fOverlapped)
   {
      // Wait for the operation to complete before continuing.
      // You could do some background work if you wanted to.
      if (GetOverlappedResult( hFile,
                               &osReadOperation,
                               &NumberOfBytesTransferred,
                               TRUE))
         ReadHasCompleted(NumberOfBytesTransferred);
      else
         // Operation has completed, but it failed.
         ErrorReadingFile();
   }
   else
      ReadHasCompleted(NumberOfBytesRead);
				
Beachten Sie, dass & NumberOfBytesRead übergebenen ReadFile unterscheidet sich von & NumberOfBytesTransferred in GetOverlappedResult übergeben. Wenn ein Vorgang asynchrone, wurde dann GetOverlappedResult verwendet wird, um zu bestimmen die tatsächliche Anzahl der übertragenen Bytes in den Vorgang, nachdem es hat abgeschlossen. Die & NumberOfBytesRead übergebenen ReadFile ist ohne Bedeutung.

Wenn auf der anderen Seite eine Operation sofort dann abgeschlossen ist & NumberOfBytesRead übergebenen ReadFile gilt für die Anzahl der gelesenen Bytes. In diesem Fall ignorieren Sie die OVERLAPPED-Struktur, die ReadFile übergeben wurde; Nicht mit GetOverlappedResult oder WaitForSingleObject verwenden.

Eine andere Einschränkung von asynchronen Vorgang besteht darin, dass Sie eine OVERLAPPED-Struktur erst dann verwenden dürfen, nachdem der ausstehende Vorgang abgeschlossen ist. In anderen Wörter, haben Sie drei ausstehenden e/a-Vorgänge müssen Sie drei OVERLAPPED-Strukturen verwenden. Wenn Sie eine überlappende Struktur wiederverwenden, Sie erhalten zu unvorhersehbaren Ergebnissen in den e/a-Vorgängen und treten möglicherweise Beschädigung von Daten. Darüber hinaus müssen bevor Sie zum ersten Mal eine OVERLAPPED-Struktur verwenden können, oder Sie ihn wieder verwenden, wenn ein früherer Vorgang abgeschlossen ist, Sie korrekt initialisieren, damit keine Daten mehr der neuen Vorgang beeinflusst.

Die gleiche Art von Einschränkung gilt für die verwendeten Datenpuffer ein der Vorgang. Ein Datenpuffer muss nicht gelesen bzw. geschrieben werden, bis seine entsprechenden e/a-Vorgang abgeschlossen hat; Lesen oder Schreiben des Puffers Fehler und fehlerhafte Daten verursachen.

Asynchrone e/a-noch anscheinend Synchronous

Wenn Sie die Anweisungen weiter oben in diesem Artikel, sorgt für eine jedoch alle i/o-Operationen in der Regel noch abschließen synchron in der Reihenfolge ausgegeben, und keiner der ReadFile-Vorgänge gibt FALSE mit GetLastError() ERROR_IO_PENDING zurückgibt, das bedeutet, dass Sie keine Zeit für jede Arbeit Hintergrund haben. Warum geschieht dies?

Es gibt eine Reihe von Gründen, warum die e/a-Vorgänge synchron abgeschlossen auch wenn Sie für die asynchrone Operation programmiert haben:

Komprimierung

Ein Hindernis für den asynchronen Vorgang ist NTFS-Komprimierung. Die Datei Systemtreiber werden komprimierte Dateien nicht asynchron zugreifen; stattdessen alle Operationen sind nur synchrone vorgenommen. Dies gilt nicht für Dateien, die mit Dienstprogrammen wie COMPRESS oder PKZIP komprimiert wurden.

NTFS-Verschlüsselung

-Komprimierung entspricht, Dateiverschlüsselung wird den Systemtreiber, asynchrone e/a in synchronen konvertieren. Wenn die Dateien entschlüsselt sind, werden die e/a-Anforderungen asynchron sein.

Erweitern Sie eine Datei

E/a-Vorgänge synchron abgeschlossen wurde, sind ein weiterer Grund ist die Vorgänge selbst. Unter Windows NT schreiben alle, synchrone Operation in eine Datei, die seine Länge erweitert werden.

Hinweis: Anwendungen können, den zuvor erwähnten Schreibvorgang asynchrone indem ändern die gültige Datenlänge der Datei mithilfe der Funktion SetFileValidData, und dann eine WriteFile.

Mit SetFileValidData (die unter Windows XP und höheren Versionen verfügbar ist), können Anwendungen effizient Dateien erweitern, ohne eine Vertragsstrafe Leistung für NULL-füllen sie.

Da das NTFS-Dateisystem nicht der Fall ist 0 (null)-füllen Sie die Daten in die gültige Datenlänge (VDL), die durch SetFileValidData definiert ist, diese Funktion hat Auswirkungen auf die Sicherheit, kann die Datei Cluster zugewiesen werden, die zuvor von anderen Dateien belegt wurden. SetFileValidData erfordert daher, dass der Aufrufer die neue SeManageVolumePrivilege aktiviert haben (standardmäßig, dies ist nur Administratoren zugewiesen). Microsoft empfiehlt, dass die Auswirkungen der Verwendung dieser Funktion ISVs überdenken.

Cache

Die meisten e/a-Treiber (Datenträger, Kommunikation und andere) haben besonderen Fall Code, wobei, wenn eine e/a-Anforderung "sofort" abgeschlossen werden kann, der Vorgang abgeschlossen werden wird und die ReadFile oder WriteFile-Funktion gibt TRUE zurück. Diese Art von Vorgängen scheinbar in jeder Hinsicht synchron sein. Für einen Datenträger Gerät, in der Regel eine e/a-Anforderung abgeschlossen werden kann "sofort", wenn die Daten im Arbeitsspeicher zwischengespeichert werden.

Daten sind nicht im Cache

Das Cache-Schema kann arbeiten gegen Sie, jedoch, wenn die Daten nicht in der Cache. Windows NT-Cache wird intern mit Dateizuordnungen implementiert. Der Speicher-Manager in Windows NT bietet keine asynchrone Seite Fault Mechanismus zum Verwalten von Dateizuordnungen, die von der Cache-Manager verwendet. Die Cache-Manager kann jedoch überprüfen, ob die angeforderte Seite im Arbeitsspeicher befindet, also wenn Sie einen asynchronen Lesevorgang zwischengespeicherten ausgeben und die Seiten nicht im Speicher sind, wird der Dateisystemtreiber davon ausgegangen, dass Sie nicht, dass des Threads blockiert möchten und die Anforderung von einer begrenzten Pool von Worker-Threads verarbeitet werden. Steuerung wird an das Programm nach Ihrem Anruf ReadFile Lese-noch zurückgegeben.

Dies funktioniert gut für eine kleine Anzahl von Anforderungen, aber da der Pool von Worker-Threads ist begrenzt (derzeit drei auf einem System 16MB), es werden noch werden nur wenige Anforderungen in der Warteschlange an der Datenträgertreiber zu einem bestimmten Zeitpunkt. Wenn Sie eine Menge von e/a-Operationen für Daten, die nicht im Cache vorhanden ist ausgeben, die Cache-Manager und Speicher-Manager gesättigt werden und Ihre Anforderungen synchron.

Das Verhalten der Cache-Manager kann auch abhängig davon, ob beeinflusst werden Zugriff auf eine Datei sequenziell oder zufällig. Vorteile des Caches sind sichtbar. die meisten beim Zugriff auf Dateien sequenziell. Das FILE_FLAG_SEQUENTIAL_SCAN-flag in der CreateFile wird Aufruf den Cache für diese Art des Zugriffs zu optimieren. Jedoch verwenden, wenn Sie zufällig Dateien zugreifen, die FILE_FLAG_RANDOM_ACCESS-Flag in CreateFile anweisen den Cache-manager Optimieren Sie ihr Verhalten für den zufälligen Zugriff.

Verwenden Sie den Cache nicht

FILE_FLAG_NO_BUFFERING-Flag hat die meisten Auswirkungen auf das Verhalten von der File System für asynchrone Operation. Dies ist der beste Weg um zu gewährleisten die e/a-Anforderungen tatsächlich asynchron sind. Es weist das Dateisystem keine Verwendung zwischengespeichert jeder Mechanismus überhaupt.

Warnung: Es gibt einige Einschränkungen, die mit diesem Flag, die mit den Daten Puffer Ausrichtung und der Sektorgröße für das Gerät zu tun haben. Finden Sie unter den Funktionsverweis in der Dokumentation für die Funktion "CreateFile" für Weitere Informationen zur Verwendung dieses Flag ordnungsgemäß.

Im wirklichen Leben Testergebnisse

Im folgenden werden einige Testergebnisse aus dem Beispielcode. Das Ausmaß der Zahlen ist hier ohne Bedeutung und variiert von Computer zu Computer aber die Beziehung der Zahlen im Vergleich zu anderen leuchtet die Allgemeine Auswirkungen der Flags auf die Leistung.

Sie können erwarten, ähnlich der folgenden Ergebnisse finden Sie unter:
  • Test 1
    Asynchronous, unbuffered I/O:  asynchio /f*.dat /n
    
       Operations completed out of the order in which they were requested.
       500 requests queued in 0.224264 seconds.
       500 requests completed in 4.982481 seconds.
    						
    Dieser Test zeigt, dass das Programm zuvor erwähnte 500 e/a-Anforderungen schnell ausgestellt und viel Zeit hatte für andere Arbeiten durchführen, oder geben Sie weitere Anforderungen.
  • Test 2
    Synchronous, unbuffered I/O: asynchio /f*.dat /s /n
    
       Operations completed in the order issued.
       500 requests queued and completed in 4.495806 seconds.
    						
    Dieser Test zeigt, dass dieses Programm 4.495880 Sekunden ausgegeben ReadFile, um seine Vorgänge ausführen aufrufen, während der Test 1 verbrachte nur 0.224264 Sekunden um die gleichen Anforderungen ausgeben. In test 2, gab es keine "extra" Zeit für das Programm im Hintergrund zu tun arbeiten.
  • Test 3
    Asynchronous, buffered I/O: asynchio /f*.dat
    
       Operations completed in the order issued.
       500 requests issued and completed in 0.251670 seconds.
    						
    Dieser Test wird die synchrone Art des Caches veranschaulicht. Alle Lesevorgänge ausgestellt wurden und in 0.251670 Sekunden abgeschlossen. Das heißt, asynchrone Anforderungen wurden synchron abgeschlossen wurde. Dies auch testen veranschaulicht die Leistungsfähigkeit der Cache-Manager, wenn Daten in der Cache.
  • Test 4
    Synchronous, buffered I/O: asynchio /f*.dat /s
    
       Operations completed in the order issued.
       500 requests and completed in 0.217011 seconds.
    						
    Dieser Test zeigt die gleichen Ergebnisse wie bei Test 3. Beachten Sie, dass auf synchrone Lesevorgänge aus dem Cache ein wenig schneller als asynchrone Lesevorgänge aus dem Cache durchgeführt. Dieser Test zeigt auch hohe Performance der Cache-Manager, wenn Daten im Cache vorhanden ist.

ABSCHLUSS

Sie können entscheiden, welche Methode am besten ist, da alles hängt von Typ, Größe und Anzahl der Vorgänge, die das Programm ausführt.

Der Standardzugriff für die Datei ohne besondere Attribute zu CreateFile ist eine synchrone und zwischengespeicherte Operation.

Hinweis: Sie einige Automatisches asynchrones Verhalten in diesem Modus erhalten, weil der Dateisystemtreiber predictive asynchrones Read-ahead und asynchrones verzögertes Schreiben von geänderten Daten enthält. Obwohl dies nicht die Anwendung [ASCII 146] s i/o-asynchrone trifft, ist es der Idealfall für die meisten einfachen Anwendungen.

Wenn auf der anderen Seite die Anwendung nicht einfach ist, müssen Sie möglicherweise tun Einige Profilerstellung und Leistung zu überwachen, um zu bestimmen, die beste Methode, ähnlich wie die Tests, die weiter oben in diesem Artikel dargestellt. Profilerstellung für die Zeit verbrachte in der ReadFile oder WriteFile-Funktion und vergleichen diese Zeit, wie lange dauert es für aktuelle e/a-Vorgänge abgeschlossen ist äußerst nützlich. Wenn die meisten aufgewendete Zeit wird benötigt tatsächlich Ausstellen der i/o und dann wird die e/a synchron abgeschlossen wurde. Ist jedoch, wenn die ausstellende e/a-Anforderungen Zeit verstrichene. ziemlich klein verglichen mit der Zeit es nimmt für die e/a-Vorgänge abgeschlossen ist, werden Ihre Vorgänge asynchron betrachtet wird. Im Beispiel Code weiter oben in diesem Artikel erwähnten verwendet die Funktion QueryPerformanceCounter eigene tun interne Profilerstellung.

Performance-Überwachung können Sie herausfinden wie effizient Ihr Programm ist verwenden die Festplatte und den Cache. Verfolgen alle Leistungsindikatoren für das Cache-Objekt wird die Leistung des Cache-Manager angezeigt. Verfolgen die Leistungsindikatoren für die physischer oder logischer Datenträger Objekte werden die Leistung der Datenträgersysteme anzugeben.

Es gibt verschiedene Dienstprogramme, die bei der Leistungsüberwachung hilfreich sind. PerfMon und DiskPerf sind besonders nützlich. Für das System zum Sammeln von Daten auf die Leistung von Datenträger-Systemen muss zunächst den Diskperf -y-Befehl ausgegeben werden. Nachdem Sie den Befehl ausgeführt haben, müssen Sie das System zum Starten der Datensammlung starten.

Informationsquellen

Weitere Informationen zu diesen Dienstprogrammen und Performance-Überwachung finden Sie unter das Volume "Optimieren von Windows NT" in der Windows NT-Ressource Kit-Dokumentation.
SQL Server erfordert die Zustellungsgewährleistung stabile Medien unterstützen, gemäß der Microsoft SQL Server ununterbrochenes Storage Solution Review Program. FOWeitere Informationen zu den Eingabe- und Anforderungen für die SQL Server-Datenbank-Engine klicken Sie auf die folgende Artikelnummer klicken, um den Artikel der Microsoft Knowledge Base anzuzeigen:
967576Microsoft SQL Server-Datenbank-Engine Input/Output-Anforderungen

Eigenschaften

Artikel-ID: 156932 - Geändert am: Donnerstag, 30. Mai 2013 - Version: 6.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Win32 Application Programming Interface
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Keywords: 
kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 156932
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com