Qual é o status de POSIX assíncrono I / O (AIO)?

Question

Há páginas espalhadas ao redor da web que descrevem instalações POSIX AIO em quantidades variáveis ??de detalhe. Nenhum deles são terrivelmente recente. Não está claro o que, exatamente, eles estão descrevendo. Por exemplo, o (?) web site "oficial" para assíncrona suporte I / O kernel Linux aqui diz que soquetes não funcionam, mas os "aio.h" páginas de manual no meu Ubuntu 8.04.1 workstation tudo parece implicar que ele funciona para descritores de arquivos arbitrários. Então há outro projeto que parece trabalho no camada Biblioteca com ainda menos documentação.

Eu gostaria de saber:

• O que é o objetivo de POSIX AIO? Tendo em conta que o exemplo mais óbvio de uma implementação posso encontrar diz que não suporta soquetes, a coisa toda parece estranho para mim. É apenas para assíncrona disco I / O? Se assim for, por que a API hiper-geral? Se não, por que é o disco I / O, a primeira coisa que foi atacado?
• Onde é que há exemplo completo programas POSIX AIO que eu posso olhar?
• Será que alguém realmente usá-lo, de verdade?
• Que plataformas suportam POSIX AIO? Quais são as partes de que eles apoiam? Será que alguém realmente apoiar a implícita "Qualquer I / O para qualquer FD" que <aio.h> parece promessa?

Os outros mecanismos de multiplexação disponíveis para mim são perfeitamente bom, mas os fragmentos aleatórios de informação flutuando lá fora, têm me deixou curioso.

Answer 1

Rede de E / S não é uma prioridade para AIO porque todo mundo escrever servidores de rede POSIX usa um evento com base, a abordagem não-bloqueio. O Java velho estilo "bilhões de bloquear tópicos" abordagem suga horrivelmente.

Disk write I / O já é tamponado e leitura de disco I / O podem ser pré-buscadas em buffer usando funções como posix_fadvise. Isso deixa direta, sem buffer de disco I / O como o único propósito útil para AIO.

direta, sem buffer de E / S só é realmente útil para bancos de dados transacionais, e aqueles tendem a escrever suas próprias threads ou processos para gerir o seu disco I / O.

Assim, no final que as folhas POSIX AIO na posição de não servir qualquer finalidade útil. Não usá-lo.

Answer 2

Fazendo tomada de I / O de forma eficiente tem sido resolvido com kqueue, epoll, portas de conclusão IO e os gostos. Fazendo arquivo assíncrono I / O é uma espécie de retardatário (além de janelas E / S sobreposto e Solaris suportam cedo para posix AIO).

Se você está procurando para fazer tomada de I / O, você é provavelmente melhor fora de usar um dos mecanismos acima.

O principal objetivo do AIO é, portanto, para resolver o problema de assíncrono disco I / O. Isso é mais provável porque Mac OS X apenas suporta AIO para arquivos regulares, e não soquetes (desde kqueue faz isso muito melhor de qualquer maneira).

As operações de escrita são normalmente armazenados em cache pelo kernel e lavada para fora em um momento posterior. Por exemplo, quando a cabeça de leitura do drive acontece a passar pelo local onde o bloco está a ser escrito.

No entanto, para operações de leitura, se você quer que o kernel priorizar e encomendar o seu lê, AIO é realmente a única opção. Aqui está o porquê da lata kernal (teoricamente) fazer isso melhor do que qualquer aplicação de nível de usuário:

• O kernel vê tudo disco I / O, e não apenas os seus empregos disco aplicações, e pode encomendá-los a nível mundial
• O kernel (pode) saber onde o disco de cabeça de leitura é, e pode escolher os postos de trabalho de leitura de você passar para ele a fim ideal, para mover a cabeça a distância mais curta
• O kernel pode tirar vantagem da comando nativo filas para otimizar ainda mais suas operações de leitura
• Você pode ser capaz de emitir operações mais lidos por chamada de sistema usando lio_listio () do que com readv (), especialmente se o seu lê não são (logicamente) contígua, poupando um pouco de chamada de sistema em cima.
• O seu programa pode ser um pouco mais simples com AIO desde que você não precisa de um fio extra para bloco em uma chamada de leitura ou escrita.

Dito isso, posix AIO tem uma interface bastante estranho, por exemplo:

• A média apenas eficiente e bem apoiado de retornos de chamada de evento são através de sinais, o que torna difícil para o uso em uma biblioteca, uma vez que significa o uso de números de sinal a partir do namespace sinal de processo global. Se seu sistema operacional não suporta sinais em tempo real, isso também significa que você tem que percorrer todos os seus pedidos pendentes para descobrir qual deles realmente acabados (este é o caso para Mac OS X, por exemplo, não Linux). Captura sinais em um ambiente multi-threaded também contribui para algumas restrições complicadas. Você normalmente não pode reagir ao evento dentro do manipulador de sinal, mas você tem que levantar um sinal, escrita para um tubo ou uso signalfd () (no Linux).
• lio_suspend () tem as mesmas questões que select () faz, ele não escala muito bem com o número de postos de trabalho.
• lio_listio (), como implementado tem número de postos de trabalho bastante limitada você pode passar, e não é trivial para encontrar este limite de uma forma portátil. Você tem que chamar sysconf (_SC_AIO_LISTIO_MAX), que pode falhar, caso em que você pode usar o AIO_LISTIO_MAX definir, que não são necessariamente definidos, mas então você pode usar 2, que é definida como garantia de suporte.

Como para aplicação no mundo real usando POSIX AIO, você poderia dar uma olhada em lighttpd (lighty), que também colocaram um desempenho de medição quando o apoio introdução.

A maioria das plataformas POSIX suportes posix AIO até agora (Linux, BSD, Solaris, AIX, Tru64). Windows suporta-lo através do seu sobreposta arquivo I / O. O meu entendimento é que somente Solaris, Windows e Linux realmente suporta assíncrona. arquivo I O todo o caminho / para baixo para o motorista, enquanto os outros sistemas operacionais emular o assíncrono. I / O com o kernel threads. Linux é a exceção, a sua implementação AIO posix em glibc emula as operações assíncronas com tópicos nível de usuário, ao passo que a sua assíncrona nativa Interface I / O (io_submit () etc.) são verdadeiramente assíncrona todo o caminho para o motorista, assumindo os suportes motorista de TI .

Eu acredito que é bastante comumentre os sistemas operacionais para não apoiar posix AIO para qualquer fd, mas restringi-la aos arquivos regulares.

Answer 3

Um desenvolvedor libtorrent fornece um relatório sobre esta: http: // blog. libtorrent.org/2012/10/asynchronous-disk-io/

Answer 4

Há aio_write - implementado em glibc; primeira chamada do aio_read ou aio_write desova função de um número de threads modo de usuário, aio_write ou pós aio_read solicitações para esse segmento, o fio faz pread / pwrite e quando ele for concluído, a resposta é enviada de volta para o segmento bloqueado chamando.

Ther também é 'real' aio - apoiado pelo nível do kernel (necessidade libaio para isso, veja a chamada io_submit http://linux.die.net/man/2/io_submit ); também precisa O_DIRECT para que (também pode não ser suportado por todos os sistemas de arquivos, mas as mais importantes que apoiá-lo)

ver aqui:

http://lse.sourceforge.net/io/aio.html

http://linux.die.net/man/2/io_submit

entre POSIX AIO e libaio no Linux?