C ++ 11标准::线程与posix线程
为什么我应该在实践中更喜欢这个或那个？ 什么是技术差异，除了std::thread是一个类？
如果你想在许多平台上运行代码，请参阅Posix主题。 他们几乎可以在任何地方使用，并且相当成熟 另一方面，如果你只使用Linux / gcc std::thread ，那么它的性能就非常好 – 它具有更高的抽象层次，非常好的接口，并且与其他C ++ 11类很好地搭配。
不幸的是，C ++ 11 std::thread类在每个平台上都不能可靠地工作（即使C ++ 11似乎可用）。 例如，在原生的Android std::thread或Win64中，它只是不起作用，或者有严重的性能瓶颈（截至2012年）。
一个好的替代是boost::thread – 它和std::thread （实际上来自同一个作者）非常相似，并且工作可靠，当然，它引入了另一个来自第三方库的依赖。
编辑：截至2017年， std::thread大多在原生Android上工作。 一些类，如std::timed_mutex仍然没有实现。
在支持pthread的环境（例如：libstdc ++）中， std::thread库在pthread上实现。
我认为两者之间的巨大差异是抽象的。 std::thread是一个C ++类库。 std::thread库包含许多抽象特性，例如：作用域锁，recursion互斥体，future / promisedevise模式实现等等。
std::thread提供跨Windows，MacOS和Linux等不同平台的可移植性。
正如@hirshhornsalz在下面的评论和相关的回答https://stackoverflow.com/a/13135425/1158895中所提到的，; std::thread在所有平台上可能还没有完成。 即使（不久的将来），它也应该比pthread更受欢迎，因为它会让你的应用程序更具前瞻性。
对于我来说，决定性的技术上的区别是std中没有信号处理原语，而不是pthread。 在单独使用std的Unix进程中无法正确指示信号处理是AFAIK在使用std :: thread时的一个致命缺陷，因为它阻碍了build立真正的multithreading信号处理模式来处理所有专用信号线程和阻止他们在rest。 你不得不假设std :: thread是使用pthreads实现的，希望在使用pthread_sigmask的时候最好。 在企业的Unix系统编程中正确处理信号是不可协商的。
截至2016年，std :: thread是一个玩具; 就那么简单。
OpenMP
是基于SMP的标准化multithreading标准，已经在Linux和Windows上工作了十多年。 所有编译器（包括GCC和Microsoft Visual Studio）都默认使用OpenMP。
在使用OpenMP时需要注意的一点是，如果线程多于CPU内核，那么由于上下文切换相关的开销，性能会下降。 第二件要记住的是，实际的操作系统级别的线程的初始化相对昂贵。 初始化是一秒钟的一小部分，但是在一些应用中，非常小的部分累加到可观的费用上。
对于软件体系结构需求相关的并发性您可能希望search“轻量级线程”或“绿色线程”的一些实现，而不是使用OpenMP。 不同之处在于OpenMP线程是实际的操作系统级别线程，但是“绿色线程”可以只是使用less量的实际线程执行的“模拟线程”。
