blocks|key|1330729|text|在你的应用程序中尝试这两种方法，看看哪一种表现最好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1330730|通常，当队列几乎总是有条目时，轮询无锁队列的效果最好，当队列几乎总是空的时候，阻塞队列的效果最好。|1330731|阻塞队列的缺点是延迟，通常是2-20+uS的数量级，这是由于内核信号。这可以通过设计系统来缓解，使使用者线程在每个排队项上所做的工作花费的时间比这个间隔长得多。|1330732|非阻塞队列的缺点是在轮询空队列时浪费CPU和内存带宽。这可以通过设计系统以使队列很少为空来缓解。|1330733|正如评论者已经暗示的那样，在单CPU系统中，非阻塞队列是一个非常糟糕的想法。|1330734|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Try both in your app, see which performs best.

Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.

The downside of blocking queues is latency, typically of the order of 2-20 uS, due to kernel signaling. This can be mitigated by designing the system so that the work done by the consumer threads on each queued item takes much longer than this interval.

The downside of non-blocking queues is the waste of CPU and memory bandwidth while polling an empty queue. This can be mitigated by designing the system so that the queue is rarely empty.

As already hinted at by commenters, a non-blocking queue is a very bad idea on single-CPU systems.

blocks|key|3142675|text|(补充)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3142676|从1.54开始，您应该意识到一些要求|3142677|boost::lockfree::queue|offset|length|style|CODE|3142678|3142679|T必须具有复制构造函数|unordered-list-item|3142680|T必须具有简单赋值运算符|3142681|T必须具有简单析构函数|3142682|3142683|boost::lockfree::stack|3142684|3142685|3142686|3142687|boost::lockfree::spsc_queue|3142688|3142689|T必须具有默认的constructor|3142690|T必须是可复制的|3142691|3142692|entityMap|0|LINK|mutability|MUTABLE|url|http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/queue.html|1|http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/stack.html|2|http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/spsc_queue.html^0|0|0|0|M|0|M|0|0|0|0|0|0|0|0|M|0|M|1|0|0|0|0|0|R|0|R|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1J|8|@$F|1K|G|1L|H|I]]|9|@$F|1M|G|1N|1|1O]]|A|$]]|$1|J|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1Q|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|1R|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|1S|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1U|8|@$F|1V|G|1W|H|I]]|9|@$F|1X|G|1Y|1|1Z]]|A|$]]|$1|U|3|-4|5|6|7|20|8|@]|9|@]|A|$]]|$1|V|3|L|5|M|7|21|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|23|8|@$F|24|G|25|H|I]]|9|@$F|26|G|27|1|28]]|A|$]]|$1|Z|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|10|3|11|5|M|7|2A|8|@]|9|@]|A|$]]|$1|12|3|13|5|M|7|2B|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|16|$17|$5|18|19|1A|A|$1B|1C]]|1D|$5|18|19|1A|A|$1B|1E]]|1F|$5|18|19|1A|A|$1B|1G]]]]

(Supplemental)

As of 1.54, you should be aware of some requirements

<a href="http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/queue.html" rel="noreferrer"><code>boost::lockfree::queue</code></a>

<ul>
<li>T must have a copy constructor</li>
<li>T must have a trivial assignment operator </li>
<li>T must have a trivial destructor</li>
</ul>

<a href="http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/stack.html" rel="noreferrer"><code>boost::lockfree::stack</code></a>

<ul>
<li>T must have a copy constructor</li>
</ul>

<a href="http://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/spsc_queue.html" rel="noreferrer"><code>boost::lockfree::spsc_queue</code></a>

<ul>
<li>T must have a default constructor</li>
<li>T must be copyable</li>
</ul>

blocks|key|192200|text|您还可以使用无锁队列来避免实时应用程序中的优先级反转。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|192201|例如，Android上的OpenSL在高优先级线程上提供了音频缓冲队列回调。如果这个线程必须等待低优先级线程持有的锁，那么它的高优先级调度就毫无意义，回调就会变得不规律，并且您可能会开始不足音频缓冲区--这会导致一些令人不快的响声。|192202|entityMap^0|L|5|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

You might also use a lock-free queue to avoid priority inversion in a real-time application. 

For example, OpenSL on Android provides audio buffer queue callbacks on a high-priority thread. If this thread has to wait for locks held by a lower priority thread, its high-priority scheduling counts for nothing, the callbacks become irregular, and you may start to underrun your audio buffer -- which results in some unpleasant popping sounds.

blocks|key|1330828|text|这个决定可以归结为提出这样一个问题：“锁争用会成为任务要解决的问题吗？”|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1330829|并发环境中的锁定解决了两个不同的问题|1330830|1330831|正确性:确保代码实际执行预期的操作。防止来自其他threads.|unordered-list-item|1330832|throughput/scalability:的干扰允许通过系统的并发操作的持续的高“流”。允许通过添加更多资源来扩展系统性能。|1330833|1330834|这两个问题是对立的目标。经典的方法是使用全局锁保护共享数据结构。这确保了100%25的正确性，但它阻止了性能的扩展，特别是并发级别超过一定程度，因为共享锁导致了“流量拥塞”。|1330835|顺便说一句，在使用术语“无锁”时需要小心。严格地说，协作操作永远不可能是100%25无锁的。但是可以巧妙地安排协作，从而减少阻塞对那些真正需要并发访问相同元素的合作伙伴的影响。|1330836|entityMap^0|J|3|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|Z|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|10|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|12|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|13|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|T|$]]

The decision boils down to asking the question: "will lock contention be a problem for the task to be solved?"

Locking in a concurrent environment addresses two distinct concerns

<ul>
<li>correctness: ensure that the code actually does what is intended. Prevent interference from other threads.</li>
<li>throughput/scalability: allow a sustained high "flow" of concurrent operations passing through the system. Allow to scale up the performance of the system by adding more resources.</li>
</ul>

These two concerns are antagonistic goals. The classical approach is to protect a shared datastructure with global locks. This ensures 100% correctness, but it prevents scaling up the performance and especially the concurrency level above a certain degree, since the shared locks lead to "traffic congestion"

Incidentally, you need to be careful when using the term "lock free". Strictly speaking, collaborative operations can never be 100% lock free. But is is possible to arrange the collaboration cleverly, so to reduce the impact of blocking to those partners which really need to access the same element concurrently.

I'm quite new in multithreading programming, I just know the most common Producer-Consumer-Queue.
I'm using the boost c++ libraries and I don't know if is better use boost::lockfree::queue or a wrapper class around std::queue that is using `mutex` and `condition_variable`.


Where is better using lock free data structures and where is better is use a simple implementation based on `mutex` and `condition_variables`?

boost c++ lock-free queue vs shared queue

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我是多线程编程的新手，我只知道最常见的生产者-消费者-队列。我正在使用boost c++库，我不知道使用boost::lockfree::queue还是使用使用mutex和condition\_variable的std::queue的包装类更好。使用无锁数据结构更好，使用基于mutex和condition\_variables的简单实现更好

问boost c++无锁队列与共享队列
EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问boost c++无锁队列与共享队列EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问boost c++无锁队列与共享队列
EN