我有一个多线程 C/C++ 程序，它非常频繁地为读写请求提供服务。出于同步目的，我使用互斥锁进行锁定和解锁。所有的读写线程在执行它们的操作之前都会获取锁。如果一个线程获得锁并且在它可以释放锁之前发生中断会发生什么？线程会恢复执行还是我必须手动处理它？
【问题讨论】：
标签： c++ linux pthreads mutex interrupt
用户端锁，包括互斥锁，不会阻塞中断。这很重要，因为 Mutex 通常可用于保护从磁盘上的文件读取，或保护从网络接收数据包，等等，结果依赖于中断。
本质上，如果有中断，“什么都不会”发生。中断由操作系统处理，就像任何其他时间一样。在这种情况下，您的程序无需执行任何操作，如果发生这种情况，您只需花费几微秒或几毫秒的时间来执行您为任务编写的任何操作。
某些内核端锁，例如 SpinLocks 确实会阻止中断（在该处理器内核上），以确保其他进程/线程不会在此过程中被调度。在这些情况下内核可以使用哪些函数也有限制——例如，在运行期间不能调用阻塞函数（例如睡眠、等待事件或文件读取或文件写入）这一次，因为这可能会导致内核锁定。
【讨论】：
线程最终会恢复执行，它可能在内核服务中断之后立即发生，或者内核调度程序可能决定调度另一个准备运行的线程。如果被中断的线程获得了一个竞争激烈的锁，那么其他试图获取该锁的线程将阻塞（或自旋，或自旋然后阻塞，取决于互斥锁的实现），直到再次调度被中断的线程，完成受锁保护的临界区，然后将其解锁。
在需要近乎实时性能的系统中，会进行仔细调整，以将关键线程分配给它们自己的内核（cpu 亲和性）并将中断映射到其他内核。此外，还要特别注意锁的使用，有时使用无锁算法。
【讨论】：
线程拥有锁这一事实不受信号影响。如果一个线程有锁并接收到一个信号，就不会发生什么特别的事情。 事实上，信号和线程并不能很好地混合，因为信号在设计时就考虑到了进程。那是因为你不知道哪个线程会得到信号。处理这个问题的正确方法是有一个特定的线程来管理信号，例如阻止每个线程中的所有信号，但一个唯一的职责是处理信号。这是在具有线程的软件中处理信号的正确方法。
【讨论】：