阻塞 I/O 从何而来？答案

【问题标题】：Where do blocking I/O comes from?阻塞 I/O 从何而来？
【发布时间】：2018-11-05 00:53:55
【问题描述】：

我的理解是硬件架构和操作系统的设计目的是不阻塞 cpu。当需要发生任何类型的阻塞操作时，操作系统会注册一个中断并继续执行其他操作，以确保始终有效地使用 cpu 的宝贵时间。

这让我想知道为什么大多数编程语言都设计有阻塞 API，但最重要的是，由于操作系统在 IO 方面以异步方式工作，注册中断并在稍后准备好结果时处理，我我真的很困惑我们的编程语言 API 如何摆脱这种异步。操作系统如何使用阻塞 API 为我们的编程语言提供同步系统调用？

这种同步性从何而来？当然不是在硬件层面。那么，在触发一些中断之前，我不知道旋转和旋转的地方是否存在无限循环？

【问题讨论】：

Re，“旋转和旋转直到出现一些中断” 大多数 CPU 都有一条指令可以暂停处理器直到下一次中断。在操作系统的“空闲循环”中使用该指令可以显着减少未满载的系统使用的电量/产生的热量。
@Edwin Dalorzo “我们的编程语言 API 如何摆脱这种异步” 你说的逃避是什么意思？
@mightyWOZ 操作系统如何为本质上是异步的东西提供同步系统调用？此类系统调用的“阻塞”性质的实际来源在哪里？
@EdwinDalorzo 再问一个问题。您认为同步系统调用会立即提供服务而没有任何延迟吗？
@mightyWOZ 不，我没有。

标签： multithreading operating-system multiprocessing scheduling multitasking

【解决方案1】：

我的理解是硬件架构和操作系统都是为了不阻塞cpu而设计的。

任何设计合理的操作系统都会有一个系统服务接口，按照你说的做。但是，有很多非理性的操作系统在进程级别不能以这种方式工作。

阻塞 I/O 比非阻塞 I/O 更易于编程。让我给你一个来自 VMS 操作系统的例子（Windoze 的工作方式与幕后相同）。 VMS 有一个名为 SYS$QIO 和 SYS$QIOW 的系统服务。即Queue I/O Request和Queue I/O Request and wait。系统服务具有相同的参数。一对参数是完成例程的地址和该例程的参数。但是，这些参数很少与 SYS$QIOW 一起使用。

如果您执行 SYS$QIO 调用，它会立即返回。当 I/O 操作完成时，完成例程被称为软件中断。然后，您必须在应用程序中进行中断编程。我们一直这样做。如果您希望您的应用程序能够同时读取 100 个输入流，那么您必须这样做。这比使用一台设备进行简单的阻塞 I/O 更复杂。

如果一种编程语言要将这样的回调系统合并到它的 I/O 语句中，它就会镜像 VMS/RSX/Windoze。 Ada 使用任务概念以独立于操作系统的方式实现此类系统。

在太监世界中，为每个设备创建单独的流程是传统做法。在您必须读取和写入每个设备之前，这更简单。

【讨论】：