Windows 上的异步 IO 真正归结为什么（例如 NodeJS、EventMachine 等）？答案

【问题标题】：What does asynchronous IO really come down to on Windows (ie like NodeJS, EventMachine, etc)?Windows 上的异步 IO 真正归结为什么（例如 NodeJS、EventMachine 等）？
【发布时间】：2012-02-13 17:12:03
【问题描述】：

我对使用单线程执行异步 IO 的“事件循环”这一主题进行了大量研究。我的理解是，例如，nodeJS 代码在单线程环境中运行，但确实在幕后将作业传递给并行线程。这意味着除了代码和解释器之外的所有东西都是同时运行的，它只是以单线程方式传递作业并管理回调。

我的问题是关于 Windows 中的 IO 和 ThreadPool 线程，特别是文件 IO 和数据库读/写。通常在使用多线程的 .NET 环境中，您可能会看到：

lock(sync)
{
          // do some IO
}

为了保护某些函数免受并发问题的影响，例如两个线程试图将记录保存到同一个 sql 表或文件中。

我的问题有两个，

1) 当 nodeJS 说它执行“异步 IO”时，这是否意味着它实际上并发写入数据库或文件？我认为这取决于底层设备/操作系统，而不是 nodeJS，但我想澄清一下。

2) 如果某些 IO 操作必须或至少应该是原子的（不能同时完成），那么“异步 IO”有什么帮助？如果您最终不得不 lock() 很多这些操作，那么生成线程来执行 IO 会不会很浪费？

【问题讨论】：

标签： c# .net multithreading node.js threadpool

【解决方案1】：

当 nodeJS 说它执行“异步 IO”时，这是否意味着它实际上同时写入数据库或文件？我认为这取决于底层设备/操作系统，而不是 nodeJS，但我想澄清一下。

它在写入数据库或文件时是否执行其他操作取决于 nodeJS。并发不是指对同一目标执行相同类型的操作。是指对不同的目标执行不同类型的操作或操作。

如果某些 IO 操作必须或至少应该是原子的（不能同时进行），那么“异步 IO”有什么帮助？如果您最终不得不 lock() 很多这些操作，那么生成线程来执行 IO 会不会很浪费？

同样的反应。只有在同一目标上进行相同类型的操作时，才会发生锁冲突。否则，如果他们请求锁，他们将请求不同的锁，并且不会互相妨碍。

实现细节取决于操作的类型。例如，线程可以获取特定资源的所有权并处理该资源的操作，直到它用尽了可做的事情。在处理该资源时，可以将同一资源上的其他操作分派到该线程。这样一来，您就不会仅仅为了等待另一个线程完成而启动一个线程来强制进行无意义的上下文切换。

【讨论】：

【解决方案2】：

任何形式的异步 IO 都基于两个前提：

发生 IO 时您的主应用程序线程没有被阻塞
如果多个未完成的异步 IO 请求争用特定资源（例如，文件或表中的记录），则您可以预期以下之一：
1. 一项或多项操作将失败
2. 操作将成功，但不保证保留数据不变量
3. 操作将自动序列化。

选项 2.3 不会破坏异步 IO 的有用性，因为可能争用只发生在所有 IO 请求的一小部分。

【讨论】：

【解决方案3】：

我认为，当它提到异步 IO 时，它是指您可以执行 IO 操作并且它将在后台运行，然后您可以做其他不需要该 IO 的事情，直到您收到回调.

这在您接收多个请求的服务器环境中很有用。在等待 IO 操作完成时，您可以为另一个客户端提供服务。

【讨论】：

hueniverse.com/2011/06/the-style-of-non-blocking有一篇关于它的好文章

【解决方案4】：

关于 2.，操作可以按顺序进行，以便一个操作仅在其因果依赖的操作完成后才开始，并且大多数为异步 io 产生的 io 操作提供服务的系统应该能够支持大量运行中的操作和那些提供原子操作的系统可能会在内部执行锁定，但它们发生锁定错误的可能性也远低于您的程序。但是，当它们可以组合成原子事务时，原子操作是最好的。

【讨论】：