c/c++语言开发共享无锁multithreading编程是否更容易？

无锁编程（据我所知）总是关于性能，否则在大多数情况下使用锁更简单，因此更可取。

但请注意，使用无锁编程，您最终可能会遇到实时锁定的死锁，这对于诊断来说要困难得多，因为我所知道的工具并不是为了诊断而设计的（尽管我可能在那里做错了）。

我会说，如果必须的话，只能沿着无锁的道路前进; 也就是说，你有一个场景，你有一个严重争用的锁，这会损害你的表现。 （如果没有损坏，请不要修理它）。

几个问题。

我们很快将面临64,128和256核心的桌面系统。 该领域的并行性与我们目前的2,4,8核心经验不同; 由于争用，在这种小型系统上成功运行的算法将在高度并行的系统上运行得更慢 。

从这个意义上讲，无锁是很重要的，因为它对解决可伸缩性有很大贡献。

还有一些非常特定的区域，其中无锁是非常方便的，例如Windows内核，其中存在禁止任何类型的睡眠（例如等待）的执行模式，这显然对于数据结构是非常有限的。 ，但无锁的地方提供了一个很好的解决方案。

此外，无锁数据结构通常没有故障模式; 它们实际上不会失败，基于锁的数据结构当然无法获得锁定。 不必担心失败会简化代码。

我已经编写了一个无锁数据结构库，我将很快发布。 我认为如果开发人员可以获得经过充分validation的API，那么他就可以使用它 – 无论是否无锁，都无关紧要，他不需要担心底层实现的复杂性 – 以及这是要走的路。

它还涉及可扩展性。 为了获得性能提升，您必须将您正在处理的问题并行化，以便可以跨多个核心扩展它们 – 越多越好。

传统的方法是锁定需要并行访问的数据结构，但是你可以运行的线程越多，就越平行，这就成了瓶颈。

是的，这是关于表现……

对于抢占式线程，在持有锁时挂起的线程可以阻止线程，否则这些线程会向前推进。 无锁无法解决这个问题，因为根据Herlihy的定义，其他一些线程总是能够取得进展。

对于非抢占式线程，它并不重要，因为即使是基于自旋锁的解决方案也不受Herlihy定义的锁定。

这是关于性能 – 但也有关于multithreading负载的能力：

随着锁BLOCK其他线程的执行，程序变慢。 随着primefaces操作连续执行（一个接一个），没有阻塞*。

（*）只要尝试访问同一资源的并发CPU数量不会产生瓶颈 – 但我们还没有足够的CPU核心将此视为一个问题。

我已经处理了这个问题，为我正在处理的服务器编写一个等待免费 （无锁等待状态）Key-Value存储。

像Tokyo Cabinet（甚至TC-FIXED，一个简单的数组）这样的库依赖于锁来保持数据库的完整性：

“当写作线程正在操作数据库时，其他读取线程和写入线程被阻止” （东京内阁文档）

没有并发性的测试结果（单线程测试）：

SQLite time: 56.4 ms (a B-tree) TC time: 10.7 ms (a hash table) TC-FIXED time: 1.3 ms (an array) G-WAN KV time: 0.4 ms (something new which works, but I am not sure a name is needed) 

通过并发（在同一个DB中写入和读取多个线程），只有G-WAN KV在同一测试中幸存下来，因为（与其他测试相比）它永远不会阻塞。

所以，是的，这个KV商店使开发人员更容易使用它，因为他们不必关心线程问题。 然而，以这种方式工作并不是微不足道的。

我相信我看到一篇文章在数学上certificate了任何算法都可以以无等待的方式编写（这基本上意味着你可以确保每个线程总是朝着它的目标前进）。 这意味着它可以应用于任何大型应用程序（毕竟，程序只是一个具有许多参数的算法），并且因为等待自由确保其中不会发生死锁/活锁（只要它没有’它有防止它真正等待的错误），它确实简化了程序的那一面。 另一方面，数学certificate与实际实现代码本身相差甚远（AFAIK，甚至没有可以在PC上运行的完全无锁的链表，我见过覆盖大多数部分的链表，但是它们通常要么不能处理一些常用function，要么某些function需要锁定结构。

另外，我还发现了另一个证据，表明由于概率定律和其他各种因素，任何无锁算法实际上都可以被认为是无等待的。

它仍然太长：2句话摘要。

无锁数据结构不是基于锁的multithreading编程的灵丹妙药（即使TM不是。如果你真的需要可扩展性并且在锁争用方面遇到麻烦，那么考虑无锁数据结构。