在像文件这样的块设备的上下文中;是Linux内核AIO函数，如io_submit()，只是在提供的I / O操作队列中的异步，或者它们（也是）异步跨多个proses和/或线程也有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操作完成？
答案 0 :(得分：1)
应用程序应该关注的异步行为的唯一部分是在您的应用程序中。是的，其他进程可能会在应用程序运行时期间的某个时刻将数据写入磁盘。在多任务处理，多用户和可能的多处理器系统中，您几乎无法阻止它。
这里的一般想法是您的应用程序不会阻止，read或write [及其更高级的堂兄弟fread，fwrite的方式等）。
如果您想阻止其他进程触及“您的”文件，那么您需要使用文件锁定或类似的东西。
答案 1 :(得分：0)
当使用io_submit提交一组io请求时，系统调用立即返回。从发出请求的线程的角度来看，嵌入在请求中的命令的执行是异步的。线程必须查询操作系统才能知道结果，并且可以自由地同时执行它想要的操作。
现在，如果两个线程碰巧发出一组请求，它们都会处于相同的情况。他们都必须向操作系统询问各自IO命令的进展情况。没有线程会被阻止。
从AIO框架的角度来看，完全可以让操作系统实际执行之前的请求从io_submit调用返回调用它的一个或所有线程，但是API保持不变：用户态线程仍然会将API作为异步API进行操作，在发布请求时从API获取未来结果的令牌，并使用该令牌获取实际结果。
在linux AIO的特定情况下，令牌是事先创建的上下文，结果检查系统调用是io_getevents，它为每个已完成的请求报告“事件”（即结果）。
关于您的示例，是否可能在第二个系统调用期间，第一个线程的所有请求都已完成？我没有看到这种情况永远不会发生的原因，但如果两个线程都发布了100个非常接近的请求，那么它似乎不太可能。更可能的情况是，当第二个线程自己调用io_submit时，第一个线程调用io_submit的几个请求已完成，但无论如何调用都不会阻塞