标签：检查 怎样 并发 问题 get 直接 编程 延迟 权限
同步和异步是一对相对的概念，阻塞和非阻塞是另一对相对的概念。这两对概念之间没有必然的关联性，它们经常被混淆或者组合在一起进行讨论。事实上，这样的讨论与对比是需要分层次，分对象，分具体应用场景来进行的。建议将这两对概念分开做独立理解，再结合具体场景做针对性理解。
以下内容摘录自知乎怎样理解阻塞非阻塞与同步异步的区别？高赞回答，仅供参考。
《操作系统概念（第九版）》中有关进程间通信的内容摘录：
大致意思为：
进程间的通信是通过调用 send() 和 receive() 两种基本操作来完成的。每种基本操作又包含着不同的设计选项。 消息的传递有可能是阻塞的或非阻塞的——也被称为同步或异步的：
上述不同类型的发送方式和不同类型的接收方式，可以自由组合。
也就是说， 从进程级通信的维度讨论时， 阻塞和同步（非阻塞和异步）就是一对同义词， 且需要针对发送方和接收方作区分对待。
操作系统为了支持多个应用同时运行，需要保证不同进程之间相对独立（一个进程的崩溃不会影响其他的进程 ， 恶意进程不能直接读取和修改其他进程运行时的代码和数据）。 因此操作系统内核需要拥有高于普通进程的权限， 以此来调度和管理用户的应用程序。
于是内存空间被划分为两部分，一部分为内核空间，一部分为用户空间，内核空间存储的代码和数据具有更高级别的权限。内存访问的相关硬件在程序执行期间会进行访问控制（ Access Control），使得用户空间的程序不能直接读写内核空间的内存。
（有《微机原理》 课程基础同学可以 Google 搜索 DPL, CPL 这两个关键字了解硬件层面的内存访问权限控制细节）
上图展示了进程切换中几个最重要的步骤：
几个底层概念的通俗（不严谨）解释：
从上述描述中可以看出来，操作系统在进行进切换时，需要进行一系列的内存读写操作，这带来了一定的开销：对于一个运行着UNIX系统的现代PC来说，进程切换通常至少需要花费300 us的时间。
上图展示了一个进程的不同状态：
我们所说的 “阻塞”是指进程在发起了一个系统调用（System Call） 后，由于该系统调用的操作不能立即完成，需要等待一段时间,于是内核将进程挂起为等待 （waiting）状态，以确保它不会被调度执行，占用 CPU 资源。
友情提示：在任意时刻，一个CPU核心上（processor）只可能运行一个进程 。
UNIX网络编程中将I/O模型分为5类：阻塞I/O，非阻塞I/O，I/O复用，信号驱动，异步I/O。
这里再重新审视阻塞/非阻塞 I/O这个概念， 其实阻塞和非阻塞描述的是进程的一个操作是否会使得进程转变为“等待”的状态， 但是为什么我们总是把它和I/O连在一起讨论呢？
原因是，阻塞这个词是与系统调用System Call紧紧联系在一起的， 因为要让一个进程进入 等待（waiting） 的状态, 要么是它主动调用 wait() 或 sleep() 等挂起自己的操作，另一种就是它调用System Call, 而System Call因为涉及到了I/O操作，不能立即完成，于是内核就会先将该进程置为等待状态，调度其他进程的运行，等到它所请求的I/O操作完成了以后，再将其状态更改回ready。
操作系统内核在执行System Call时，CPU需要与I/O设备完成一系列物理通信上的交互，其实再一次会涉及到阻塞和非阻塞的问题。例如，操作系统发起了一个读硬盘的请求后， 其实是向硬盘设备通过总线发出了一个请求，它即可以阻塞式地等待I/O设备的返回结果，也可以非阻塞式的继续其他的操作。 在现代计算机中，这些物理通信操作基本都是异步完成的， 即发出请求后， 等待I/O设备的中断信号后， 再来读取相应的设备缓冲区。 但是，大部分操作系统默认为用户级应用程序提供的都是阻塞式的系统调用（blocking system call）接口， 因为阻塞式的调用，使得应用级代码的编写更容易（代码的执行顺序和编写顺序是一致的）。
但同样， 现在的大部分操作系统也会提供非阻塞I/O系统调用接口（Nonblocking I/O system call）。 一个非阻塞调用不会挂起调用程序， 而是会立即返回一个值， 表示有多少字节的数据被成功读取（或写入）。
非阻塞I/O系统调用( nonblocking system call )的另一个替代品是异步I/O系统调用 （asychronous system call）。 与非阻塞I/O系统调用类似，asychronous system call也是会立即返回， 不会等待I/O操作的完成， 应用程序可以继续执行其他的操作， 等到 I/O 操作完成了以后，操作系统会通知调用进程（设置一个用户空间特殊的变量值或者触发一个signal或者 产生一个软中断或者调用应用程序的回调函数）。
此处， 非阻塞I/O 系统调用（nonblocking system call）和异步I/O系统调用（asychronous system call）的区别是：
下图展示了同步I/O与异步I/O的区别 （非阻塞 IO 在下图中没有绘出）：
注意， 上面提到的非阻塞I/O 系统调用（nonblocking system call）和异步I/O系统调用都是非阻塞式的行为（non-blocking behavior），它们的差异仅仅是返回结果的方式和内容不同。
考虑一个单进程服务器程序， 收到一个Socket连接请求后， 读取请求中的文件名，然后读请求的文件名内容，将文件内容返回给客户端。 那么一个请求的处理流程会如下图所示：
在这个过程中， 我们可以看到， CPU和硬盘I/O的资源大部分时间都是闲置的。 此时， 我们会希望在等待I/O的过程中继续处理新的请求。
方案一： 多进程
方案二：多线程
引申问题： 一个进程中的某一个线程发起了system call后， 是否造成整个进程的阻塞？ 如果会， 那么多线程方案与单进程方案相比就没有明显的改善。
在这种方案中， 如果CPU是多核的， 不同的线程还可以运行在不同的CPU processor上。 既实现了I/O并发， 也实现了CPU并发。
问题： 内核支持线程可移植性差， 其实现对于不同的操作系统而言有所差别。
从上面的过程可以看出，用户级支持线程（User-Supported Threads）的解决方案基于非阻塞I/O系统调用（Non-blocking system call）， 且是一种基于操作系统内核事件通知（event-driven）的解决方案， 该方案可以降低系统处理并发请求时的进程切换开销。 基于这个方案， 可以引申到更为宽泛的 event-driven progreamming 话题上。 但是这里就不作赘述了。
（1）阻塞/非阻塞， 同步/异步的概念要注意讨论的上下文：
（2）非阻塞系统调用（Non-blocking I/O system call 与 asynchronous I/O system call）的存在可以用来实现线程级别的I/O并发， 与通过多进程实现的I/O并发相比可以减少内存消耗以及进程切换的开销。
标签：检查 怎样 并发 问题 get 直接 编程 延迟 权限
原文地址：https://www.cnblogs.com/MinPage/p/14675914.html
