为什么在实践中我应该更喜欢一个或另一个?std::thread
除了是一个类之外,还有什么技术差异?
4 回答
如果您想在许多平台上运行代码,请选择 Posix Threads。它们几乎随处可见,并且非常成熟。另一方面,如果您只使用 Linux/gccstd::thread
则完全没问题——它具有更高的抽象级别、非常好的接口并且可以与其他 C++11 类很好地配合使用。
std::thread
不幸的是,即使 C++11 似乎可用,C++11类也不能(还)在每个平台上可靠地工作。例如,在原生 Androidstd::thread
或 Win64 中,它只是无法正常工作或存在严重的性能瓶颈(截至 2012 年)。
一个很好的替代品是boost::thread
- 它与(实际上它来自同一作者)非常相似std::thread
并且工作可靠,但是,当然,它引入了来自第三方库的另一个依赖项。
编辑:截至 2017 年,std::thread
主要适用于原生 Android。一些类,如std::timed_mutex
仍未实现。
该std::thread
库是在支持 pthread 的环境中的 pthread 之上实现的(例如:libstdc++)。
我认为两者之间的最大区别是抽象。std::thread
是一个 C++ 类库。该std::thread
库包含许多抽象特性,例如:作用域锁、递归互斥锁、future/promise 设计模式实现等。
std::thread
提供跨不同平台的可移植性,如 Windows、MacOS 和 Linux。
正如@hirshhornsalz 在下面的评论和相关答案https://stackoverflow.com/a/13135425/1158895中提到的,std::thread
可能尚未在所有平台上完成。即使如此,(它将在不久的将来)它应该比pthread
's 更受青睐,因为它应该使您的应用程序更加面向未来。
对我来说,决定性的技术差异是 std 中没有信号处理原语,而不是 pthreads。无法单独使用 std 在 Unix 进程中正确指示信号处理是 AFAIK 使用 std::thread 时的一个令人衰弱的缺陷,因为它禁止设置真正的多线程信号处理模式来处理专用的所有信号线程并在其余部分阻止它们。您被迫假设 std::thread 是使用 pthreads 实现的,并希望在使用 pthread_sigmask 时获得最好的结果。在企业的 Unix 系统编程中,正确处理信号是不可协商的。
截至 2016 年,std::thread 是一个玩具;就那么简单。