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

Traduções de Artigos Traduções de Artigos
Artigo: 156932 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

E/s de ficheiro no Microsoft Windows NT, Windows 2000 e Windows XP podem ser síncrona ou assíncrona. O comportamento predefinido de e/s é síncrono: uma função de e/s é chamada e devolve quando a e/s está concluída. E/s assíncrona, por outro lado, permite uma função de e/s voltar imediatamente execução ao autor da chamada, mas a e/s não é assumido como sendo concluído até algum tempo de futuro. 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 efectuar outros trabalhar ou emitir pedidos de mais, enquanto a operação de e/s está a ser concluída. O o termo e/s de sobreposta é frequentemente utilizado para e/s assíncrona e não-sobrepostas E/s e/s síncronas. Este artigo utiliza os termos assíncrono e Síncrono para operações de e/s no Windows NT. Este artigo pressupõe a leitor tem determinada familiaridade com as funções de e/s de ficheiro como CreateFile, ReadFile, WriteFile.

Frequentemente, operações de e/s assíncronas funcionam tal como síncronas e/s. determinadas condições a que este artigo aborda nas secções posteriores tornar a e/s operações concluídas de forma síncrona. O autor da chamada não tem tempo para o fundo funciona porque as funções de e/s não regressa até que a e/s está 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; boas alternativas seria ReadFileEx e WriteFileEx. Apesar deste artigo aborda apenas o disco e/s especificamente, muitos dos princípios podem ser aplicados a outros tipos de e/s, por exemplo, e/s série ou de e/s de rede.

Nota: uma vez que o Windows 95 não suporta e/s assíncrona em dispositivos de disco (embora faz noutros tipos de dispositivos e/s), este artigo não abrange o respectivo comportamento.

Mais Informação

Configurar e/s assíncrona

Deve ser especificado o sinalizador FILE_FLAG_OVERLAPPED em CreateFile quando o ficheiro é aberto. Este sinalizador permite operações de e/s no ficheiro para ser efectuada de modo assíncrono. 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 a codificação de e/s assíncrona porque o sistema de reserva a direito de efectuar uma operação síncrona se necessitam. Por conseguinte, é melhor escrever o programa para processar correctamente uma operação de e/s que pode ser preenchida de forma síncrona ou assíncrona. O código de exemplo demonstra esta consideração.

Existem muitas coisas que um programa pode fazer ao aguardar assíncrona operações concluírem, tal como a colocação em fila operações adicionais ou a fazer trabalho de fundo. Por exemplo, o seguinte código processa correctamente conclusão de uma operação de leitura sobreposta e não sobrepostas. Faz nada mais do que esperar a e/s pendentes concluir a:
   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);
				
Tenha em atenção que & o NumberOfBytesRead transmitido para ReadFile é diferente de & NumberOfBytesTransferred transmitido para GetOverlappedResult. Se uma operação foi efectuada assíncrona, em seguida, GetOverlappedResult é utilizado para determinar o número real de bytes transferidos na operação após concluída. O & NumberOfBytesRead transmitido para ReadFile não faz sentido.

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

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

O mesmo tipo de restrição aplica-se para a memória intermédia de dados utilizada numa operação. Uma memória intermédia de dados não pode ser lidos ou escrita até sua Concluiu-se a operação de e/s correspondente; ler ou escrever a memória intermédia pode causar erros e dados danificados.

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

Se tiver seguido as instruções neste artigo, no entanto, todas as operações de e/s ainda normalmente concluir sincronamente pela ordem emitida e nenhuma das operações ReadFile devolve FALSE com GetLastError () ERROR_IO_PENDING a devolver, isto significa que não o tempo para qualquer trabalho de fundo. Por que razão esta ocorrer?

Existem várias razões porque é que as operações de e/s concluídas síncrona mesmo que tenham codificadas para operação assíncrona:

Compressão

Uma obstrução para operação assíncrona é a compressão NTFS. O ficheiro. controlador de sistema não acederá ficheiros comprimidos de modo assíncrono; em vez disso, todos os operações são apenas efectuadas síncronas. Isto não se aplica aos ficheiros existentes comprimido com utilitários semelhantes ao COMPRIMIR ou PKZIP.

Encriptação de NTFS

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

Expandir um ficheiro

Outra razão que as operações de e/s são concluídas sincronamente é as operações de si. No Windows NT, escrever qualquer operação para um ficheiro que expande o seu comprimento será síncrona.

Nota: as aplicações podem efectuar a operação de escrita mencionada anteriormente assíncrona alterando o comprimento de dados válido do ficheiro utilizando a função de SetFileValidData e, em seguida, emitindo 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 o enchimento zero-los.

Uma vez que o sistema de ficheiros NTFS não preenchimento de zero os dados até o comprimento de dados válido (VDL) é definido pelo SetFileValidData, esta função tem implicações de segurança onde o ficheiro pode ser atribuído conjuntos de sectores que foram anteriormente ocupados por outros ficheiros. Por conseguinte, o SetFileValidData requer que o emissor tenha o novo SeManageVolumePrivilege activado (por predefinição, este é atribuído apenas para os administradores). A Microsoft recomenda que os ISVs consideram cuidadosamente as implicações da utilização desta função.

Cache

A maioria dos controladores de e/s (disco, comunicações e outros) têm código caso especial, sempre que, se um pedido de e/s pode ser concluído "imediatamente", será possível concluir a operação e a função ReadFile ou WriteFile irá devolver TRUE. De todas as formas, estes tipos de operações parecem ser sincronizado. Para um disco dispositivo, normalmente, um pedido de e/s pode ser concluído "imediatamente" quando os dados são colocadas em cache na memória.

Dados não estão na Cache

O esquema de cache pode trabalhar contra si, 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 uma página assíncrona mecanismo de falhas para gerir os mapeamentos de ficheiros utilizados pelo gestor da cache. O Gestor da cache pode, no entanto, verificar se a página pedida está na memória, para que se emitir uma leitura assíncrona em cache e as páginas não estiverem na memória, o controlador de sistema de ficheiros assume que não pretende que o thread bloqueado e o pedido será processado por um conjunto limitado de threads de trabalho. O controlo é devolvido ao programa após a chamada de ReadFile com leitura ainda pendentes.

Isto funciona correctamente para um pequeno número de pedidos, mas porque o agrupamento de threads de trabalho é limitada (actualmente três num sistema 16MB), não existem serão ainda ser apenas alguns pedidos na fila para o controlador de disco num determinado momento. Se introduzir uma grande quantidade de operações de e/s para os dados que não está na cache, o Gestor da cache e o Gestor de memória ficam saturadas e são efectuados os pedidos de síncronos.

Também pode ser influenciado o comportamento do Gestor da cache com base no aceder a um ficheiro sequencialmente ou aleatoriamente. Benefícios da cache são vistos a maior parte quando aceder a ficheiros sequencialmente. O sinalizador FILE_FLAG_SEQUENTIAL_SCAN no CreateFile chamada irá optimizar a cache para este tipo de acesso. No entanto, se aceder a ficheiros de modo aleatório, utilizar o Sinalizador FILE_FLAG_RANDOM_ACCESS em CreateFile para instruir o Gestor de cache Optimize o respectivo comportamento de acesso aleatório.

Não utilize a Cache

O sinalizador FILE_FLAG_NO_BUFFERING tem o maior efeito sobre o comportamento do sistema de ficheiros para a operação assíncrona. Esta é a melhor forma de garantia que os pedidos de e/s são efectivamente assíncronos. Indica ao sistema de ficheiros para não utilizar qualquer cache mecanismo 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 de CreateFile para obter mais informações sobre como utilizar este sinalizador correctamente.

Resultados do teste real mundiais

Seguem-se alguns resultados de ensaios obtidos o código de exemplo. A magnitude das números não é importante aqui e varia de computador para computador, mas a relação dos números em relação umas às outras illuminates a afectam geral dos sinalizadores de desempenho.

Pode esperar 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 emitidos rapidamente 500 pedidos de e/s e teve muito tempo a executar qualquer outro trabalho ou a emissão mais pedidos.
  • Ensaio 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 gasta a 4.495880 segundos chamar ReadFile para concluir as suas operações, Considerando que o teste 1 gasto apenas 0.224264 segundos para emitir os pedidos do mesmos. No ensaio 2, não ocorreu nenhum "extra" hora para o programa deve efectuar qualquer fundo trabalho.
  • Ensaio n º 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 da cache. Todas as leituras foram emitidas e concluídas em 0.251670 segundos. Por outras palavras, pedidos assíncronos foram concluídos de forma síncrona. Isto também testar demonstra o alto desempenho do Gestor da cache quando estão a dados a 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 no ensaio n º 3. Tenha em atenção que as Leituras síncronas a partir da cache concluir um pouco mais rapidamente do que as Leituras assíncronas a partir da cache. Este teste também demonstra o alto desempenho do Gestor da cache quando os dados estiverem na cache.

CONCLUSÃO

Pode decidir qual o método é preferível porque todos os depende do tipo, tamanho e número de operações que executa o programa.

A predefinição de acesso de ficheiro sem especificar todos os sinalizadores especiais para CreateFile é uma operação síncrona e em cache.

Nota: obter alguns comportamento automática assíncrono neste modo vez preditiva assíncrona leitura antecipada e assíncrona escrita lenta de dados modificados efectua automaticamente o controlador de sistema de ficheiros. Apesar de isto não fizer a s aplicação [ASCII 146] e/s assíncrona, é o caso ideal para a maioria das aplicações simples.

Se, por outro lado, a aplicação não é simple, poderá ter de fazer Alguns de criação de perfis e monitorização do desempenho para determinar o melhor método, semelhante aos ensaios ilustrados neste artigo. A hora de criação de perfis despendido a Função ReadFile ou WriteFile e, em seguida, comparar este tempo como longa demora para as operações de e/s reais concluir é extremamente útil. Se a maioria do tempo é gasto na emissão efectivamente a e/s, em seguida, o e/s está a ser concluído sincronamente. No entanto, se o tempo despendido a pedidos de emissão e/s é relativamente pequeno comparado com o tempo efectua as operações de e/s de concluído, em seguida, as operações são a ser tratadas assincronamente. A amostra código mencionado anteriormente neste artigo utiliza a função de QueryPerformanceCounter para fazer a sua própria criação de perfis interno.

Monitorização do desempenho pode ajudar a determinar a eficácia do programa é utilizar o disco e a cache. Qualquer um dos contadores de desempenho para rastreio o objecto de Cache indicará o desempenho do Gestor de cache. Controlar os contadores de desempenho para o disco físico ou o disco lógico objectos indicará o desempenho dos sistemas de disco.

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

Referências

Para mais informações sobre estes utilitários e monitorização de desempenho, consulte o volume "optimizar o Windows NT" o recurso de Windows NT Documentação do Kit.
Sistemas para suportar «entrega garantida para suportes de dados estáveis», conforme descrito em que o programa de revisão de solução do Microsoft SQL Server Always-On armazenamento requer o SQL Server. FOPara 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 seguinte para visualizar o artigo na Microsoft Knowledge Base:
967576Requisitos de entrada/saída de motor de base de dados de servidor de Microsoft SQL

Propriedades

Artigo: 156932 - Última revisão: 30 de maio de 2013 - Revisão: 6.0
A informação contida neste artigo aplica-se a:
  • Microsoft Win32 Application Programming Interface
  • 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 por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
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