POSIXミューテックスがfutexより重いまたは遅いと見なされるのはなぜですか？pthreadミューテックスタイプのオーバーヘッドはどこから来ていますか？pthreadミューテックスはfutexに基づいていると聞きました。競合がない場合は、カーネルを呼び出さないでください。その場合、pthreadミューテックスはfutexの周りの単なる「ラッパー」であるように見えます。
オーバーヘッドは単に関数ラッパー呼び出しにあり、ミューテックス関数がfutexを「セットアップ」する必要がありますか（つまり、基本的にpthreadミューテックス関数呼び出しのスタックのセットアップ）？または、pthread mutexで行われている追加のメモリバリア手順はありますか？
Futexは、pthreadミューテックスのパフォーマンスを向上させるために作成されました。NPTLはfutexを使用します。LinuxThreadsはfutexよりも古いものであり、これが「遅い」考慮事項になると思います。NPTLミューテックスには追加のオーバーヘッドがあるかもしれませんが、それほど多くはないはずです。
編集： 実際のオーバーヘッドは基本的に次のもので構成されます。
したがって、数サイクル（通常の場合）から数サイクル+ブランチの予測ミス+追加のキャッシュミス（非常に最悪の場合）。
あなたの質問に対する簡単な答えは、futexは可能な限り効率的に実装されることが知られているのに対し、pthreadミューテックスは実装されている場合とされていない場合があるということです。少なくとも、pthreadミューテックスにはミューテックスのタイプの決定に関連するオーバーヘッドがありますが、futexにはありません。したがって、futexは、誰かがfutexよりも軽い構造を考えて、それをデフォルトのミューテックスに使用するpthreads実装をリリースするまで、ほとんどの場合、少なくともpthreadミューテックスと同じくらい効率的です。
技術的に言えば、pthreadミューテックスはfutexよりも遅くも速くもありません。pthreadは単なる標準APIであるため、遅いか速いかは、そのAPIの実装によって異なります。
特にLinuxでは、pthreadミューテックスはfutexとして実装されているため、高速です。実際には、futex API自体は非常に使いにくく、glibcに適切なラッパー関数がなく、移植性のないアセンブリでコーディングする必要があるため、使用したくありません。幸いなことに、glibcのメンテナは、pthreadmutexAPIの内部でこれらすべてをすでにコーディングしています。
現在、ほとんどのオペレーティングシステムはfutexを実装していなかったため、プログラマーは通常、pthreadミューテックスがpthreadミューテックスの通常の実装から得られるパフォーマンスであると意味します。これは低速です。
したがって、POSIXに準拠しているほとんどのオペレーティングシステムでは、pthread mutexがカーネル空間に実装されており、futexよりも低速であるというのは統計的な事実です。Linuxでは、同じパフォーマンスが得られます。pthreadミューテックスがユーザースペースに実装されているため（競合のない場合）、パフォーマンスが向上している他のオペレーティングシステムがある可能性がありますが、現時点ではLinuxしか認識していません。
それらは可能な限りユーザースペースにとどまるため、つまり必要なシステムコールが少なくなります。これは、ユーザーモードとカーネルモードの間のコンテキストスイッチにコストがかかるため、本質的に高速です。
POSIXスレッドについて話すときは、カーネルスレッドについて話していると思います。システムコールを必要としないが、独自の他の問題があるPOSIXスレッドの完全なユーザースペース実装を持つことは完全に可能です。
私の理解では、futexはカーネルPOSIXスレッドとユーザースペースPOSIXスレッドの中間にあります。
AMD64では、futexは4バイトですが、NPTL pthread_mutex_tは56バイトです！はい、かなりのオーバーヘッドがあります。