E/s asynchrone disque apparaît comme synchrone sur Windows NT, Windows 2000 et Windows XP

Traductions disponibles Traductions disponibles
Numéro d'article: 156932 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Fichier d'e/s sur Microsoft Windows NT, Windows 2000 et Windows XP peut être synchrone ou asynchrone. Le comportement par défaut pour les e/s est synchrone : une fonction d'e/s est appelée et retourne lorsque les e/s est terminée. E/s asynchrones, d'autre part, permet à une fonction d'e/s retourner immédiatement l'exécution à l'appelant, mais les e/s n'est pas supposé être terminée jusqu'à une date ultérieure. Le système d'exploitation informe l'appelant lorsque les e/s est terminée. Sinon, l'appelant peut déterminer le statut de l'opération d'e/s en attente à l'aide des services du système d'exploitation.

L'avantage d'e/s asynchrone est que l'appelant a de temps pour faire otherwork ou émettre des demandes plus pendant l'exécution de l'opération d'e/s. Theterm les e/s avec chevauchement est fréquemment utilisé pour les e/s asynchrones et Non-overlappedI/O pour les e/s synchrones. Cet article utilise les termes andSynchronous asynchrone pour les opérations d'e/s sous Windows NT. Cet article suppose que thereader a certaine vous familiariser avec les fonctions d'e/s de fichier telles que WriteFile CreateFile, ReadFile.

Souvent, les opérations d'e/s asynchrones se comportent comme synchrone d'e/s. Certainconditions que cet article décrit dans les sections suivantes Assurez-vous le / Sopérations terminent de façon synchrone. L'appelant n'a pas le temps de backgroundwork parce que les fonctions d'e/s ne retournent pas jusqu'à ce que l'e/s est terminée.

Plusieurs fonctions sont liées aux e/s synchrones et asynchrones. Cet article utilise ReadFile et WriteFile, exemples ; bonnes alternatives serait ReadFileEx et WriteFileEx. Bien que cet article traite uniquement les e/s de disque en particulier, la plupart des principes peuvent être appliquées à d'autres types d'e/s, telles que les e/s série ou les e/s réseau.

Remarque: étant donné que Windows 95 ne gère pas les e/s asynchrones sur des périphériques de disque (même si c'est le cas dans d'autres types de périphériques d'e/s), son comportement n'est pas abordé dans cet article.

Plus d'informations

Paramétrer des e/s asynchrones

L'indicateur FILE_FLAG_OVERLAPPED doit être spécifié dans CreateFile lorsque le fichier est ouvert. Cet indicateur permet des opérations d'e/s sur le fichier pour être effectuée de manière asynchrone. Voici un exemple :
   HANDLE hFile;

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

   if (hFile == INVALID_HANDLE_VALUE)
      ErrorOpeningFile();
				
Soyez prudent lors du codage pour les e/s asynchrones, parce que le système réserve de bonnes pour effectuer une opération synchrone s'il faut. Par conséquent, il est préférable si vous écrivez le programme afin de gérer correctement une opération d'e/s qui peut être effectuée de manière synchrone ou asynchrone. L'exemple de code illustre ce compte.

Il y a beaucoup de choses un programme peut tout en attendant asynchronousoperations à exécuter, telles que les files d'attente des opérations supplémentaires ou un travail de doingbackground. Par exemple, le code suivant correctement handlesoverlapped et ne se superposent pas la fin d'une opération de lecture. Il doesnothing plus d'attendre que l'e/s en attente terminer :
   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);
				
Notez que & NumberOfBytesRead passé à ReadFile est différente de & NumberOfBytesTransferred passés de GetOverlappedResult. Si un operationhas été rendu asynchrone, GetOverlappedResult est ensuite utilisée pour determinethe le nombre réel d'octets transférés dans l'opération après son hascompleted. Le & NumberOfBytesRead passé à ReadFile n'a aucune signification.

Si, en revanche, une opération est effectuée immédiatement, puis & NumberOfBytesRead passé à ReadFile est valide pour le nombre d'octets lus. Dans ce cas, ignorer la structure OVERLAPPED passée à ReadFile ; ne l'utilisez pas avec GetOverlappedResult ou WaitForSingleObject.

Un autre inconvénient avec une opération asynchrone est que vous ne devez pas utiliser une structure OVERLAPPED jusqu'à ce que son fonctionnement en attente est terminée. Dans otherwords, si vous avez trois opérations d'e/s en attente, vous devez utiliser trois structures OVERLAPPED. Si vous réutilisez une structure OVERLAPPED, vous recevez des résultats imprévisibles dans les opérations d'e/s, et vous pouvez rencontrer une corruption des données. En outre, avant de pouvoir utiliser une structure OVERLAPPED pour la première fois, ou avant de la réutiliser après une opération antérieure, vous devez correctement initialiser il donc aucune donnée de gauche a une incidence sur la nouvelle opération.

Le même type de restriction s'applique à la mémoire tampon utilisée dans anoperation. Un tampon de données ne doit pas être lue ou écrit jusqu'à la fin de l'opération d'e/s d'itscorresponding ; lire ou écrire la buffermay entraînent des données endommagées et des erreurs.

Asynchrone d'e/s semble être toujours synchrone

Si vous avez suivi les instructions fournies plus haut dans cet article, cependant, toutes les opérations d'e/s terminent toujours généralement synchrone dans l'ordre émis et aucune des opérations ReadFile renvoie la valeur FALSE avec GetLastError() renvoie ERROR_IO_PENDING, cela signifie que vous n'avez aucun le temps de travail en arrière-plan. Pourquoi cela se produit-il ?

Il existe un certain nombre de raisons pourquoi les opérations d'e/s exécuter synchronouslyeven si vous avez codé pour une opération asynchrone :

Compression

Une obstruction à l'opération asynchrone est la compression NTFS. Le pilote de système de fichiers n'ont pas accès les fichiers compressés de façon asynchrone ; à la place alloperations sont uniquement effectuées synchrone. Cela ne s'applique pas aux fichiers qui arecompressed avec les utilitaires similaires à compresser ou PKZIP.

Cryptage NTFS

Similaire à la Compression, cryptage de fichiers entraîne le pilote système convertir les e/s asynchrone à synchrone. Si les fichiers décryptés, les demandes d'e/s est asynchrones.

Extension d'un fichier

Une autre raison que les opérations d'e/s effectuées de façon synchrone est les opérations eux-mêmes. Sous Windows NT, toute écriture opération dans un fichier qui étend sa longueur sera synchrone.

Remarque: les Applications peuvent rendre l'opération d'écriture mentionné précédemment asynchrones en changeant la longueur de données valides du fichier à l'aide de la fonction SetFileValidData, puis d'émettre un fichier d'écriture.

À l'aide de SetFileValidData (qui est disponible sur Windows XP et versions ultérieures), les applications peuvent étendre efficacement les fichiers sans entraîner une baisse des performances pour le remplissage par des zéros les.

Étant donné que le système de fichiers NTFS ne le fait pas zéro-remplissage de données jusqu'à atteindre la longueur de données valides (VDL) qui est définie par SetFileValidData, cette fonction a des implications de sécurité où le fichier peut être affecté clusters qui ont été précédemment occupés par d'autres fichiers. Par conséquent, SetFileValidData requiert que l'appelant a la nouvelle SeManageVolumePrivilege activé (par défaut, il est attribué uniquement aux administrateurs). Microsoft recommande que les éditeurs de logiciels avec soin les implications de l'utilisation de cette fonction.

Mémoire cache

La plupart des pilotes d'e/s (disque, les communications et autres) ont un code cas spécial, où, si une demande d'e/s peut être terminée "immédiatement", l'opération sera terminée et la fonction ReadFile ou WriteFile renvoie la valeur TRUE. Dans tous les cas, ces types d'opérations semblent être synchrone. Pour un diskdevice, en règle générale, une demande d'e/s peut être effectuée « immédiatement » lorsque les données sont mises en cache dans la mémoire.

Données ne sont pas dans le Cache

Le jeu de cache peut travailler contre vous, toutefois, si les données ne se trouvent pas dans le cache. Le cache de Windows NT est implémenté en interne à l'aide de mappages de fichiers.Le Gestionnaire de mémoire de Windows NT ne fournit pas un mécanisme asynchrone pagefault pour gérer les mappages de fichier utilisés par le Gestionnaire de cache. Le Gestionnaire de cache peut, toutefois, vérifier si la page demandée est en mémoire, donc si vous émettez une lecture asynchrone de mise en cache, et que les pages ne sont pas dans la mémoire, le pilote de système de fichiers suppose que vous ne souhaitez pas que votre thread bloqué et que la demande sera gérée par un groupe limité de threads de travail. Contrôle est renvoyé à votre programme après l'appel de ReadFile avec la lecture toujours en attente.

Cette méthode fonctionne parfaitement pour un petit nombre de requêtes, mais étant donné que le pool de threads de travail est limité (actuellement trois sur un système 16 Mo), il seront toujours être uniquement quelques demandes file pour le pilote de disque à un moment donné. Si vous exécutez un grand nombre d'opérations d'e/s pour les données qui ne sont pas dans le cache, le Gestionnaire de cache et le Gestionnaire de mémoire deviennent saturés et vos demandes sont synchrones.

Le comportement du Gestionnaire de cache peut également être influencé basée sur l'accès whetheryou un fichier dans l'ordre ou de façon aléatoire. Avantages du cache sont seenmost lors de l'accès aux fichiers de manière séquentielle. Le flagin FILE_FLAG_SEQUENTIAL_SCAN l'appel de CreateFile va optimiser le cache pour ce type d'accès.Toutefois, si vous accéder aux fichiers de manière aléatoire, utilisez theFILE_FLAG_RANDOM_ACCESS indicateur de CreateFile pour indiquer son comportement pour un accès aléatoire à la tooptimize de gestionnaire de cache.

N'utilisez pas le Cache

L'indicateur FILE_FLAG_NO_BUFFERING a le plus d'effets sur le comportement du système de thefile pour une opération asynchrone. Il s'agit de la meilleure méthode pour garantir que requêtes sont effectivement asynchrones. Il indique le fichier quant pas utiliser n'importe quel mécanisme de cache du tout.

Avertissement: il existe certaines restrictions à l'utilisation de cet indicateur à faire avec l'alignement de mémoire tampon de données et la taille de secteur du périphérique. Consultez la référence de fonction dans la documentation de la fonction CreateFile pour plus d'informations sur l'utilisation de cet indicateur correctement.

Résultats des tests dans la réalité

Voici certains résultats de tests à partir de l'exemple de code. L'amplitude de thenumbers n'est pas important ici et varie d'un ordinateur à l'autre, mais la relation des nombres par rapport à eux éclaire général affectent des indicateurs sur les performances.

Vous devriez voir des résultats semblables aux suivants :
  • 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.
    						
    Ce test montre que le programme mentionné précédemment émis rapidement de 500 demandes d'e/s et eu beaucoup de temps à effectuer un autre travail ou émettre des demandes plus.
  • 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.
    						
    Ce test démontre que ce programme a passé à 4.495880 secondes appel de ReadFile pour terminer ses opérations, alors que le test 1 a passé 0.224264 secondes uniquement pour émettre les requêtes mêmes. Dans test 2, n'a aucun temps « extra » du programme effectuer le travail en arrière-plan.
  • Test 3
    Asynchronous, buffered I/O: asynchio /f*.dat
    
       Operations completed in the order issued.
       500 requests issued and completed in 0.251670 seconds.
    						
    Ce test illustre la nature synchrone du cache. Toutes les lectures ont été délivrés et terminées en 0.251670 secondes. En d'autres termes, les demandes asynchrones a été effectuées de façon synchrone. Ce test illustre également les hautes performances du Gestionnaire de cache lorsque les données sont dans le 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.
    						
    Ce test illustre les mêmes résultats que test 3. Notez que les lectures synchrones à partir du cache terminer un peu plus rapidement que les lectures asynchrones à partir du cache. Ce test illustre également les hautes performances du Gestionnaire de cache lorsque les données sont dans le cache.

CONCLUSION

Vous pouvez décider quelle méthode est préférable car tout dépend du type, la taille et le nombre d'opérations qui exécute votre programme.

L'accès au fichier par défaut sans spécifier tous les indicateurs spéciaux pour CreateFileis une opération synchrone et mis en cache.

Remarque: vous obtenez un comportement asynchrone automatique dans ce mode, étant donné que le pilote de système de fichiers ne prédictive asynchrone lecture anticipée et asynchrone écriture différée des données modifiées. Bien que cela n'a aucune application [ASCII 146] s d'e/s asynchrones, il est idéalement pour la grande majorité des applications simples.

Si, en revanche, votre application n'est pas simple, vous devrez dosome le profilage et l'analyse des performances pour déterminer la meilleure méthode, similaire aux tests illustrés plus haut dans cet article. Profilage le temps passé dans les theReadFile ou fonction WriteFile et en comparant cette fois, de façon trop long il takesfor des opérations d'e/s réelles se termine est extrêmement utile. Si la majorityof que le temps passé en émettant effectivement les e/s, puis votre e/s est beingcompleted de manière synchrone. Toutefois, si le temps passé à émetteur d'e/s demandes isrelatively petit par rapport à la durée de le tocomplete d'opérations d'e/s, puis vos opérations sont en cours traitées en mode asynchrone. Le samplecode mentionné plus haut dans cet article utilise la fonction QueryPerformanceCounter pour effectuer son owninternal de profilage.

Analyse des performances peut aider à déterminer la pertinence de votre isusing programme le disque et le cache. Le suivi des compteurs de performance pour l'objet de Cache indique les performances du Gestionnaire de cache.Le suivi des compteurs de performance du disque physique ou logique Diskobjects indique les performances des systèmes de disque.

Il existe plusieurs utilitaires qui sont utiles pour l'analyse des performances ;Analyseur de performances et de la commande DiskPerf sont particulièrement utiles. Pour le système collecter des données sur les performances des systèmes de disque, vous devez tout d'abord émettre la commande -y diskperf. Une fois que vous exécutez la commande, vous devez redémarrer le système pour démarrer la collecte de données.

Références

Pour plus d'informations sur ces utilitaires et analyse des performances, consultez le volume « optimisation de Windows NT » dans la documentation ResourceKit où Windows NT.
SQL Server nécessite des systèmes pour prendre en charge des « remise garantie sur un support stable » comme indiqué dans le programme d'évaluation de la Solution Microsoft SQL Server sacoche stockage. FOPour plus d'informations sur la configuration d'entrée et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
967576 Configuration requise de Microsoft SQL Server de base de données moteur d'entrée/sortie

Propriétés

Numéro d'article: 156932 - Dernière mise à jour: samedi 8 février 2014 - Version: 8.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • 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
Mots-clés : 
kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d?une traduction incorrecte du contenu ou de son utilisation par les clients.
La version anglaise de cet article est la suivante: 156932
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

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