POSIX 异步 I/O（AIO）的状态如何？

问题描述：

网络上有许多页面以不同程度的细节描述了 POSIX AIO 设施。这些页面都不是最新的。不清楚它们到底在描述什么。例如，Linux 内核异步 I/O 支持的“官方”(?) 网站表示套接字不起作用，但我的 Ubuntu 8.04.1 工作站上的“aio.h”手册页似乎都暗示它适用于任意文件描述符。然后还有另一个项目似乎在库层工作，但文档更少。

我想知道：

• POSIX AIO 的目的是什么？鉴于我能找到的最明显的实现示例表明它不支持套接字，整个事情对我来说似乎很奇怪。它只是用于异步磁盘 I/O 吗？如果是这样，为什么要使用超通用 API？如果不是，为什么磁盘 I/O 是第一个受到攻击的东西？

• 哪里有完整的POSIX AIO 程序示例可以供我查看？

• 真的有人真正用过它吗？

• <aio.h>哪些平台支持 POSIX AIO？它们支持其中的哪些部分？是否有人真的支持似乎承诺的隐含“任何 I/O 到任何 FD” ？

我可以使用的其他多路复用机制都非常好，但是到处流传的随机信息片段让我很好奇。

解决方案 1：

高效执行套接字 I/O 的问题已通过 kqueue、epoll、IO 完成端口等方法得到解决。执行异步文件 I/O 则有点姗姗来迟（除了 Windows 的重叠 I/O 和 Solaris 对 posix AIO 的早期支持）。

如果您希望执行套接字 I/O，那么最好使用上述机制之一。

因此，AIO 的主要目的是解决异步磁盘 I/O 的问题。这很可能就是为什么 Mac OS X 仅支持常规文件的 AIO，而不支持套接字（因为 kqueue 在这方面做得更好）。

写入操作通常由内核缓存并在稍后刷新。例如当驱动器的读取头恰好经过要写入块的位置时。

但是，对于读取操作，如果您希望内核对读取进行优先级排序，那么 AIO 实际上是唯一的选择。这就是为什么内核（理论上）可以比任何用户级应用程序做得更好：

• 内核可以看到所有磁盘 I/O，而不仅仅是应用程序的磁盘作业，并且可以在全局级别对它们进行排序

• 内核（可能）知道磁盘读取头在哪里，并且可以按最佳顺序选择传递给它的读取作业，以使读取头移动最短的距离

• 内核可以利用本机命令排队进一步优化读取操作

• 与 readv() 相比，使用 lio_listio() 每次系统调用您可能能够发出更多的读取操作，特别是当您的读取（逻辑上）不连续时，从而节省一点点系统调用开销。

• 使用 AIO 后您的程序可能会稍微简单一些，因为您不需要额外的线程来阻止读取或写入调用。

话虽如此，posix AIO 有一个相当尴尬的接口，例如：

• 事件回调的唯一有效且得到良好支持的方法是通过信号，这使得它很难在库中使用，因为这意味着使用来自进程全局信号命名空间的信号编号。如果您的操作系统不支持实时信号，这还意味着您必须循环遍历所有未完成的请求，以确定哪个请求真正完成了（例如，这是 Mac OS X 的情况，而不是 Linux）。在多线程环境中捕获信号也会带来一些棘手的限制。您通常不能对信号处理程序中的事件做出反应，但您必须发出信号、写入管道或使用 signalfd()（在 Linux 上）。

• lio_suspend() 具有与 select() 相同的问题，它不能很好地随着作业数量而扩展。

• lio_listio() 的实现中，您可以传入的作业数量相当有限，而且以可移植的方式找到这个限制并不容易。您必须调用 sysconf(_SC_AIO_LISTIO_MAX)，这可能会失败，在这种情况下，您可以使用 AIO_LISTIO_MAX 定义，它不一定被定义，但您可以使用 2，它被定义为保证被支持。

至于使用 posix AIO 的实际应用，您可以看看 lighttpd (lighty)，它在引入支持时也发布了性能测量。

目前，大多数 posix 平台都支持 posix AIO（Linux、BSD、Solaris、AIX、tru64）。Windows 通过其重叠文件 I/O 支持它。我的理解是，只有 Solaris、Windows 和 Linux 真正支持异步文件 I/O，直至驱动程序，而其他操作系统则使用内核线程模拟异步 I/O。Linux 是个例外，它在 glibc 中的 posix AIO 实现使用用户级线程模拟异步操作，而其本机异步 I/O 接口（io_submit() 等）是真正异步的，直至驱动程序（假设驱动程序支持它）。

我相信在操作系统中，不支持任何 fd 的 posix AIO 是相当常见的，而是将其限制为常规文件。

解决方案 2：

网络 I/O 不是 AIO 的重点，因为每个编写 POSIX 网络服务器的人都使用基于事件的非阻塞方法。旧式 Java“数十亿个阻塞线程”方法非常糟糕。

磁盘写入 I/O 已缓冲，磁盘读取 I/O 可使用 posix_fadvise 等函数预取到缓冲区中。这使得直接、非缓冲磁盘 I/O 成为 AIO 的唯一有用用途。

直接、无缓冲 I/O 仅对事务数据库真正有用，并且这些数据库倾向于编写自己的线程或进程来管理其磁盘 I/O。

因此，最终 POSIX AIO 处于没有任何用处的境地。不要使用它。

解决方案 3：

libtorrent 开发人员提供了一份关于此的报告： http: //blog.libtorrent.org/2012/10/asynchronous-disk-io/

解决方案 4：

有 aio_write - 在 glibc 中实现；第一次调用 aio_read 或 aio_write 函数会产生许多用户模式线程，aio_write 或 aio_read 向该线程发送请求，该线程执行 pread/pwrite，完成后将答案发回到被阻塞的调用线程。

还有“真正的”aio - 由内核级别支持（需要 libaio，请参阅 io_submit 调用http://linux.die.net/man/2/io_submit）；还需要 O_DIRECT（也可能并非所有文件系统都支持，但主要文件系统都支持它）

参见此处：

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

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

Linux 上 POSIX AIO 和 libaio 之间的区别？