Des e/s disque asynchrone s'affiche comme synchrone sur Windows

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
Résumé
Les e/s à partir d'un fichier sur Microsoft Windows peuvent être synchrones ou asynchrones. Le comportement par défaut pour les e/s est synchrone, dans le cas où une fonction d'e/s est appelée et retourne lorsque les e/s est terminée. E/s asynchrone permet à une fonction d'e/s à l'exécution un retour à l'appelant immédiat, mais l'e/s n'est pas supposé être terminée jusqu'à une date ultérieure. Le système d'exploitation informe l'appelant lorsqu'elle 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 des e/s asynchrones est que l'appelant a du temps pour effectuer un autre travail ou émettre d'autres demandes pendant l'exécution de l'opération d'e/s. Le terme chevauchement I / Ois fréquemment utilisés pour les e/s asynchrones et Non superposé d'e/s d'e/s synchrones. Cet article utilise les termes asynchrone et synchrone pour les opérations d'e/s. Cet article suppose que le lecteur possède une connaissance avec les fonctions d'e/s de fichier telles que WriteFile de le CreateFile, ReadFile.

Fréquemment, les opérations d'e/s asynchrones se comportent simplement comme des e/s synchrones. Certaines conditions, que cet article traite dans les paragraphes suivants, font que les opérations d'e/s se terminent de façon synchrone. L'appelant n'a pas le temps de faire d'autre travail en arrière-plan parce que les fonctions d'e/s ne retournent que lorsque 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 la série d'e/s ou e/s réseau.
Plus d'informations

Paramétrer des e/s asynchrones

L'indicateur FILE_FLAG_OVERLAPPED doit être spécifié dans le CreateFile lorsque le fichier est ouvert. Cet indicateur permet des opérations d'e/s sur le fichier pour être exécutée de façon 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é dans GetOverlappedResult. Si un operationhas est devenu 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 transmis à 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'à la fin de l'opération en attente. 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 l'initialiser pour qu'aucune donnée restante ait 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 de jusqu'à la fin de l'opération d'e/s d'itscorresponding ; lecture ou l'écriture de la buffermay provoquer des erreurs et des données endommagées.

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 terminer 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 sont 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 n'est pas zéro-remplissage de données jusqu'à la longueur de données valides (VDL) qui est définie par SetFileValidData, cette fonction a des conséquences sur la 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, communications, etc.) ont un code cas spécial dans lequel, si une demande d'e/s peut être terminée "immédiatement", l'opération sera terminée et que 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 des mappages de fichiers. Le Gestionnaire de mémoire dans 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.

Cela fonctionne bien pour un petit nombre de requêtes, mais étant donné que le pool de threads est limité (actuellement trois sur un système 16 Mo), il seront toujours être uniquement quelques demandes en file d'attente 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 se trouve 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 optimisera 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 dans le CreateFile pour indiquer à le tooptimize de gestionnaire de cache son comportement pour un accès aléatoire.

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 réellement 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 entre les numéros par rapport à l'autre effet général d'éclaire 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 d'autres tâches ou émettre des demandes de 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é que 0.224264 secondes pour émettre les requêtes mêmes. Dans test 2, n'a aucun temps « extra » du programme à effectuer tout travail d'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 dans le 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 repose sur le type, la taille et le nombre d'opérations que votre programme effectue.

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 ne transforme pas d'e/s l'application asynchrones, il arrive idéal 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 du temps passé dans les theReadFile ou WriteFile fonction et en comparant cette fois comment le temps takesfor des opérations d'e/s réelles pour terminer est extrêmement utile. Si la majorityof que le temps passé en émettant effectivement de l'e/s, puis votre e/s est beingcompleted de façon synchrone. Toutefois, si le temps passé émettrice d'e/s requêtes isrelatively petit par rapport à la durée de la 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 de QueryPerformanceCounter pour effectuer le profilage d'owninternal.

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. Suivi des compteurs de performance pour le 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
Reportez-vous à la documentation de MSDN sur E/s synchrone et asynchrone Pour plus d'informations.

Kbdss de Asynczip ReadFile ReadFileEx WriteFile kbfile de WriteFileEx GetOverlappedResult asynchrone synchrone qui se chevauchent ne se superposent pas

Avertissement : Cet article a été traduit automatiquement.

Vlastnosti

ID článku: 156932 - Poslední kontrola: 10/04/2015 07:57:00 - Revize: 10.0

Microsoft Win32 Application Programming Interface

  • kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtfr
Váš názor