E/s de disco asincrónicas aparece como sincrónico en Windows NT, Windows 2000 y Windows XP

E/s de archivos en Microsoft Windows NT, Windows 2000 y Windows XP pueden ser sincrónica o asincrónica. El comportamiento predeterminado para la E/s es sincrónico: una función de E/s se denomina y se devuelve cuando finalice la E/s. E/s asincrónica, por otro lado, permite a una función de E/s al volver inmediatamente la ejecución al llamador, pero no se asume la E/s se completa hasta algunos momento futuro. El sistema operativo notifica al llamador cuando finalice la E/s. Como alternativa, el llamador puede determinar el estado de la operación de E/s pendiente utilizando los servicios del sistema operativo.

La ventaja de E/s asincrónica es que el llamador tiene tiempo para realizar otro trabajo o emitir más solicitudes mientras se completa la operación de E/s. El término E/s superpuesta se utiliza con frecuencia para E/s asíncrona y E/s superpuesto no para E/s sincrónica. Este artículo usa los términos asincrónico y sincrónico para operaciones de E/s en Windows NT. Este artículo se supone que el lector tiene cierta familiaridad con las funciones de E/s de archivos, tales como WriteFile CreateFile, ReadFile.

Con frecuencia, comportan operaciones asincrónicas de E/s sincrónica sólo como E/s. determinadas condiciones que este artículo se describe en la posterior creación de secciones que las operaciones de E/s sincrónicamente completan. El llamador no tiene ningún tiempo de trabajo de fondo porque no se devuelven las funciones de E/s hasta que finalice la E/s.

Varias funciones están relacionadas con E/s sincrónica y asincrónica. En este artículo utiliza ReadFile y WriteFile como ejemplos; serían buena alternativas ReadFileEx y WriteFileEx. Aunque en este artículo en concreto se describe sólo e/s, muchos de los principios se pueden aplicar a otros tipos de E/s, como serie de E/s o de E/s de red.

Nota : como Windows 95 no admite la E/s asincrónica en dispositivos de disco (aunque no en otros tipos de dispositivos de E/s), su comportamiento no se trata en este artículo.

Configurar la E/s asincrónica

La marca FILE_FLAG_OVERLAPPED debe especificarse en CreateFile cuando abre el archivo. Este indicador permite operaciones de E/s en el archivo para realizarse de forma asincrónica. Éste es un ejemplo: tenga cuidado al codificar para la E/s asincrónica porque el sistema reserva el derecho a realizar una operación sincrónica si es necesario. Por lo tanto, es mejor escribir el programa para tratar correctamente una operación de E/s puede completarse de forma sincrónica o asincrónica. El código de ejemplo muestra esta consideración.

Hay muchas cosas que un programa puede mientras espera para las operaciones asincrónicas completar como operaciones de colas adicionales, o el trabajo de fondo. Por ejemplo, el código siguiente controla correctamente finalizar superpuesto y no superpuesto una operación de lectura. No hace nada más que esperar la E/s pendientes completar: tenga en cuenta que NumberOfBytesRead pasada ReadFile es diferente de & NumberOfBytesTransferred pasó GetOverlappedResult. Si ha realizado una operación asincrónica, GetOverlappedResult se utiliza para determinar el número real de bytes que se transfieren en la operación después de que se ha completado. El & NumberOfBytesRead pasada ReadFile no tiene sentido.

Si, por otro lado, se completa una operación inmediatamente, a continuación, & pasó NumberOfBytesRead ReadFile es válido para el número de bytes leídos. En este caso, omitir la estructura OVERLAPPED pasada ReadFile; no lo utilice con GetOverlappedResult o WaitForSingleObject.

Otra advertencia con la operación asincrónica es que no se debe utilizar una estructura OVERLAPPED hasta que se ha completado su operación pendiente. En otras palabras, si tiene tres operaciones de E/s pendientes, debe utilizar tres estructuras OVERLAPPED. Si volver a utilizar una estructura OVERLAPPED, recibirá resultados impredecibles en las operaciones de E/s y puede experimentar daños en los datos. Además, antes de utilizar una estructura OVERLAPPED por primera vez, o antes de utilizarla una vez que ha terminado una operación anterior, debe correctamente inicializarlo por lo que no hay datos sobre izquierda afecta a la operación nueva.

El mismo tipo de restricción se aplica al búfer de datos utilizado en una operación. Un búfer de datos no se debe leer o escribir hasta que se ha completado su operación de E/s correspondiente; leer o escribir el búfer puede provocar errores y datos dañados.

Asincrónica E/s se parece ser sincrónico

Si ha seguido las instrucciones anteriores de este artículo, sin embargo, todas las operaciones de E/s todavía cotidianamente sincrónicamente en el orden emitido y ninguna de las operaciones ReadFile devuelve FALSE con GetLastError() devuelva ERROR_IO_PENDING, esto significa no que tener ningún tiempo para cualquier trabajo de fondo. ¿Por qué ocurre esto?

Hay una serie de razones por qué las operaciones de E/s sincrónicamente completarán incluso si ha codificado para operación asincrónica:

Compresión

Un obstáculo para la operación asincrónica es la compresión NTFS. El controlador de sistema de archivos no tendrán acceso a archivos comprimidos asincrónica; en su lugar todas las operaciones se realizan sólo sincrónicas. No se aplica a archivos que se comprimen con utilidades similares a COMPRESS o PKZIP.

Cifrado de NTFS

Similar a la compresión, cifrado de archivo hace que el controlador de sistema para convertir E/s asincrónica a sincrónico. Si los archivos se descifran, las solicitudes de E/s será asincrónicas.

Ampliación de un archivo

Otra razón que las operaciones de E/s se completan sincrónicamente es las operaciones a sí mismos. En Windows NT, cualquier escribir operación en un archivo que se extiende su longitud será sincrónica.

Nota : aplicaciones hacer la operación de escritura se ha mencionado anteriormente asincrónica, cambiar la longitud de datos válido del archivo mediante la función SetFileValidData y luego emita una WriteFile.

Mediante SetFileValidData (que está disponible en Windows XP y versiones posteriores), las aplicaciones pueden extender eficazmente los archivos sin incurrir en una penalización de rendimiento para rellenar cero ellos.

Porque el sistema de archivos NTFS no pone a cero: rellenar los datos hasta que la longitud de datos válidos (VDL) que se define mediante SetFileValidData, esta función tiene implicaciones de seguridad donde se puede asignar el archivo de clústeres que anteriormente se han ocupado por otros archivos. Por lo tanto, SetFileValidData requiere que el llamador tenga el nuevo SeManageVolumePrivilege habilitado (de forma predeterminada, esto se asigna únicamente a los administradores). Microsoft recomienda que los ISV considere detenidamente las implicaciones de utilizar esta función.

Caché

La mayoría de los controladores de E/s (disco, comunicaciones y otros) tienen código caso especial donde, si una solicitud de E/s puede completarse "inmediatamente", se puede completar la operación y la función ReadFile o WriteFile devolverá TRUE. De todas maneras, estos tipos de operaciones parecen ser sincrónico. Para un dispositivo de disco, normalmente, una solicitud de E/s se puede completar "inmediatamente" cuando los datos se almacena en memoria caché.

Datos no está en caché

La combinación de caché puede trabajar con, sin embargo, si los datos no están en la caché. La caché de Windows se implementa internamente mediante asignaciones de archivos. El Administrador de memoria en Windows NT no proporciona un mecanismo de errores de página asincrónica para administrar las asignaciones de archivo utilizadas por el Administrador de caché. El Administrador de caché sin embargo, puede comprobar si la página solicitada está en memoria, por lo que si emitir una lectura asincrónica en caché y las páginas no están en la memoria, el controlador de sistema de archivos supone que no desea que el subproceso bloqueado y se controlará la solicitud mediante un grupo limitado de subprocesos de trabajo. Control se devuelve al programa después de la llamada ReadFile con la lectura sigue pendiente.

Esto funciona bien para un pequeño número de solicitudes, pero porque el grupo de subprocesos de trabajo es limitado (actualmente tres en un sistema de 16 MB), hay se sigue pondrán en sólo unas solicitudes cola en el controlador de disco en un momento determinado. Si emite un muchas operaciones de E/s para datos que no están en la caché, el Administrador de caché y el Administrador de memoria se convierten en saturado y las solicitudes se realizan sincrónicas.

El comportamiento del Administrador de caché también se puede influir en función de si acceso a un archivo secuencialmente o aleatoriamente. Ventajas de la caché se ven más acceso a archivos secuencialmente. El indicador FILE_FLAG_SEQUENTIAL_SCAN en la llamada CreateFile optimizará la caché para este tipo de acceso. Sin embargo, si tener acceso a archivos de forma aleatoria, utilizar el indicador FILE_FLAG_RANDOM_ACCESS en CreateFile para indicar el Administrador de caché para optimizar su comportamiento para acceso aleatorio.

No utilizar la caché

El marcador FILE_FLAG_NO_BUFFERING tiene el efecto más en el comportamiento del sistema de archivos para operación asincrónica. Ésta es la mejor forma para garantizar que las solicitudes de E/s son realmente asincrónicas. Indica a no utilizar cualquier mecanismo de caché en absoluto el sistema de archivos.

Advertencia : hay algunas restricciones al uso de este indicador, que debe hacer con la alineación de búfer de datos y tamaño de sector del dispositivo. Consulte la referencia de función en la documentación de la función CreateFile para obtener más información sobre cómo utilizar este indicador correctamente.

CÓDIGO DE EJEMPLO

El archivo siguiente está disponible para descargarlo del Centro de descarga de Microsoft:
Para obtener información adicional acerca de cómo descargar los archivos de soporte técnico de Microsoft, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: Microsoft exploró este archivo en busca de virus. con el software de detección de virus más reciente disponible en la fecha de publicación. Asimismo, el archivo se almacenó en servidores seguros que ayudan a impedir la realización de cambios no autorizados. El código de ejemplo asociado con este artículo muestra el uso de los indicadores y funciones que se trata. El código se ejecuta como una aplicación de consola en Windows NT. Los siguientes modificadores de la línea de comandos controlan su comportamiento: Operación predeterminada de este programa es para la operación asincrónica, el búfer. De forma predeterminada, 500 operaciones de E/s se solicitan.

Real World Test Results

Siguientes son algunos resultados de prueba desde el código de ejemplo. La magnitud de los números no es importante aquí y varía de un equipo a otro, pero la relación de los números comparan entre sí ilumina el efecto general de los indicadores de rendimiento.

Puede esperar ver resultados similares al siguiente:

• Prueba 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.
  						

  esta prueba muestra que el programa se ha mencionado anteriormente emitió 500 solicitudes de E/s rápidamente y tenía un mucho tiempo para realizar otro trabajo o emitir más solicitudes.
• Prueba 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.
  						

  esta prueba muestra que este programa empleado 4.495880 segundos de llamar a ReadFile para completar sus operaciones, mientras que la prueba 1 dedicado sólo 0.224264 segundos para emitir las solicitudes mismas. En la prueba 2, no había ningún tiempo "extra" para el programa realizar cualquier trabajo de fondo.
• Prueba 3

  Asynchronous, buffered I/O: asynchio /f*.dat
  
     Operations completed in the order issued.
     500 requests issued and completed in 0.251670 seconds.
  						

  esta prueba muestra la naturaleza sincrónica de la caché. Todas las lecturas se han emitido y completar en 0.251670 segundos. En otras palabras, las solicitudes asincrónicas se completaron sincrónicamente. Esta prueba también muestra el alto rendimiento del Administrador de caché cuando los datos en la caché.
• Probar 4

  Synchronous, buffered I/O: asynchio /f*.dat /s
  
     Operations completed in the order issued.
     500 requests and completed in 0.217011 seconds.
  						

  esta prueba muestra los mismos resultados como en la prueba 3. Tenga en cuenta que Lecturas sincrónicas de la caché de completan un poco más rápido que las lecturas asincrónicas de la caché. Esta prueba también muestra el alto rendimiento del Administrador de caché cuando los datos en la caché.

CONCLUSIÓN

Puede decidir qué método es mejor porque todo depende del tipo, tamaño y número de operaciones que realiza el programa.

El acceso de archivo predeterminado sin especificar los indicadores especiales a CreateFile es una operación sincrónica y en caché.

Nota : ¿obtener algún comportamiento asincrónico automática en este modo porque el controlador de sistema de archivos no predicción asincrónica lectura anticipada y asincrónica lenta escritura de datos modificados. Aunque esto no realiza la s de la aplicación [ASCII 146] E/s asincrónica, es el caso ideal para la mayoría de las aplicaciones sencillas.

Si, por otro lado, la aplicación no es sencilla, quizás tenga que hacer algunos perfiles y la supervisión del rendimiento para determinar el mejor método, similar a las pruebas que se muestra anteriormente en este artículo. Generación de perfiles el tiempo empleado en la función ReadFile o WriteFile y a continuación, comparar cuánto tarda las operaciones de E/s reales completar esta vez es extremadamente útil. Si se dedica la mayor parte del tiempo en realidad emite la E/s, la E/s se está completando sincrónicamente. Sin embargo, si la CA las solicitudes de E/s de tiempo es relativamente pequeño en comparación con el tiempo necesario para que las operaciones de E/s completar, a continuación, las operaciones se se tratan de forma asincrónica. El código de ejemplo mencionado anteriormente en este artículo utiliza la función QueryPerformanceCounter para realizar sus propios perfiles interno.

Supervisión del rendimiento puede ayudar a determinar la eficacia con su programa está utilizando el disco y la caché. Seguimiento de cualquiera de los contadores de rendimiento para el objeto de caché indicará el rendimiento del Administrador de caché. Seguimiento de los contadores de rendimiento de los objetos de disco físico o disco lógico indicará el rendimiento de los sistemas de disco.

Existen varias utilidades que son útiles para supervisar el rendimiento; PerfMon y DiskPerf son especialmente útiles. Para que el sistema recopilar datos en el rendimiento de los sistemas de disco, primero debe emitir el comando de diskperf -y. Después de emitir el comando, debe reiniciar el sistema para iniciar la recopilación de datos.

Para obtener más información acerca de estas utilidades y la supervisión del rendimiento, consulte el volumen "Optimizing Windows NT" en la documentación del Kit de recursos de Windows NT.