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

Traduções deste artigo Traduções deste artigo
ID do artigo: 156932 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

E/s de arquivo no Microsoft Windows NT, Windows 2000 e Windows XP pode ser síncrono ou assíncrono. O comportamento padrão de i/o é síncrono: uma função de e/s é chamada e retorna quando a e/s for concluída. E/s assíncrona, por outro lado, permite que uma função de e/s retornar a execução de volta para o chamador imediatamente, mas a i / o não será usada para ser concluída até o futuro. O sistema operacional notifica o chamador quando a e/s for concluída. Como alternativa, o chamador pode determinar o status da operação de e/s pendente usando os serviços do sistema operacional.

A vantagem de e/s assíncrona é que o chamador tem tempo para fazer outros de trabalho ou emitir solicitações mais enquanto a operação é concluída. O termo Overlapped i/o é freqüentemente usado para e/s assíncrona e não-sobrepostas I/o de e/s síncrona. Este artigo usa os termos assíncrono e Síncrono para operações de e/s em Windows NT. Este artigo pressupõe que o leitor tem certa familiaridade com as funções de e/s de arquivo como CreateFile, ReadFile, WriteFile.

Com freqüência, operações de e/s assíncronas se comportam exatamente como síncrono e/s. alguns condições descritas nesse artigo nas seções posteriores fazer i / o operações concluído de forma síncrona. O chamador tem nenhum período para plano de fundo funciona porque as funções de e/s não retorna até que a e/s for concluída.

Várias funções relacionadas a e/s síncrona e assíncrona. Este artigo usa ReadFile e WriteFile como exemplos; boas alternativas seria ReadFileEx e WriteFileEx. Embora este artigo aborda especificamente o disco e/s, muitos dos princípios podem ser aplicados a outros tipos de e/s, como e/s serial ou e/s de rede.

Observação: como o Windows 95 não oferece suporte e/s assíncrona em dispositivos de disco (embora ele faz em outros tipos de dispositivos de i/o), seu comportamento não é abordado neste artigo.

Mais Informações

Configurar e/s assíncrona

O sinalizador FILE_FLAG_OVERLAPPED deve ser especificado em CreateFile quando o arquivo é aberto. Esse sinalizador permite que operações de e/s no arquivo para ser executado de forma assíncrona. Aqui está um exemplo:
   HANDLE hFile;

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

   if (hFile == INVALID_HANDLE_VALUE)
      ErrorOpeningFile();
				
Tenha cuidado ao codificar para e/s assíncrona porque o sistema de reserva de direito de fazer uma operação síncrona se precisar. Portanto, é melhor escrever o programa para tratar corretamente uma operação de i/o que pode ser concluída de forma síncrona ou assíncrona. O exemplo de código demonstra essa consideração.

Há muitas coisas que um programa pode enquanto aguardando assíncrona a conclusão, como operações adicionais de enfileiramento de mensagens ou fazendo das operações trabalho de plano de fundo. Por exemplo, o código a seguir manipula corretamente sobrepostos e não sobrepostos a conclusão de uma operação de leitura. Ele faz nada mais de espera de e/s pendentes concluir:
   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);
				
Observe que & NumberOfBytesRead passado para ReadFile é diferente de & NumberOfBytesTransferred passado para GetOverlappedResult. Se uma operação foi feita assíncrono, e em seguida, GetOverlappedResult é usado para determinar o número real de bytes transferidos na operação após ele ter concluída. O & NumberOfBytesRead passado para ReadFile não faz sentido.

Se, por outro lado, a operação é concluída imediatamente, em seguida & NumberOfBytesRead passado para ReadFile é válido para o número de bytes lidos. Nesse caso, ignore a estrutura OVERLAPPED passada para ReadFile; não usá-lo com GetOverlappedResult ou WaitForSingleObject.

Outra limitação com a operação assíncrona é que você não deve usar uma estrutura OVERLAPPED até que sua operação pendente seja concluída. Em outros palavras, se você tiver três operações de e/s pendentes, você deve usar três estruturas OVERLAPPED. Se você reutilizar uma estrutura OVERLAPPED, você receberá resultados imprevisíveis nas operações de e/s e você pode enfrentar corrupção de dados. Além disso, antes de usar uma estrutura OVERLAPPED pela primeira vez, ou antes de reutilizá-lo depois de uma operação anterior foi concluída, você deve corretamente inicializá-lo para que nenhum dado sobre esquerda afeta a operação de nova.

O mesmo tipo de restrição se aplica para o buffer de dados usado em uma operação. Um buffer de dados não deve ser lidos ou gravado até sua operação de e/s correspondente foi concluída; ler ou gravar o buffer pode causar erros e dados corrompidos.

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

Se você seguiu as instruções neste artigo, no entanto, todas as operações de i/o ainda normalmente concluído de forma síncrona na ordem emitida e nenhuma das operações ReadFile retorna FALSE com GetLastError () retornar ERROR_IO_PENDING, isso significa que não tenha qualquer trabalho de plano de fundo. Por que isso ocorre?

Há várias razões por que as operações de e/s concluído de forma síncrona mesmo que você codificou para operação assíncrona:

Compactação

Uma obstruções operação assíncrona é a compactação NTFS. O arquivo. driver do sistema não irá acessar os arquivos compactados assíncrona. em vez disso, todos os as operações são apenas feitas síncronas. Isso não se aplica aos arquivos que estão compactado com utilitários semelhantes para COMPACTAR ou PKZIP.

Criptografia NTFS

Semelhante à compactação, criptografia de arquivos faz o driver de sistema converter síncrono e/s assíncrona. Se os arquivos são descriptografados, as solicitações de i/o será assíncronas.

Extensão de um arquivo

Outro motivo que operações de e/s são concluídas síncrona é as operações em si. No Windows NT, qualquer gravação operação para um arquivo que estende seu comprimento será síncrona.

Observação: os aplicativos podem fazer uma operação de gravação mencionado anteriormente assíncrona alterando o tamanho de dados válido do arquivo usando a função SetFileValidData e, em seguida, emitir um WriteFile.

Usando o SetFileValidData (que está disponível no Windows XP e versões posteriores), aplicativos podem eficientemente estender arquivos sem incorrer em uma penalidade de desempenho para o preenchimento de zero-los.

Porque o sistema de arquivos NTFS não os dados até o comprimento de dados válidos (VDL) que é definido por SetFileValidData de preenchimento de zero, essa função tem implicações de segurança onde o arquivo pode ser atribuído clusters que anteriormente estavam ocupados por outros arquivos. Portanto, o SetFileValidData requer que o chamador tem o novo SeManageVolumePrivilege ativada (por padrão, isso é atribuído somente a administradores). A Microsoft recomenda que os ISVs consideram cuidadosamente as implicações de usar essa função.

Cache

A maioria dos drivers de e/s (disco, comunicações e outros) têm código caso especial em que, se uma solicitação de e/s pode ser concluída "imediatamente", a operação será concluída e a função ReadFile ou WriteFile retornará verdadeiro. Em todos os sentidos, esses tipos de operações parecem ser síncrono. Para um disco dispositivo, normalmente, uma solicitação de e/s pode ser concluída "logo" quando os dados são armazenados na memória.

Dados não estão em Cache

O esquema de cache pode trabalhar contra você, no entanto, se os dados não estão na cache. O cache do Windows NT é implementado internamente usando mapeamentos de arquivo. O Gerenciador de memória no Windows NT não oferece uma página assíncrona mecanismo de falha para gerenciar os mapeamentos de arquivo usados pelo Gerenciador de cache. O Gerenciador de cache pode, entretanto, verificar se a página solicitada está na memória, portanto, se você emitir uma leitura assíncrona de cache e as páginas não estão na memória, o driver de sistema de arquivos pressupõe que você não deseja que o thread bloqueado e a solicitação será tratada por um conjunto limitado de segmentos de trabalho. Controle é retornado ao seu programa após a sua chamada ReadFile com a leitura ainda pendente.

Isso funciona bem para um pequeno número de solicitações, mas porque o pool de threads de trabalho é limitada (atualmente três em um sistema de 16MB), há serão ainda ser apenas algumas solicitações enfileiradas para o driver de disco em um determinado momento. Se você executar muitas operações de e/s para dados que não estão no cache, o Gerenciador de cache e o Gerenciador de memória se tornam saturados e suas solicitações são feitas síncronas.

O comportamento do Gerenciador de cache também pode ser influenciado com base no Você pode acessar um arquivo seqüencialmente ou aleatoriamente. Benefícios do cache são vistos maioria ao acessar arquivos seqüencialmente. O sinalizador FILE_FLAG_SEQUENTIAL_SCAN no CreateFile chamada otimizará o cache para esse tipo de acesso. No entanto, se você acessar os arquivos de modo aleatório, use o Sinalizador FILE_FLAG_RANDOM_ACCESS em CreateFile para instruir o Gerenciador de cache Otimize seu comportamento para acesso aleatório.

Não Use o Cache

O sinalizador FILE_FLAG_NO_BUFFERING tem mais efeito sobre o comportamento da sistema de arquivos para operação assíncrona. Esta é a melhor maneira de garantir que são, na verdade, assíncronas, solicitações de i/o. Ele instrui o sistema de arquivos não use qualquer cache mecanismo todo.

Aviso: há algumas restrições para usar esse sinalizador que tem a ver com o alinhamento do buffer de dados e tamanho de setor do dispositivo. Consulte a referência de função na documentação para a função CreateFile para obter mais informações sobre como usar esse sinalizador corretamente.

Resultados de teste do mundo real

A seguir estão alguns resultados de teste do código de exemplo. A magnitude da números aqui não é importante e varia de computador para computador, mas a relação dos números em relação uns aos outros ilumina o efeito geral dos sinalizadores no desempenho.

Você pode esperar 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 emitidos 500 solicitações de e/s rapidamente e tinha muito tempo para fazer outro trabalho ou emitir solicitações de mais.
  • 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 que este programa gasto 4.495880 segundos chamada ReadFile para concluir suas operações, ao passo que o teste 1 gasto apenas 0.224264 segundos para emitir as solicitações do mesmas. No teste 2, não havia nenhum tempo "extra" para o programa de qualquer plano de fundo trabalho.
  • 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 síncrona do cache. Todas as leituras foram emitidos e concluída em 0.251670 segundos. Em outras palavras, solicitações assíncronas foram concluídas de forma síncrona. Esse teste também Demonstra o alto desempenho do Gerenciador de cache quando os dados estão em o 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 que teste 3. Observe que síncrona leituras do cache um pouco mais rápido do que as Leituras assíncronas concluídas do cache. Esse teste também demonstra o alto desempenho do Gerenciador de cache quando os dados estão no cache.

CONCLUSÃO

Você pode decidir qual método é melhor, porque tudo depende do tipo, tamanho e número de operações que executa o programa.

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

Observação: você tem algum comportamento assíncrono automático neste modo porque o driver de sistema de arquivos faz a previsão assíncrona read-ahead e assíncrona gravação lenta de dados modificados. Embora isso não faz o aplicativo [ASCII 146] s e/s assíncrona, é o caso ideal para a maioria dos aplicativos simples.

Se, por outro lado, o aplicativo não é simple, você precisa fazer alguns perfis e monitoramento do desempenho para determinar o melhor método, como os testes ilustrados neste artigo. Perfil o tempo gasto na Função ReadFile ou WriteFile e, em seguida, comparando neste momento como longa demora para operações de e/s reais concluir são extremamente útil. Se a maioria o tempo é gasto na emissão, na verdade, o i / o, e em seguida, o i/o está sendo concluído de forma síncrona. No entanto, se o tempo gasto na emissão de solicitações de i/o é relativamente pequeno comparado com o tempo leva para as operações de i/o para completa, em seguida, as operações são sendo tratadas assincronamente. O exemplo código mencionado anteriormente neste artigo usa a função de QueryPerformanceCounter para fazer o seu próprio Definindo o perfil interno.

Monitoramento de desempenho pode ajudar a determinar a eficiência com o seu programa é usando o disco e o cache. Rastreamento de qualquer um dos contadores de desempenho para o objeto do Cache indicará o desempenho do Gerenciador de cache. Controlar os contadores de desempenho para o disco físico ou lógico de disco objetos indicará o desempenho dos sistemas de disco.

Existem vários utilitários que são úteis no monitoramento de desempenho; PerfMon e DiskPerf são especialmente úteis. Para o sistema coletar dados sobre o desempenho dos sistemas de disco, execute o comando -y diskperf. Depois de executar o comando, você deve reiniciar o sistema para iniciar a coleta de dados.

Referências

Para obter mais informações sobre esses utilitários e o monitoramento de desempenho, consulte o volume "otimização do Windows NT" no recurso do Windows NT Documentação do Kit.
SQL Server requer sistemas para dar suporte a 'entrega garantida para mídias estáveis' conforme descrito no programa de análise de solução de armazenamento do Microsoft SQL Server Always-On. FOPara obter mais informações sobre os requisitos de entrada e saídas para o mecanismo de banco de dados do SQL Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
967576Requisitos de entrada/saída de mecanismo de banco de dados do Microsoft SQL Server

Propriedades

ID do artigo: 156932 - Última revisão: quinta-feira, 30 de maio de 2013 - Revisão: 6.0
A informação contida neste artigo aplica-se a:
  • Interface de Programação de Aplicativos do Microsoft Win32
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Palavras-chave: 
kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.
Clique aqui para ver a versão em Inglês deste artigo: 156932

Submeter comentários

 

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