multithreading - 阻塞I/O与非阻塞I/O之间是否存在灰色区？

Question

我熟悉根据JVM(Java/nio，Scala/Akka)上的阻塞和非阻塞两种范式进行编程的知识。
但是，我看到介于两者之间的一种灰色地带使我感到困惑。

查看您选择的任何非阻塞程序:它充满了阻塞语句!

例如，变量的每个分配都是等待CPU寄存器和内存读取成功的阻塞操作。
而且，非阻塞程序甚至包含阻塞语句，这些语句对复杂的内存集合进行计算，而不会违反非阻塞范例。

与此相反，如果我们以阻塞的方式调用某些外部Web服务来接收其结果，则显然会违反非阻塞的范式。

但是在这些极端之间是什么？读/写一个小文件，一个本地套接字或对嵌入式数据存储引擎(例如SQLite，RocksDb等)进行API调用该怎么办？是否可以阻止对这些API的读取/写入？在实践中，它们通常会提供强大的时序保证(例如，只要操作系统没有停止，<< << 1ms)，因此，纯内存访问几乎没有实际区别。举一个精确的例子:在Akka Actor中调用RocksDB获取/放置是否被认为是不可取的阻塞I/O？

因此，我的问题是，是否有经验法则或精确的标准可以帮助我确定我是否可以在非阻塞程序中坚持使用简单的阻塞语句，或者是否将这样的语句包装到非阻塞样板中(框架-依赖于例如将此类调用外包到单独的线程池，在Future或Monad中更深一层地嵌套等)。

Answer 1

for example, each assignment of a variable is a blocking operation that waits for CPU-registers and memory-reads to succeed

并不是真正被认为是“阻塞”的东西。这些操作是恒定时间，并且与任何IO操作的延迟(数千到十亿个周期之间的任何地方)相比，该常数非常低(通常为几个周期)-除了由于交换内存而导致的页面错误外，但如果发生这些错误经常，您仍然有问题。

而且，如果我们想让所有事情变得晦涩难懂，则个别指令不会完全阻塞CPU线程，因为现代CPU可以在等待内存/缓存或其他更昂贵的指令完成时对指令进行重新排序并执行没有数据依赖性的指令。

Moreover, non-blocking programs even contain blocking statements that carry out computations on complex in-memory-collections, without violating the non-blocking paradigm.

那些不被认为是阻塞CPU的工作。如果它们经过正确设计，可以在不阻止UI的情况下将结果呈现给用户，则它们甚至不应阻止用户交互。

Is it ok to do blocking reads/writes to these APIs?

这始终取决于您为什么首先使用非阻塞方法。您想解决什么问题？也许一个API保证了一种非阻塞方法，而另一个则没有。
例如，大多数文件IO方法名义上都处于阻塞状态，但是没有 fsync的写操作可能会非常便宜，尤其是如果您不写旋转锈迹，因此在计算线程池中避免使用这些方法可能会过大。另一方面，在等待数秒的数据库查询时，通常不希望阻塞固定线程池中的线程