もちろん、それを維持しますが、C ++標準が保証されれば、それはどれほど役立つでしょう。
新しい標準の出現による同期プリミティブ(Mutex、条件変数)はどうですか?
std :: threadとは対照的に、pthreadをマスターするのは難しいと思いますか?
Cは消えません。POSIXはなくなることはありません。POSIX用にCで記述されたマルチスレッドコードがなくなることはありません。したがって、pthreadがなくなることはありません。
std :: threadの多くの実装は、内部でpthreadを使用します。
「PthreadsAPIは、ANSI / IEEEPOSIX1003.1-1995標準で定義されています。」--POSIXスレッドプログラミングhttps://computing.llnl.gov/tutorials/pthreads/
POSIXはオペレーティングシステムの標準です。C++0Xは言語標準です。2番目にスレッドがあっても、最初のスレッドは廃止されません。2つは最初に実装できるように、2つの間にコラボレーションがあります。(そして、POSIX用のC ++インターフェースを持つための作業も進行中です)。
pthreadをサポートするプラットフォームでのC++実装は、おそらくpthreadの観点から言語機能を実装します。したがって、廃止されることはありません。
std :: threadには、優先順位のサポート、スレッドスタックのサイズの制御、スケジューリングポリシーの制御、またはプロセッサアフィニティの制御は含まれていません。
クラスと優先順位のスケジューリングは、リアルタイムシステムにとって非常に重要です。プロセッサの親和性とスタックサイズは、高性能システムにとって非常に重要です。このようなアプリケーションは、おそらくstd :: threadに加えて、おそらくstd :: threadの代わりに、おそらくstd :: threadとともに必要な機能を公開するベンダー拡張機能を介して、ネイティブスレッド機能を引き続き使用します。
技術的な比較に関係なく、すべての主要なプラットフォーム/ベンダーから合理的にまともなC ++ 98のサポートを得るには、10年の大部分を要しました。これだけで、2020年にpthreadが強力になることが保証されます。
たぶん、新しいコードの場合、標準にあるものを使用するのが正しい方法です。主要なコンパイラーの実装がどれほど堅実であるかを待つ必要があります。ただし、現在機能していると仮定すると、既存のコードをpthreadから変換してもあまりメリットはありません。これには、すでにpthreadの経験が豊富なショップで作成された新しいコードが含まれます。
少なくともブーストスレッドについては正しい:
setpshared属性をサポートしていませんそうではありません...OSAPIが廃止されたと見なされる前にやるべきことがいくつかあります。(そしてBTWスレッドはpthreadを介して実装されます)