进程阻塞如何应用于多线程进程？答案

【问题标题】：How does process blocking apply to a multi-threaded process?进程阻塞如何应用于多线程进程？
【发布时间】：2013-08-07 13:47:28
【问题描述】：

我了解到一个进程有 running、ready、blocked 和 suspended 状态。线程也有这些状态，除了挂起，因为它存在于进程的地址空间中。

进程在执行阻塞 i/o 或等待事件时大部分时间都会阻塞。

如果一个进程是单线程的，或者它遵循一对多模型，我可以很容易地想象出一个进程会被阻塞，但是如果进程是多线程的，它是如何工作的？

例如：

我在遵循一对一模型的系统中有一个带有两个线程的进程。 一个处理 gui，另一个处理阻塞 i/o。我知道该进程保持响应，因为其他线程处理 i/o。

那么这个过程是否有可能被阻止，或者在这种情况下我应该排除它吗？

我只是进入这些东西，如果我还没有理解一些重要的细节，请原谅我。

【问题讨论】：

如果没有更具体的上下文，这将很难回答 - 根据平台、操作系统、系统库、编程语言及其支持的多{线程/处理}模型，可能存在巨大差异(s)...
很抱歉，如果我不能更详细地介绍。还有很多我不熟悉的东西。

标签： multithreading process scheduling

【解决方案1】：

假设您有一个工作队列，UI 线程在其中安排要完成的工作，而 I\O 线程则在那里寻找要完成的工作。工作队列本身是从两个线程读取和修改的数据，因此您必须以某种方式同步访问，否则会导致竞争条件。

天真的方法是使用锁（也称为临界区）同步对队列的访问。如果 I\O 线程获取锁然后阻塞，UI 线程将只保持响应，直到它决定需要安排工作并尝试获取锁。更好的方法是使用一个无锁队列，其中已经写了很多，您可以轻松搜索更多信息。

但要回答您的问题，是的，即使在使用多个线程时，导致 UI 卡顿/挂起仍然比您想象的要容易得多。有各种库可以让解决这个问题变得更容易或更难，因此根据您的操作系统和选择的语言，可能有比操作系统原语更好的东西。尽管有各种同步原语，Win32（据我所知）并没有让它变得非常容易。 Pthreads 和 Boost 在我看来也从来不是很简单。 Apple 的 GCD 让表达你想要的东西在语义上更容易（在我看来），尽管仍然有一些陷阱必须注意（例如在单个工作队列上调度太多阻塞操作并行完成并导致处理器在它们同时唤醒时抖动）。

我的建议是深入研究并编写大量多线程代码。调试起来可能很困难，但您会学到很多东西，最终它会成为第二天性。

【讨论】：

我想这是一个“最小化它发生的机会”而不是“等待它发生”的问题。这真的归结为良好的编程习惯。我只是好奇，当线程之间的资源拉锯战发生时，进程会发生什么？
当两个线程都尝试获取相同的锁时，一个线程最终会阻塞。您的目标确实应该是正确编写代码，以免发生资源争用。起初这似乎是合理的，因为争用很少发生并且会很快自行解决，但随着时间的推移，软件只会变得越来越大、越来越复杂，而且您会发现基础不牢固使得以后很难修复。