【发布时间】：2013-10-19 00:03:21
【问题描述】：
“阻塞系统调用”是什么意思？
在我的操作系统课程中，我们正在学习多线程编程。当我在教科书中读到“当线程进行阻塞系统调用时，它可以允许另一个线程运行”时，我不确定是什么意思
【问题讨论】：
标签： c multithreading operating-system system-calls
【发布时间】：2013-10-19 00:03:21
【问题描述】：
阻塞系统调用是必须等到操作完成的系统调用。 read() 将是一个很好的例子 - 如果没有输入准备好，它会坐在那里等到一些输入（当然，前提是你没有将它设置为非阻塞，在这种情况下它不会是阻塞系统调用）。显然，当一个线程正在等待阻塞系统调用时，另一个线程可以停止做其他事情。
【讨论】：
-
is 是指当一个用户线程使用了这个阻塞系统调用时，它会等待（这个线程被阻塞），另一个用户线程可以映射到之前映射的内核线程？
-
我不知道你正在学习什么课程，也不知道它想告诉你什么，但我想是这样。多对一多线程模型将多个用户线程与单个内核线程相关联。如果该内核线程处于阻塞系统调用中，则与之关联的所有用户线程也必须等待。这不适用于一对一模型，因为所有用户线程都有自己的内核线程，所以如果一个内核线程被阻塞，另一个内核线程可以做其他事情。
-
我也有同样的问题。如果它是多对一模型并且用户线程想要进行阻塞系统调用。所有其他线程也必须停止吗？ （只能内核线程进行系统调用吗？）
-
@PaulGriffiths 阻塞调用与屈服点有什么关系？ （在 nesC 论文中，这句话中它们之间存在隐含关系：“我们需要禁止原子部分中的阻塞调用，并将阻塞调用视为任务调度的屈服点。）
-
@Novemberland：屈服点是一个方便的地方（例如，它没有独占访问共享资源的地方），任务有机会自愿放弃其执行。通常它希望在超过其时间片之前执行此操作。由于阻塞系统调用可能会被阻塞很长时间，可能远远超过任务的时间片，因此进入系统调用将是系统中任务自愿让步控制的让步点的理想位置。
对于阻塞系统调用，调用者在系统调用返回之前不能做任何事情。如果系统调用可能很长（例如涉及文件 IO 或网络 IO），这可能是一件坏事（例如，想象一个沮丧的用户在应用程序中敲击“取消”按钮，但由于该线程被阻塞等待来自未到达的网络的数据包）。为了解决这个问题（在等待阻塞系统调用返回时做有用的工作），您可以使用线程 - 当一个线程被阻塞时，另一个线程可以继续做有用的工作。
替代方案是非阻塞系统调用。在这种情况下，系统调用（几乎）立即返回。对于冗长的系统调用，系统调用的结果要么稍后发送给调用者（例如，作为某种事件、消息或信号），要么稍后由调用者轮询。这允许您有一个线程同时等待许多不同的冗长系统调用完成；并避免了线程的麻烦（以及锁定、竞争条件、线程切换的开销等）。但是，这也增加了获取和处理系统调用结果的麻烦。
（几乎总是）可以围绕阻塞系统调用编写非阻塞包装器；包装器产生一个线程并（几乎）立即返回，产生的线程执行阻塞系统调用，并将系统调用的结果发送给原始调用者或将它们存储在原始调用者可以轮询的地方。
也可以（几乎总是）围绕非阻塞系统调用编写阻塞包装器；包装器执行系统调用并在返回之前等待结果。
【讨论】：
-
非阻塞系统调用和分阶段操作的关系是什么？第二个只是第一个的一小部分？关于非阻塞系统调用还有其他类型的操作吗？或者它们是一回事？提前致谢！
我建议阅读这段非常短的文本： http://files.mkgnu.net/files/upstare/UPSTARE_RELEASE_0-12-8/manual/html-multi/x755.html 特别是你可以阅读为什么阻塞系统调用可能是线程的问题，而不仅仅是并发进程：
这对于多线程应用程序尤其成问题，因为 一个线程阻塞系统调用可能会无限期延迟更新 另一个线程的代码。
希望对你有帮助。
【讨论】：