互斥量和信号量实际上是做什么的？

Question

我想要一些关于互斥锁和信号量的说明。
我的问题是，

1. 当一个线程试图进入一个被互斥锁锁定的区域时，互斥锁实际上做了什么，a。 它等待锁被释放？ 或 B. 它进入休眠状态，直到锁被释放。 在那种情况下，当锁被释放时它是如何再次唤醒的？
2. 与 1 相同的问题，但在本例中是信号量。
3. 你能给我一些关于在 C 中的 pthread 中忙等待的代码，以及线程进入睡眠状态而不是等待的情况吗？ 睡眠是否意味着它被阻塞或睡眠是另一种忙碌的等待？
4. 我想知道一些涵盖这种情况的程序，例如一些实现忙等待、阻塞等的 c 源代码。

Answer 1

当线程尝试获取互斥锁上的锁时，如果该互斥锁已被持有，那么通常它将使用对操作系统内核的调用来指示它正在等待，然后当当前持有锁的线程解锁互斥锁时它将调用操作系统内核以唤醒等待线程之一。

这同样适用于信号量，除了它仅在计数减少到零以下时才会阻塞，并且只有在计数增加回零以上时才会唤醒线程。

忙等待是您在等待某事时不会阻塞或休眠，而是在循环中反复轮询，因此处理器总是很忙，但没有做任何有用的事情。

要真正实现忙等待，需要一个原子变量，但是POSIX线程并没有提供这样的东西，所以你不能真正在pthreads中写一个忙等待。 您可以获得的最接近的是锁定互斥锁，读取标志，解锁互斥锁，如果未设置标志则循环。 这会反复锁定和解锁互斥锁，但不会等待数据准备就绪。 在这种情况下，您应该改用条件变量。

通常，如果一个线程调用了诸如usleep东西来暂停它自己的执行一段指定的时间，那么你就说它正在休眠。 这与阻塞相反，阻塞是等待另一个线程提供的特定信号。

Answer 2

请看： https : //stackoverflow.com/a/24582076/3163691

是的，互斥体和信号量都在同步内核对象，当一个线程尝试获取其中一个对象时，如果该对象已被其他线程拥有，则该线程将进入睡眠状态。

正如您已经猜到的，这种休眠是一个至关重要的特性，因为它允许其他线程做比“循环/轮询”更有用的工作。

当拥有该对象的线程释放它时，这些线程之一的休眠结束。

[ OS Scheduler不会为休眠线程提供任何执行切片]。

将它与锁和自旋锁进行对比，其中线程处于“循环/忙等待”状态，浪费宝贵的 CPU 时间，几乎什么都不做。 因此，应避免在用户代码中使用自旋锁。 改用临界区、互斥锁或信号量！。

正如您从上面的链接中看到的，这两个对象是不同的，应该在最适合的正确上下文中使用。

将互斥锁视为只允许一个线程拥有它的锁。 并且它具有许多安全属性（所有权、终止通知、递归等）。

并且，将信号量视为只允许指定数量的线程拥有它的锁。 但是，它没有mutex的许多有用属性。

希望这可以帮助。

Answer 3

这取决于互斥锁的类型（它的支持实现），有些忙于通过回退进行旋转，有些只会让内核线程对象休眠，然后在互斥锁更新时将其唤醒，有些则是两者的混合（ Valve 的 Source 引擎使用混合引擎）。 它的特性还取决于它需要跨越内核/用户空间障碍的时间和频率，因为有时这可能比旋转更长的时间成本更高（如果您想更多地了解旋转与睡眠方面的内容，请参阅此内容）。

互斥体通常用于一次单线程进入（尽管它们可能支持同一线程的递归进入）。 另一方面，信号量一次只允许n 个线程尝试获取它（参见这篇MSDN 文章，或这篇比较 Intel 的文章）。

休眠线程通常意味着它放弃其分配计算时间片，直到它准备好被唤醒并且操作系统调度程序给它另一个时间片。 您可能会找到的最佳示例实际上是在 linux 内核源代码中（或任何其他与此相关的开源操作系统）。

Answer 4

1. 当一个线程试图进入一个被互斥锁锁定的区域时，互斥锁实际上做了什么，a。 它等待锁被释放？ 或 B. 它进入休眠状态，直到锁被释放。 在那种情况下，当锁被释放时它是如何再次唤醒的？

当一个线程试图获取一个互斥锁时，它被卡住并只有在该锁被授予该线程时才返回。 该锁被 OS 识别，因此 OS 知道，直到这样的锁可用于给线程 - 它没有其他事情可做。 该线程停在 OS 内。 只有操作系统知道现在线程拥有所有权，它会返回休眠状态。 在单个 CPU 系统中，在那个实例中，如果某个其他进程正在运行，则互斥锁将仅在线程同时具有 CPU 可用和锁授予时才会返回！

注意：当您执行fwrite或select时，会发生同样的事情。 由于操作系统知道相应的 IO 需要时间，因此线程变为空闲。 当数据到达时，线程变得可运行。

1. 与 1 相同的问题，但在本例中是信号量。 你能给我一些关于在 C 中的 pthread 中忙等待的代码，以及线程进入睡眠状态而不是等待的情况吗？ 睡眠是否意味着它被阻塞或睡眠是另一种忙碌的等待？

在这两种情况下，都没有忙等待。 如果有人忙着等待打发时间直到你获得锁定 - 你实际上没有达到锁定的目的！ 考虑一下，假设我们有严格的单 CPU 情况（和一个愚蠢的操作系统）。 所以发生的情况是，线程 1 尝试获取锁，因为锁属于线程 B，所以线程 A 开始忙等待。 因此，CPU 永远不会从线程 A 中释放，线程 B 永远不会有机会在 CPU 上执行——最终两个线程都处于无用状态。 锁对线程对象不做任何事情。 但是锁定过程总是停放线程

Answer 5

等待、睡眠、阻塞，都是同一个意思：

1. 线程进行系统调用（获取互斥锁或信号量，等待一段时间，无论如何）

2. 操作系统取得控制权，运行调度程序，将线程标记为等待资源，同时更新其他线程的状态，然后将控制权交给准备运行的线程。 如果有多个线程准备运行，则根据调度策略选择一个。

3. 一旦资源可用（通过另一个线程进行的另一个系统调用），调度程序就会将前一个线程的状态从等待资源更新为准备好运行，并且一旦调度程序策略决定，线程就被赋予控制权所以。

只要线程在等待资源，它就不会消耗 CPU。 它没有投票。

Answer 6

简而言之，当您关心 1 个锁时，Mutex 适用于这些东西....信号量适用于多个锁。我会尝试向您发送样本。 我记得我有一些与 C 中的信号量和互斥量相关的作业。就概念而言，这在这里很有趣http://geekswithblogs.net/shahed/archive/2006/06/09/81268.aspx :)

谢谢