在像文件这样的块设备的上下文中；是 Linux 内核 AIO 函数，例如io_submit()仅在提供的 I/O 操作队列中异步，还是它们（也）跨多个进程和/或线程异步，这些进程和/或线程在同一文件上也有 I/O 操作队列。
Doc 说：io_submit()系统调用将 nr I/O 请求块排队，以便在 AIO 上下文 ctx_id 中进行处理。iocbpp 参数应该是 nr 个 AIO 控制块的数组，将提交给上下文 ctx_id。
更新：
示例：如果我生成两个线程，它们在同一个文件上都有 100 个排队的 I/O 操作，并且都调用io_submit()大约。同时; 是否所有200 个 I/O 操作都是异步的，或者线程 #1 的 100 个 I/O 操作是否彼此异步但阻塞线程 #2 直到所有线程 #1 的 I/O 操作完成？
您的应用程序应该关心的异步行为的唯一部分是在您的应用程序中。是的，其他进程也可能会在应用程序运行时的某个时间点将数据写入磁盘。在多任务、多用户和潜在的多处理器系统中，您几乎无法阻止这种情况。
这里的一般想法是您的应用程序不会阻塞，这就是reador write[和他们更高级的表亲fread，,fwrite等）的方式。
如果你想阻止其他进程接触“你的”文件，那么你需要使用文件锁定或类似的东西。
当使用 提交一组 io 请求时io_submit，系统调用立即返回。从发出请求的线程的角度来看，嵌入在请求中的命令的执行是异步的。线程必须查询操作系统才能知道结果，同时可以自由地做它想做的事情。
现在，如果两个线程碰巧各自发出一组请求，它们都将处于相同的情况。他们都必须向操作系统询问各自 IO 命令的进展情况。不会阻塞任何线程。
从 AIO 框架的角度来看，完全有可能让操作系统在从调用它的一个或所有线程的调用返回之前io_submit实际执行请求，但 API 保持不变：用户态线程仍将 API 作为一个async one，在发布请求时从 API 获取未来结果的令牌，并使用该令牌获取真实结果。
在 linux AIO 的特定情况下，token 是预先创建的上下文，结果检查系统调用是io_getevents，它为每个完成的请求报告一个“事件”（即结果）。
关于您的示例，是否有可能在第二个系统调用期间，第一个线程的所有请求都已完成？我看不出这根本不会发生的原因，但是如果两个线程彼此非常接近地发布 100 个请求，那么这似乎不太可能。更可能的情况是，io_submit当第二个线程自己调用时，第一个线程调用的几个请求已完成io_submit，但无论如何该调用不会阻塞。