我是 Linux 和 Linux 线程的新手。我花了一些时间谷歌搜索来尝试了解可用于线程同步的所有函数之间的差异。我还有一些问题。
我发现了所有这些不同类型的同步，每种都有许多用于锁定、解锁、测试锁定等的功能。
- gcc原子操作
- futexes
- mutexes
- 自旋锁
- seqlocks
- rculocks
- 状况
- 信号量
我目前（但可能有缺陷）的理解是这样的：
信号量是进程范围内的，涉及文件系统（实际上我假设），并且可能是最慢的。
Futexes 可能是互斥锁、自旋锁、seqlocks 和 rculocks 使用的基本锁定机制。 Futexes 可能比基于它们的锁定机制更快。
自旋锁不会阻塞，从而避免上下文切换。然而，它们避免了上下文切换，代价是消耗 CPU 上的所有周期，直到锁被释放（旋转）。出于显而易见的原因，它们只应该在多处理器系统上使用。永远不要睡在自旋锁中。
seq 锁只是告诉您何时完成工作，如果编写者更改了工作所基于的数据。在这种情况下，你必须返回并重复该工作。
原子操作是最快的同步调用，并且可能在所有上述锁定机制中使用。您不想对共享数据中的所有字段使用原子操作。当您访问多个数据字段时，您希望使用锁（mutex、futex、spin、seq、rcu）或对锁标志进行单个原子操作。
我的问题是这样的：
到目前为止我的假设正确吗？
有谁知道各种选项的CPU周期成本吗？我正在向应用程序添加并行性，以便我们可以获得更好的挂机时间响应，但代价是每个盒子运行更少的应用程序实例。表演是最重要的考虑因素。我不想通过上下文切换、旋转或大量额外的 cpu 周期来消耗 cpu 来读写共享内存。我绝对关心消耗的CPU 周期数。
哪些锁（如果有）可以防止调度程序或中断中断线程......或者我只是一个白痴，所有同步机制都会这样做。可以防止哪些类型的中断？我可以阻止所有线程或仅阻止锁定线程的 CPU 上的线程吗？这个问题源于我担心中断持有一个非常常用的函数的锁的线程。我预计调度程序可能会调度任意数量的其他工作人员，这些工作人员可能会遇到此函数，然后因为它被锁定而阻塞。在具有锁的线程被重新调度并完成之前，大量的上下文切换将被浪费。我可以重写这个函数以最小化锁定时间，但它仍然如此普遍地被称为我想使用一个锁来防止中断......跨所有处理器。
我正在编写用户代码......所以我得到软件中断，而不是硬件中断......对吗？我应该远离任何带有“irq”一词的函数（自旋/序列锁）。
哪些锁用于编写内核或驱动程序代码，哪些锁用于用户模式？
有人认为使用原子操作让多个线程在链表中移动是疯狂的吗？我正在考虑以原子方式将当前项目指针更改为列表中的下一个项目。如果尝试有效，则线程可以安全地使用当前项目在移动之前所指向的数据。其他线程现在将沿着列表移动。
未来？有什么理由使用它们而不是互斥体？
有没有比在没有工作时使用条件使线程休眠更好的方法？
当使用 gcc 原子操作（特别是 test_and_set）时，我可以通过先进行非原子测试然后使用 test_and_set 进行确认来提高性能吗？我知道这将视具体情况而定，所以情况如下。有大量的工作项目，比如说数千个。每个工作项都有一个初始化为 0 的标志。当线程具有对该工作项的独占访问权限时，该标志将为 1。将会有很多工作线程。每当线程寻找工作时，它们都可以非原子地测试 1。如果它们读取到 1，我们就可以确定该工作不可用。如果他们读取到零，则需要执行原子 test_and_set 来确认。因此，如果原子 test_and_set 是 500 个 cpu 周期，因为它禁用了流水线，导致 cpu 进行通信并且 L2 缓存刷新/填充....并且一个简单的测试是 1 个周期....那么只要我有更好的比率当遇到已经完成的工作项目时，比例为 500 比 1……这将是一场胜利。
我希望使用互斥锁或自旋锁来保护我只希望系统上的一个线程（而不是 CPU）一次访问的代码部分。我希望谨慎使用 gcc 原子操作来选择工作并尽量减少互斥锁和自旋锁的使用。例如：可以检查工作项中的标志以查看线程是否已对其进行工作（0 = 否，1 = 是或正在进行）。一个简单的 test_and_set 告诉线程是否有工作或需要继续。我希望在有工作的时候使用条件来唤醒线程。
Thanks!
应用程序代码可能应该使用 posix 线程函数。我假设你有手册页，所以输入
man pthread_mutex_init
man pthread_rwlock_init
man pthread_spin_init
阅读它们以及对它们进行操作的函数以找出您需要的内容。
如果您正在进行内核模式编程，那么情况就不同了。您需要了解您正在做什么、需要多长时间以及它被调用的上下文，以便了解您需要使用什么。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
