Você está offline; aguardando reconexão
Entrar

Não há suporte para seu navegador

Você precisa atualizar seu navegador para usar o site.

Atualize para a versão mais recente do Internet Explorer

E/s de disco assíncrono aparece como síncrono no Windows

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
Sumário
E/s de arquivo no Microsoft Windows pode ser síncrono ou assíncrono. O comportamento padrão para i/o é sincronizado, onde é chamada de uma função de i/o e retorna quando a e/s for concluída. E/s assíncrona permite que uma função de e/s retornar imediatamente a execução volta para o chamador, mas o i/o não é assumido como sendo concluída até algum momento 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 através dos serviços do sistema operacional.

A vantagem de e/s assíncrona é que o chamador tem tempo para fazer outro trabalho ou emitir solicitações mais enquanto a operação é concluída. O termo Overlapped I / Ois usados com freqüência para e/s assíncrona e e/s sobreposto não para e/s síncrona. Este artigo usa os termos assíncrono e síncrono para operações de e/s. Este artigo presume que o leitor tenha familiaridade com as funções de e/s de arquivo, como o CreateFile, ReadFile, WriteFile.

Com freqüência, operações de e/s assíncronas se comportam exatamente como síncrono e/s. determinadas condições descritas nesse artigo tornar seções posterior, que as operações de i/o é concluído de forma síncrona. O chamador tem não há tempo para o trabalho de plano de fundo 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íncronas e assíncronas. Este artigo usa ReadFile e WriteFile como exemplos; boas alternativas seria ReadFileEx e WriteFileEx. Embora este artigo aborda especificamente o disco i/o, muitos dos princípios podem ser aplicados a outros tipos de e/s, como e/s serial ou e/s de rede.
Mais Informações

Configurar a e/s assíncrona

O sinalizador FILE_FLAG_OVERLAPPED deve ser especificado em CreateFile quando o arquivo for aberto. Esse sinalizador permite que operações de e/s no arquivo para ser executado de forma assíncrona. Eis 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 quando codificando para e/s assíncrona porque o sistema reserva asinformações certas para fazer uma operação síncrona caso seja necessário. Portanto, é melhor escrever o programa para tratar corretamente uma operação de e/s 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 aguarda para asynchronousoperations a conclusão, como operações adicionais de enfileiramento de mensagens ou trabalho de doingbackground. Por exemplo, o seguinte código corretamente handlesoverlapped e elas não se a conclusão de uma operação de leitura. Ele doesnothing mais de esperar por 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 do & NumberOfBytesTransferred passado no GetOverlappedResult. Se um operationhas foi feita assíncrona, em seguida, GetOverlappedResult é usado para determinethe o número real de bytes transferidos na operação depois que ele hascompleted. 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 o utilize com GetOverlappedResult ou WaitForSingleObject.

Outra limitação com operação assíncrona é que você não deve usar uma estrutura OVERLAPPED até que sua operação pendente seja concluída. Em outras 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, para que você possa usar uma estrutura OVERLAPPED pela primeira vez ou antes de reutilizá-la depois de uma operação anterior foi concluída, você deve corretamente inicializá-lo para que nenhum dado restante afeta a nova operação.

O mesmo tipo de restrição se aplica para o buffer de dados usado em anoperation. Um buffer de dados não deve ser lidos ou gravado até que tenha concluído a operação de e/s do itscorresponding; ler ou gravar o buffermay 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 há tempo para qualquer trabalho de plano de fundo. Por que isso ocorre?

Há várias razões por que as operações de e/s concluir synchronouslyeven se você codificou para operação assíncrona:

Compactação

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

Criptografia NTFS

Semelhante à compactação, criptografia de arquivo faz com que o driver do sistema converter e/s assíncrono para síncrono. 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 propriamente ditos. No Windows NT, qualquer gravação operação em um arquivo que estende seu comprimento será síncrona.

Nota: aplicativos podem fazer uma operação de gravação mencionado anteriormente assíncrona alterando o comprimento 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 eficiente estender arquivos sem incorrer em uma penalidade de desempenho para preenchimento de zero-los.

Porque o sistema de arquivos NTFS não zero-preenchimento os dados até o comprimento de dados válido (VDL) que é definido pelo SetFileValidData, essa função tem implicações de segurança em que o arquivo pode ser atribuído clusters que foram anteriormente ocupados por outros arquivos. Portanto, o SetFileValidData requer que o chamador possua o novo SeManageVolumePrivilege habilitado (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) tem código de 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á TRUE. Em todos os sentidos, esses tipos de operações parecem ser síncronas. Para diskdevice, em geral, uma solicitação de e/s pode ser concluída "imediatamente" quando os dados são armazenados em cache na memória.

Dados não estiverem no Cache

O esquema de cache pode trabalhar contra você, no entanto, se os dados não são thecache. O cache do Windows NT é implementado internamente usando mapeamentos de arquivo. O Gerenciador de memória do Windows NT não fornece um mecanismo assíncrono pagefault para gerenciar os mapeamentos de arquivo usados pelo Gerenciador de cache. Gerenciador de Thecache pode, no entanto, 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 estiverem na memória, o driver de sistema de arquivos pressupõe que você não deseja que o segmento bloqueado e a solicitação será tratada por um conjunto limitado de segmentos de trabalho. Controle é retornado ao seu programa após 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 é limitado (atualmente três em um sistema de 16MB), há serão ainda apenas algumas solicitações enfileiradas para o driver de disco em um momento específico. Se você executar muitas operações de e/s para dados que não estejam no cache, o Gerenciador de cache e o Gerenciador de memória se tornar saturados e as solicitações são feitas síncronas.

O comportamento do Gerenciador de cache também pode ser influenciado baseado em acesso de whetheryou um arquivo seqüencialmente ou aleatoriamente. Benefícios do cache são seenmost ao acessar arquivos seqüencialmente. O flagin FILE_FLAG_SEQUENTIAL_SCAN a chamada de CreateFile otimizar o cache para esse tipo de acesso. No entanto, se você acessar arquivos de maneira aleatória, use sinalizador theFILE_FLAG_RANDOM_ACCESS em CreateFile para instruir o seu comportamento para acesso aleatório a tooptimize do Gerenciador de cache.

Não usar o Cache

O sinalizador FILE_FLAG_NO_BUFFERING tem o efeito mais o comportamento do sistema aCaixa de operação assíncrona. Esta é a melhor maneira de guaranteethat que as solicitações de e/s são realmente assíncronas. Ele instrui o arquivo de sistema não usar qualquer mecanismo de cache do todo.

Aviso: há algumas restrições ao uso esse sinalizador que tem a ver com o alinhamento do buffer de dados e o tamanho do 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 do teste do mundo real

A seguir estão alguns resultados de teste de código de exemplo. A magnitude da thenumbers aqui não é importante e varia de um computador para outro, mas a relação dos números em relação uns aos outros ilumina thegeneral afetam os 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.						
    Esse 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 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.						
    Esse teste demonstra este programa gasto 4.495880 segundos chamando ReadFile para completar suas operações, enquanto 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 que fazer qualquer trabalho de plano 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 síncrona do cache. Todas as leituras foram emitidas e concluídas 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 no 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.						
    Esse teste demonstra os mesmos resultados teste 3. Observe que Leituras síncronas do cache conclua um pouco mais rápido do que as Leituras assíncronas 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 o tipo, o tamanho e o número de operações que executa o programa.

O acesso a arquivos padrão sem especificar quaisquer sinalizadores especiais para CreateFileis uma operação síncrona e armazenados em cache.

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

Se, por outro lado, o aplicativo não for simple, você terá que dosome de criação de perfil e monitoração de desempenho para determinar o melhor método, como os testes ilustrados neste artigo. Perfil o tempo gasto em theReadFile ou função WriteFile e, em seguida, comparando neste momento como longo takesfor as operações de i/o reais para concluir é extremamente útil. Se o majorityof que o tempo é gasto na emissão, na verdade, o i/o e a e/s for beingcompleted sincronicamente. No entanto, se o tempo gasto emissão e/s solicitações isrelatively pequeno em comparação com o tempo que leva para o tocomplete de operações de e/s, as operações são sejam tratadas de forma assíncrona. O samplecode mencionada anteriormente neste artigo usa a função QueryPerformanceCounter fazer sua owninternal de criação de perfil.

Monitoramento de desempenho pode ajudar a determinar quão eficientemente seu programa isusing o disco e o cache. Qualquer um dos contadores de desempenho para o objeto de Cache de controle indicará o desempenho do Gerenciador de cache. Controlando os contadores de desempenho de disco físico ou lógico Diskobjects indicará o desempenho dos sistemas de disco.

Existem vários utilitários que são úteis para monitoramento de desempenho; PerfMon e DiskPerf são especialmente úteis. Para o sistema coletar dados sobre o desempenho dos sistemas de disco, primeiro você deve emitir o comando do diskperf -y. Depois que você executar o comando, você deve reiniciar o sistema para iniciar a coleta de dados.
Referências
Consulte a documentação do MSDN sobre E/s síncrona e assíncrona Para obter informações adicionais.

Kbdss Asynczip ReadFile ReadFileEx WriteFile arquivo WriteFileEx GetOverlappedResult assíncrono síncrono sobrepostas não sobrepostas

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 156932 - Última Revisão: 06/27/2015 02:21:00 - Revisão: 7.0

  • Interface de Programação de Aplicativos do Microsoft Win32
  • kbapi kbfileio kbinfo kbkernbase kbmt KB156932 KbMtpt
Comentários
mp;t=">>ml> "//c.microsoft.com/ms.js'><\/script>");