E/s de disco assíncrono é apresentado como sincronizado no Windows NT, Windows 2000 e Windows XP

A E/s de ficheiro no Microsoft Windows NT, Windows 2000 e Windows XP podem ser síncrona ou assíncrona. O comportamento predefinido para E/s é síncrono: uma função de E/s é chamada e devolve quando a E/s é concluída. E/s assíncrona, por outro lado, permite que uma função de E/s para voltar imediatamente execução ao autor da chamada, mas a E/s não é considerado completo quando alguns futuras. O sistema operativo notifica o autor da chamada quando a E/s está concluída. Em alternativa, o autor da chamada pode determinar o estado da operação de E/s pendente, utilizando os serviços do sistema operativo.

A vantagem de E/s assíncrona é que o autor da chamada tem tempo para executar qualquer outro trabalho ou emitem pedidos mais enquanto está a ser concluída a operação de E/s. O termo E/s sobreposta é frequentemente utilizado para E/s assíncrona e E/s sobreposto não para E/s síncrono. Este artigo utiliza os termos assíncrono e síncrono para operações de E/s no Windows NT. Este artigo pressupõe que o leitor tem determinada familiaridade com as funções de E/s de ficheiro, tais como CreateFile, ReadFile, WriteFile.

Frequentemente, operações de E/s assíncronas comportamento E/s apenas como síncronas. determinadas condições que este artigo aborda a disponibilizar secções posteriores que as operações de E/s concluir síncrona. O emissor não tem tempo para trabalhar no fundo porque as funções de E/s não devolvem até a E/s estar concluída.

Várias funções estão relacionados com E/s síncronas e assíncronas. Este artigo utiliza ReadFile e WriteFile como exemplos; alternativas boas seria ReadFileEx e WriteFileEx. Apesar deste artigo aborda apenas E/s do disco especificamente, muitos dos princípios podem ser aplicados a outros tipos de E/s, tal como E/s de série ou E/s de rede.

Nota : uma vez que o Windows 95 não suporta E/s assíncrona em dispositivos de disco (embora acontece noutros tipos de dispositivos de E/s), o comportamento não é descrito neste artigo.

Configurar E/s assíncrona

O sinalizador FILE_FLAG_OVERLAPPED deve ser especificado no CreateFile quando o ficheiro é aberto. Este sinalizador permite operações de E/s no ficheiro para ser executada de forma assíncrona. Eis um exemplo: ter cuidado quando a codificação de E/s assíncrona porque o sistema de reserva o direito de efectuar uma operação síncrona se necessitam. Por conseguinte, recomenda-se se escrever o programa processe correctamente uma operação de E/s que pode ser efectuada síncrona ou modo assíncrono. O código de exemplo demonstra esta consideração.

Existem muitas coisas que um programa pode enquanto as operações assíncronas concluir, tais como operações adicionais de Colocação de mensagens em fila, a aguardar ou tarefas em segundo plano. Por exemplo, o seguinte código processa correctamente sobreposta e não sobrepostas conclusão de uma operação de leitura. -Não faz nada mais do que esperar que a E/s pendentes concluir: nota que & NumberOfBytesRead transmitido para ReadFile é diferente da & NumberOfBytesTransferred transmitido para GetOverlappedResult. Se foi efectuada uma operação assíncrona, GetOverlappedResult é utilizado para determinar o número real de bytes transferidos na operação depois de ter concluído. A & NumberOfBytesRead transmitido para ReadFile é sem sentido.

Se, por outro lado, uma operação é concluída imediatamente, em seguida, & NumberOfBytesRead transmitido para ReadFile é válido para o número de bytes lidos. Neste caso, ignorar a estrutura OVERLAPPED transmitida para ReadFile, não utilize com GetOverlappedResult ou WaitForSingleObject.

Outro truque com operação assíncrona é que tem não utilizar uma estrutura OVERLAPPED até que a operação pendente tenha concluído. Por outras palavras, se tiver três operações de E/s pendentes, tem de utilizar três OVERLAPPED estruturas. Se reutilizar uma estrutura OVERLAPPED, receberá resultados imprevisíveis em operações de E/s e poderão ocorrer danos nos dados. Além disso, antes de poder utilizar uma estrutura OVERLAPPED pela primeira vez ou antes de reutilizar depois de concluída uma operação anterior, tem de correctamente inicializá-lo para que não existem dados através da esquerda afecta a operação de nova.

O mesmo tipo de restrição se aplica a memória intermédia de dados utilizada numa operação. Uma memória intermédia de dados não deve ser lidos ou escrita até que a operação de E/s correspondente foi concluída; leitura ou escrita a memória intermédia pode provocar erros e dados danificados.

Assíncrono E/s ainda parece ser síncrono

Se seguiu as instruções neste artigo, no entanto, todas as operações de E/s ainda normalmente concluir síncrona pela ordem emitido e nenhuma das operações ReadFile devolve FALSE com GetLastError() devolver ERROR_IO_PENDING, isto significa que tem não tempo para qualquer trabalho de fundo. Porque é que isto ocorre?

Existem várias razões por que razão operações de E/s concluir síncrona mesmo se ter codificado para operação assíncrona:

Compressão

Um obstáculo a operação assíncrona é a compressão NTFS. O controlador do sistema de ficheiros não acederá ficheiros comprimidos assincronamente; em vez disso, todas as operações são feitas síncronas. Não se aplica aos ficheiros que são comprimidos com utilitários semelhantes a COMPRIMIR ou PKZIP.

Encriptação de NTFS

Faz com semelhante à compressão, encriptação de ficheiros que o sistema controlador converter E/s assíncrona síncrono. Se os ficheiros são desencriptados, os pedidos de E/s serão assíncronos.

Expandir um ficheiro

Outra razão que operações de E/s são concluídas síncrona é operações próprios. No Windows NT, qualquer escrever a operação para um ficheiro que expande o respectivo comprimento será síncrona.

Nota : aplicações podem tornar a operação de escrita mencionados anteriormente assíncrona alterando o tamanho de dados válido do ficheiro utilizando a função SetFileValidData e, em seguida, emitir um WriteFile.

Utilizar SetFileValidData (que está disponível no Windows XP e versões posteriores), aplicações podem eficiente expandir ficheiros sem incorrer numa penalização de desempenho para preenchimento zero-los.

Uma vez que o sistema de ficheiros NTFS não zero - preencher os dados até o comprimento de dados válido (VDL, Valid Data LENGTH) definido pelo SetFileValidData, esta função tem implicações de segurança onde o ficheiro pode ser atribuído clusters que anteriormente foram ocupados por outros ficheiros. Por conseguinte, SetFileValidData requer que o autor da chamada tenha o novo SeManageVolumePrivilege activado (por predefinição, este é atribuído apenas para administradores). A Microsoft recomenda que os fabricantes independentes cuidadosamente as implicações de usar esta função.

Cache

A maior parte dos controladores de E/s (disco, comunicações e outros) têm código caso especial onde, se um pedido de E/s pode ser concluído "imediato", a operação vai ser concluída e a função ReadFile ou WriteFile devolverá VERDADEIRO. Todas as formas, estes tipos de operações parecem ser sincronizado. Para um dispositivo de disco, normalmente, um pedido de E/s pode ser concluído "imediatamente" quando os dados estiverem na memória em memória cache.

Dados não está na cache

O esquema de cache pode trabalhar contra, no entanto, se os dados não estiverem na cache. A cache do Windows NT é implementada utilizando internamente mapeamentos de ficheiros. O Gestor de memória no Windows NT não fornece um mecanismo de falhas de página assíncrona para gerir os mapeamentos de ficheiros utilizados pelo Gestor de cache. O Gestor de cache no entanto, pode verificar se a página pedida é na memória, para se emitir uma leitura assíncrona em cache e as páginas não estiverem na memória, o controlador do sistema de ficheiros assume que não pretender que o thread bloqueado e o pedido irá ser processado por um conjunto limitado de threads de trabalho. Controlo é devolvido ao programa após a chamada de ReadFile com a leitura pendente.

Isto funciona correctamente para um pequeno número de pedidos, mas uma vez que o conjunto de threads de trabalho é limitada (actualmente três num sistema 16 MB), existe serão ainda ser apenas alguns pedidos em fila para o controlador de disco num determinado momento. Se emitir muitas operações de E/s de dados que não estiverem na cache, o Gestor de cache e o Gestor de memória ficarem saturadas e os pedidos são efectuados síncronos.

O comportamento do Gestor de cache também pode ser influenciado baseia se acessar um arquivo sequencialmente ou aleatoriamente. Vantagens da cache de serem visualizadas mais ao aceder a ficheiros sequencialmente. O sinalizador FILE_FLAG_SEQUENTIAL_SCAN na chamada CreateFile irá optimizar a cache para este tipo de acesso. No entanto, se aceder a ficheiros em modo aleatório, utilize o sinalizador FILE_FLAG_RANDOM_ACCESS em CreateFile para instruir o Gestor de cache para optimizar o respectivo comportamento de acesso aleatório.

Não utilizar a cache

O sinalizador FILE_FLAG_NO_BUFFERING tem o efeito a maior parte no seu comportamento do sistema de ficheiros para operação assíncrona. Esta é a melhor forma de garantir que são realmente assíncronos pedidos de E/s. Indica o sistema de ficheiros não utilizar qualquer mecanismo de cache de todo.

aviso : existem algumas restrições à utilização deste sinalizador que têm de fazer com o alinhamento da memória intermédia de dados e tamanho do sector do dispositivo. Consulte a referência de função na documentação para a função CreateFile para mais informações sobre como utilizar este sinalizador correctamente.

EXEMPLO DE CÓDIGO

O ficheiro seguinte está disponível para transferência a partir do Centro de transferências da Microsoft:
Para obter informações adicionais sobre como transferir ficheiros de suporte da Microsoft, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Microsoft procedeu de vírus neste ficheiro. Microsoft utilizou o mais recente software de detecção de vírus que estava disponível na data em que o ficheiro foi publicado. O ficheiro é alojado em servidores com segurança avançada que o ajudam a impedir alterações não autorizadas ao ficheiro. O código de exemplo associado este artigo demonstra a utilização dos sinalizadores e funções discutidas. O código é executado como uma aplicação de consola no Windows NT. Os seguintes parâmetros de linha de comandos controlam o comportamento: Operação predefinida deste programa destina-se operação assíncrona, armazenada em buffer. Por predefinição, são solicitadas 500 operações de E/s.

Resultados do teste World real

Seguem-se alguns resultados do teste ao código de exemplo. A magnitude dos números não é importante aqui e varia de computador para computador, mas a relação entre os números comparados a si illuminates afectam geral dos sinalizadores de desempenho.

Pode esperar que ver resultados semelhantes à seguinte:

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

  este teste demonstra que o programa mencionado anteriormente emitido rapidamente pedidos de E/s de 500 e tinha muito tempo a executar qualquer outro trabalho ou emitir mais pedidos.
• Teste 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.
  						

  este teste demonstra este programa gasto 4.495880 segundos chamar ReadFile para concluir as respectivas operações, enquanto que o teste 1 gasto apenas 0.224264 segundos para emitir os pedidos do mesmos. No teste 2, ocorreu não "extra" hora para o programa efectuar qualquer trabalho de fundo.
• Teste 3

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

  este teste demonstra a natureza da cache de síncrona. Todas as leituras foram emitidas e foi concluídas em 0.251670 segundos. Por outras palavras, pedidos assíncronos foram concluídos síncrona. Este teste também demonstra o desempenho do Gestor de cache alto quando dados na cache.
• Teste 4

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

  este teste demonstra os mesmos resultados como no teste 3. Tenha em atenção que Leituras síncronas a partir da cache de concluir um pouco mais rapidamente do que Leituras assíncronas a partir da cache de. Este teste também demonstra o desempenho do Gestor de cache alto quando dados na cache.

CONCLUSÃO

Pode decidir qual o método é melhor uma vez que tudo depende do tipo, tamanho e número de operações que executa o programa.

O acesso de ficheiro predefinido sem especificar quaisquer sinalizadores especiais para CreateFile é uma operação síncrona e em cache.

Nota : É fazer algumas comportamento assíncrono automático neste modo porque o controlador do sistema de ficheiros é Preditiva assíncrona leitura antecipada e assíncrona a escrita de dados modificados. Apesar de este não efectua a aplicação [ASCII 146] s E/s assíncrona, é o caso ideal para a grande maioria das aplicações simples.

Se, por outro lado, a aplicação não é simples, poderá ter de efectuar alguns perfis e monitorização do desempenho para determinar o melhor método, semelhante aos testes ilustrados neste artigo. Criação de perfis o tempo gasto na função ReadFile ou WriteFile e, em seguida, comparar desta vez para quanto tempo demora para operações de E/s reais concluir é extremamente útil. Se a maioria das vezes é gasto em, na realidade, emitir a E/s, em seguida, a E/s está a ser concluída síncrona. No entanto, se o tempo gasto emissora pedidos de E/s é relativamente pequeno quando comparado com o tempo necessário para concluir, as operações de E/s, em seguida, as operações são a ser tratadas assincronamente. O código de exemplo mencionado anteriormente neste artigo utiliza a função QueryPerformanceCounter para fazer o seu próprio perfil interno.

A monitorização de desempenho pode ajudar a determinar como eficientemente o programa está a utilizar o disco e a cache. Controlo dos contadores de desempenho para o objecto de cache indicará o desempenho do Gestor de cache. Controlar os contadores de desempenho para os disco físico ou disco lógico objectos indicará o desempenho dos sistemas de disco.

Existem vários utilitários que são úteis na monitorização do desempenho; PerfMon e DiskPerf são particularmente úteis. Para o sistema recolher dados de desempenho de sistemas de disco, primeiro tem que emitir o comando de -y diskperf. Depois de emitir o comando, tem de reiniciar o sistema para iniciar a recolha de dados.

Para mais informações sobre estes utilitários e monitorização de desempenho, consulte o volume "optimizar o Windows NT" na documentação do Windows NT Resource Kit.

SQL Server requer sistemas para suportar ? garantida a entrega de multimédia estável ? conforme descrito no programa do Microsoft SQL Server Always-On armazenamento solução de revisão. FOPara obter mais informações sobre os requisitos de entrada e saídas para o motor de base de dados do SQL Server, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: