linux线程同步

Question

我是 linux 和 linux 线程的新手。我花了一些时间在谷歌上搜索，试图了解所有可用于线程同步的函数之间的差异。我还有一些问题。

我发现了所有这些不同类型的同步，每个同步都有许多用于锁定、解锁、测试锁定等的功能。

gcc 原子操作

futexes

互斥锁

自旋锁

序列锁

rculocks

条件

信号量

我目前(但可能有缺陷)的理解是:

信号量是进程范围的，涉及文件系统(实际上我认为)，并且可能是最慢的。

Futex 可能是互斥锁、自旋锁、序列锁和 rculock 使用的基本锁定机制。 Futex 可能比基于它们的锁定机制更快。

自旋锁不会阻塞，从而避免上下文切换。然而，它们以消耗 CPU 上的所有周期直到释放锁(自旋)为代价来避免上下文切换。出于显而易见的原因，它们应该仅用于多处理器系统。永远不要睡在自旋锁中。

如果作者更改了工作所基于的数据，则 seq 锁只会告诉您何时完成工作。在这种情况下，您必须返回并重复工作。

原子操作是最快的同步调用，并且可能用于上述所有锁定机制。您不想对共享数据中的所有字段使用原子操作。当您访问多个数据字段时，您想对锁标志使用锁(互斥锁、futex、spin、seq、rcu)或单个原子操作。

我的问题是这样的:

到目前为止，我的假设是否正确？

有谁知道各种选项的 CPU 周期成本？我正在为应用程序添加并行性，因此我们可以获得更好的挂机时间响应，但代价是每盒运行更少的应用程序实例。表演是最重要的考虑因素。我不想通过上下文切换、旋转或大量额外的 cpu 周期来消耗 cpu 来读取和写入共享内存。我绝对关心消耗的 CPU 周期数。

哪个(如果有)锁可以防止调度程序或中断中断线程......或者我只是一个白痴，所有同步机制都这样做。什么类型的中断被阻止？我可以在锁定线程的 CPU 上阻塞所有线程或线程吗？这个问题源于我害怕中断持有非常常用函数锁的线程。我希望调度程序可能会调度任意数量的其他工作人员，这些工作人员可能会遇到这个函数，然后因为它被锁定而阻塞。在重新调度并完成具有锁的线程之前，将浪费大量上下文切换。我可以重写这个函数来最小化锁定时间，但它仍然如此普遍，我想使用一个防止中断的锁......跨所有处理器。

我正在编写用户代码......所以我得到了软件中断，而不是硬件中断......对吗？我应该远离任何包含“irq”一词的函数(自旋/序列锁)。

哪些锁用于编写内核或驱动程序代码，哪些用于用户模式？

有没有人认为使用原子操作让多个线程在链表中移动很疯狂？我想以原子方式将当前项目指针更改为列表中的下一个项目。如果尝试成功，则线程可以安全地使用当前项在移动之前指向的数据。其他线程现在将沿着列表移动。

futex？有什么理由使用它们而不是互斥体？

有没有比在没有工作时使用条件使线程休眠更好的方法？

当使用 gcc 原子操作，特别是 test_and_set 时，我可以通过先进行非原子测试然后使用 test_and_set 确认来提高性能吗？我知道这将视具体情况而定，所以就是这种情况。有大量的工作项目，比如数千个。每个工作项都有一个初始化为 0 的标志。当线程对工作项具有独占访问权限时，该标志将为 1。会有很多工作线程。任何时候线程正在寻找工作，它们都可以非原子地测试 1。如果它们读取 1，我们肯定知道该工作不可用。如果他们读到一个零，他们需要执行原子 test_and_set 来确认。因此，如果原子 test_and_set 是 500 个 cpu 周期，因为它禁用了流水线，导致 cpu 通信和 L2 缓存刷新/填充 .... 一个简单的测试是 1 个周期 .... 那么只要我有更好的比率当遇到已经完成的工作项目时，500比1......这将是一场胜利。

我希望使用互斥锁或自旋锁来严格保护我一次只希望 SYSTEM 上的一个线程(而不是 CPU)访问的代码部分。我希望谨慎使用 gcc atomic ops 来选择工作并尽量减少互斥锁和自旋锁的使用。例如:可以检查工作项中的标志以查看线程是否已经工作(0=否，1=是或正在进行)。一个简单的 test_and_set 告诉线程它是否有工作或需要继续。我希望在有工作时使用条件来唤醒线程。

谢谢!

Answer 1

应用程序代码可能应该使用 posix 线程函数。我假设你有手册页所以输入

man pthread_mutex_init
man pthread_rwlock_init
man pthread_spin_init

阅读它们以及对它们进行操作的函数，以确定您需要什么。

如果您正在进行内核模式编程，那么情况就不同了。您需要了解自己在做什么、需要多长时间以及调用它的上下文，才能知道需要使用什么。