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

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

A vantagem de E/s assíncrona é que o chamador tem tempo para realizar qualquer outro trabalho ou emitir mais solicitações enquanto a operação de E/s é concluída. O termo Overlapped E/s é freqüentemente usado para E/s assíncrona e E/s sobreposto não para E/s síncrona. Este artigo usa os termos síncrono e assíncrono para operações de E/s no Windows NT. Este artigo pressupõe que o leitor tenha determinada familiaridade com as funções de E/s de arquivos como WriteFile CreateFile, ReadFile.

Se com freqüência, operações de E/s assíncronas comportam síncrona apenas como E/s. determinadas condições que este artigo aborda na criar seções posterior que as operações de E/s concluídas em sincronia. O chamador não tem nenhum período de trabalho de plano de fundo porque as funções de E/s não retornam até que a E/s seja concluída.

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

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 E/s), seu comportamento não é abordado neste artigo.

Configurar a E/s assíncrona

O sinalizador FILE_FLAG_OVERLAPPED deve ser especificado no CreateFile quando o arquivo é aberto. Este sinalizador permite operações de E/s no arquivo para ser executada de forma assíncrona. Aqui está um exemplo: ser cuidado durante a codificação para E/s assíncrona porque o sistema reserva o direito de fazer uma operação síncrona se precisar. Portanto, é melhor se você escrever o programa para tratar corretamente uma operação de E/s que pode ser concluída forma síncrona ou assíncrona. O código de exemplo demonstra essa consideração.

Há muitas coisas que um programa pode enquanto espera para operações assíncronas concluir, como enfileiramento operações adicionais, ou fazer o trabalho de plano de fundo. Por exemplo, o código a seguir manipula corretamente sobreposta não sobrepostos e conclusão de uma operação de leitura. Ele não faz nada mais do que aguardar a E/s pendentes concluir: Observação que & NumberOfBytesRead passado para ReadFile é diferente da & NumberOfBytesTransferred passado para GetOverlappedResult. Se uma operação foi feita assíncrona, GetOverlappedResult é usado para determinar o número real de bytes transferidos na operação após ele ter sido concluída. A & NumberOfBytesRead passado para ReadFile não faz sentido.

Se, por outro lado, uma 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 use 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 OVERLAPPED estruturas. 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 poder usar uma estrutura OVERLAPPED pela primeira vez, ou antes de você reutilizar após uma operação anterior ter sido 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 ao buffer de dados usado em uma operação. Um buffer de dados não deve ser lido ou gravado até que sua operação de E/s correspondente seja concluído; ler ou gravar o buffer pode causar erros e dados corrompidos.

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

Se você seguiu as instruções anteriormente neste artigo, no entanto, todas as suas operações de E/s ainda normalmente deve concluir síncrona na ordem emitida e nenhuma das operações ReadFile retorna FALSE com GetLastError() retornando ERROR_IO_PENDING, isso significa não que ter nenhum tempo para qualquer trabalho de plano de fundo. Por que isso ocorre?

Há uma série de motivos por que operações de E/s síncrona concluída mesmo se tiver codificado para operação assíncrona:

Compactação

Obstrução de uma operação assíncrona é a compactação NTFS. O driver de sistema de arquivos não irá acessar arquivos compactados assíncrona; em vez disso, todas as operações são feitas síncronas. Isso não se aplica aos arquivos que são compactados com utilitários semelhantes a COMPRESS ou PKZIP.

Criptografia do NTFS

Semelhante a compactação, criptografia de arquivo faz o driver sistema converter E/s assíncrono para síncrono. Se os arquivos sejam descriptografados, as solicitações de E/s será assíncronas.

Estendendo um arquivo

Outro motivo que operações de E/s são concluídas síncrona é operações próprios. No Windows NT, qualquer gravar operação para um arquivo que estende seu comprimento será síncrona.

Observação : aplicativos podem tornar a 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 SetFileValidData (que está disponível no Windows XP e versões posteriores), aplicativos podem com eficiência estender arquivos sem incorrer em uma penalidade de desempenho para preenchimento zero-los.

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

Cache

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

Dados não está no cache

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

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

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

Não usar o cache

O sinalizador FILE_FLAG_NO_BUFFERING tem o efeito mais o comportamento do sistema de arquivos para operação assíncrona. Essa é a melhor maneira para garantir que as solicitações de E/s são realmente assíncronas. Ele instrui o sistema de arquivos não usar qualquer mecanismo de cache.

Aviso : há algumas restrições ao uso esse sinalizador 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 mais informações sobre como usar esse sinalizador corretamente.

CÓDIGO DE EXEMPLO

O seguinte arquivo está disponível para download no Centro de download da Microsoft:
Para obter informações adicionais sobre como baixar arquivos de suporte da Microsoft, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: Microsoft examinou esse arquivo em busca de vírus. Microsoft utilizou o mais recente software de detecção de vírus que estava disponível na data em que o arquivo foi publicado. O arquivo é armazenado em servidores com segurança avançada que ajudam a evitar qualquer alteração não autorizada no arquivo. O código de exemplo associado a este artigo demonstra o uso de sinalizadores e funções abordadas. O código é executado como um aplicativo de console no Windows NT. As opções de linha de comando a seguir controlam seu comportamento: Operação padrão deste programa é para a operação assíncrona, em buffer. Por padrão, 500 operações de E/s são solicitadas.

Real World Test Results

Seguem alguns resultados de teste do 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 em comparação comparados si ilumina o efeito dos sinalizadores no desempenho geral.

Você 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 emitido 500 solicitações de E/s rapidamente e tinha muito tempo para realizar qualquer outro trabalho ou emitir mais solicitações.
• 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 chamar ReadFile para concluir suas operações, enquanto o teste 1 gasto apenas 0.224264 segundos para emitir as solicitações do mesmas. No teste 2, não houve nenhum tempo "extra" para o programa fazer qualquer trabalho de plano de fundo.
• Testar 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 em sincronia. Este teste também demonstra o alto desempenho do Gerenciador de cache de quando o cache de dados.
• Testar 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 teste 3. Observe que síncrona leituras do cache concluir um pouco mais rápido que Leituras assíncronas do cache. Este teste também demonstra o alto desempenho do Gerenciador de cache de quando o cache de dados.

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 qualquer sinalizadores especiais para CreateFile é uma operação síncrona e armazenadas em cache.

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

Se, por outro lado, seu aplicativo não for simples, talvez você precise fazer algumas profiling e monitoramento de desempenho para determinar o melhor método, semelhante a testes ilustrados anteriormente neste artigo. Perfil o tempo gasto na função WriteFile ou ReadFile e, em seguida, dessa vez para quanto tempo demora para operações de E/s reais concluir a comparação é extremamente útil. Se a maior parte do tempo é gasto na emissão, na verdade, a E/s, em seguida, a E/s está sendo completada em sincronia. No entanto, se o tempo gasto emissão solicitações de E/s é relativamente pequeno em comparação com o tempo necessário para as operações de E/s concluir, e as operações são sendo tratadas assincronamente. O código de exemplo mencionado anteriormente neste artigo usa a função QueryPerformanceCounter para fazer o seu próprio perfil interno.

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

Há 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 de sistemas de disco, você primeiro deve emitir o comando de -y diskperf. Após emitir o comando, deve reiniciar o sistema para iniciar a coleta de dados.

Para obter mais informações sobre esses utilitários e monitoramento de desempenho, consulte o volume "Optimizing Windows NT" na documentação do Windows NT Resource Kit.

SQL Server requer sistemas para oferecer suporte a ? entrega de mídia estável garantida ? conforme descrito no programa do Microsoft SQL Server Always-On armazenamento Solution revisão. 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: