问题标签 [spinlock]

我的多线程代码中有很多自旋锁，大部分时间它们都在等待其他线程工作，因此会占用大量的 CPU 资源。在 linux 中，我通常使用 pthread_cond_wait 和 pthread_cond_signal 来暂停线程并在收到信号时唤醒。boost库中有这样的东西吗？快速浏览一下，我找不到任何东西。

视觉工作室 2005

我正在使用自旋锁来保护一个非常小的关键部分。争用很少发生，因此自旋锁比常规互斥锁更合适。

我当前的代码如下，并假设 x86 和 GCC：

所以我想知道：

• 这段代码正确吗？它是否正确地确保了互斥？
• 它适用于所有 x86 操作系统吗？
• 它也适用于 x86_64 吗？在所有操作系统上？
• 是最优的吗？
  • 我见过使用比较和交换的自旋锁实现，但我不确定哪个更好。
  • 根据 GCC atomic builtins 文档（http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html），还有__sync_lock_release. 我不是记忆障碍方面的专家，所以我不确定我是否可以使用它而不是__sync_synchronize.
  • 我正在针对没有争用的情况进行优化。

我根本不在乎争吵。可能有 1 个，也可能有 2 个其他线程试图每隔几天锁定一次自旋锁。

您多久发现自己在代码中实际使用自旋锁？遇到使用繁忙循环实际上优于使用锁的情况有多常见？
就个人而言，当我编写某种需要线程安全的代码时，我倾向于使用不同的同步原语对其进行基准测试，而且就目前而言，使用锁似乎比使用自旋锁提供更好的性能。不管我实际持有锁的时间有多短，我在使用自旋锁时收到的争用量远远大于我从使用锁中获得的量（当然，我在多处理器机器上运行我的测试）。

我意识到它更有可能在“低级”代码中遇到自旋锁，但我很想知道您是否发现它在更高级的编程中有用？

我使用 Windows 中的 Interlocked 函数制作了一个非常简单的自旋锁，并在双核 CPU（增加变量的两个线程）上对其进行了测试；

该程序似乎工作正常（每次都给出相同的结果，但不使用同步时情况并非如此），但英特尔 Parallel Inspector表示在值 += j处存在竞争条件（请参见下面的代码）。使用关键部分而不是我的 SpinLock 时，警告会消失。

我的 SpinLock 实现是否正确？这真的很奇怪，因为所有使用的操作都是原子的并且具有适当的内存屏障并且它不应该导致竞争条件。

测试程序：

在我的 Ubuntu 机器上，正在运行的默认内核映像是为 smp ( CONFIG_SMP=y) 构建的。但是这台机器只有1个cpu。

在单处理器内核上，与 smp 内核不同，spin_lock/unlock是空函数。那么在这个设置中是如何表现的spin_lock()呢？spin_unlock()

这种 smp 特定代码是否会对性能产生影响？

我一直想知道它们是什么：每次我听到它们时，未来派飞轮式设备的图像都会在我脑海中翩翩起舞（滚动？）......

这些是什么？

我正在使用以下自旋锁方法：

这基本上等待用户执行一个操作，然后返回它。目前有些东西在继续之前要求用户回答，这就是我等到收到输入的原因。但是我想知道这是否效率低下，如果我们等待一段时间（即 <= 30 秒）会减慢运行此应用程序的电脑的速度。是否有任何其他使用这种方法的替代方法，即锁、信号量，如果是的话，语法是什么？

谢谢，

阿里

我编写了一个写入共享内存的“服务器”程序，以及一个从内存中读取的客户端程序。服务器有不同的“通道”可以写入，它们只是不同的链接列表，它也可以附加项目。客户端对某些链表感兴趣，并希望读取添加到这些链表中的每个节点，并尽可能降低延迟。

我有两种方法供客户使用：

1. 对于每个链表，客户端保留一个“书签”指针以保持其在链表中的位置。它循环循环链表，一遍又一遍地遍历所有链表（它永远循环），如果可以的话，每次将每个书签向前移动一个节点。是否可以由节点的“下一个”成员的值确定。如果它是非空的，那么跳转到下一个节点是安全的（服务器自动将它从空切换到非空）。这种方法工作正常，但是如果有很多列表要迭代，并且只有少数列表正在接收更新，那么延迟就会变差。

2. 服务器给每个列表一个唯一的 ID。每次服务器将项目附加到列表时，它也会将列表的 ID 号附加到主“更新列表”。客户端只保留一个书签，一个书签到更新列表中。它无休止地检查书签的下一个指针是否为非空（while(node->next_ == NULL) {}），如果是，则继续读取给定的 ID，然后处理链表上具有该 ID 的新节点。从理论上讲，这应该可以更好地处理大量列表，因为客户端不必每次都遍历所有列表。

当我对这两种方法的延迟进行基准测试时（使用 gettimeofday），令我惊讶的是＃2 非常糟糕。对于少量链表，第一种方法的延迟通常低于 20us。第二种方法会有少量低延迟，但通常在 4,000-7,000us 之间！

通过在这里和那里插入 gettimeofday，我确定方法 #2 中所有增加的延迟都花在循环中，反复检查下一个指针是否为非空。这让我很困惑；就好像一个流程中的更改需要更长的时间才能使用第二种方法“发布”到第二个流程。我假设正在进行某种我不明白的缓存交互。这是怎么回事？

更新：最初，方法 #2 使用条件变量，因此如果node->next_ == NULL它会等待条件，服务器会在每次发布更新时通知该条件。延迟是相同的，并且试图弄清楚为什么我将代码减少到上述方法。我在多核机器上运行，所以一个进程自旋锁不应该影响另一个。

更新 2： node->next_ 是不稳定的。

在 SMP 机器上，我们必须使用 spin_lock_irqsave而不是spin_lock_irq来自中断上下文。

为什么我们要保存标志（包含 IF）？

是否有另一个中断程序可以中断我们？

我不太确定在用户模式线程中旋转 volatile 变量是否安全，以实现轻量级 spin_lock，我查看了 tbb 源代码，tbb_machine.h:170，

正如我所见， atomic_backoff 类中没有栅栏。而从其他用户模式的 spin_lock 实现中，它们中的大多数使用 CAS（比较和交换）。