我有一个混合和匹配boost :: threads与一些C++ 11标准项目的问题，这是否工作？我还没有真正测试过任何东西，但我正在使用一个系统，它使用所有boost ::线程和线程组和中断功能，您不会随标准一起开箱，所以没有任何更改。我们的boost 1.50版本并没有最新的std :: atomic和内存排序内容。我想知道是否可以使用boost线程的std :: atomic和std :: memory排序操作load/fectch_add等（acquire/release，relaxed），并且具有与std :: thread相同的结果。这些都是我的Linux机器上的所有pthreads，所以我认为答案是肯定的，我可以混合搭配。虽然，我只是想确认一下，看看有没有人在混合boost :: thread和std :: thread apis之间有任何兼容性问题。boost ::线程和std ::线程兼容性问题？
这是一个有趣的问题，自C++ 11广泛推出以来，我一直在想这个问题。
一个一般的观点，我注意到std组件的boost版本通常具有扩展，它提供比std版本更多的功能。例如，boost::bind比std::bind提供了更多的功能，提高<type_traits>比STD的人更富有，boost::thread允许线程取消/中断和性病的人不这样做，等等。
至于提高线程VS特别STD线程，你提到
...我与使用所有boost ::线程和线程组和中断，你不出去与标准箱的功能系统工作...
我想提醒一下，读中断取消不会没有价格，boost::condition_variable真的是boost::condition_variable_any当线程取消启用升压。 boost::condition_variable_any保留了自己的互斥锁，并且比原来的POSIX pthread_cond_t锁定了更多的锁定，即boost::condition_variable被设计为一个轻量级封装。线程中断功能adds measurable 5-10% speed overhead to boost::condition_variable，condition variable: std vs boost chart。
我们的boost 1.50版本并没有最新的std :: atomic和memory内存排序的东西。我想知道如果我可以使用std :: atomic和std :: memory命令操作load/fectch_add等（获取/释放，放松）与boost线程并且具有相同的结果，如果它们是std :: thread
std::atomic库不使用或依赖特定线程库仅适用于某些内置原子类型（整数和指针的宽度不得超过自然平台宽度，例如32或64位）或平台，所以你可以随意混合和匹配线程与原子库，只要你小心使用std::atomic<T>，其中T的原子性被硬件支持（也是整数和指针），你可以用std::atomic<T>::is_lock_free()来检查。
感谢您的额外信息，因为我不知道有关boost :: condition_variable真的是boost :: condition_variable_any – bjackfly
@bjackfly有时候我无法在boost中找到某些东西的定义，所以我只是运行我的编译器命令行并更改' -c'到'-E'和'-o .../xyz.o'到'-o xyx.i'来得到一个完全预处理的宏扩展翻译单元，在那里我用普通的内联找到了东西的定义在emacs中进行文本搜索。这就是我偶然发现'boost :: condition_variable'维护它自己的互斥体的原因，我就像这不是我所期望的，这是怎么回事？... –
没有任何技术原因为什么它不应该工作。 boost :: thread和std :: thread都只是本地系统线程的包装器，并且所有同步机制都与您用来生成线程的内容无关。
我会更关心的混合代码是C++ 03与C++ 11兼容的代码。在个人笔记中，我仍然认为对C++ 11的“线程化”支持基本上没有用处，而且具有非常旧的设计。 – user2485710
@ user2485710这是一个非常大胆的陈述。你是否在意为什么C++ 11线程支持“基本无用”？ – JBentley
@JBentley它不是基于任务的，它没有任何对“信号”或异步操作的支持，“std :: async”基于一个线程，还有一些关于设计和实现的其他问题， 'std :: future'，它们被封锁并且设计得不好。可能有一些有用的东西，但我真的不认为有人会用这种方式实现一些好的东西，再加上在C++ 14中会有一些修改，会影响具有不同行为的C++ 11线程模型。 – user2485710