Linuxのスレッド定義はシステムコールに依存していますか？

クローン

clone()/systemcalls のマニュアルページで以下をclone3()見つけました。

CLONE_THREAD（Linux 2.4.0以降）。

CLONE_THREAD が設定されると、子プロセスは呼び出しプロセスと同じスレッドグループに配置されます。 CLONE_THREAD に関する残りの議論をより読みやすくするには、「スレッド」という用語は、スレッドグループのプロセスを表すために使用される。。

したがって、私が理解したように、cloneスレッドはCLONE_THREADフラグが設定された状態で生成されます（したがって、呼び出し元と同じスレッドグループに属します）。

ピューテックス

しかし、例えば、マニュアルページを見ると、次のような内容がfutex()見つかりました。

FUTEX_PRIVATE_FLAG(Linux 2.6.22以降)

このオプションビットは、すべてのfutex操作に使用できます。これはfutexがプロセスプライベートであり、他のプロセスと共有されていないことをカーネルに伝えます（つまり、同期にのみ使用されます）。同じプロセスのスレッド）。これにより、カーネルは追加のパフォーマンス最適化を実行できます。

これは定義に関連しているように見えますが、clone完全に関連しているわけではありません。クローンのようにスレッドが生成された場合（つまり、CLONE_THREADフラグが立てられる）、生成されたタスクも〜しなければならない仮想マシンを共有します。ただし、スレッドではなく（複製のように）2つのタスクを作成し、まだVMを共有することは可能です（のみ指定CLONE_VM）。しかし、FUTEX：新しいプライベートfutex記事/パッチでfutexの最適化は、物理アドレスではなく_PRIVATEfutex単語の仮想アドレスを使用することです。したがって、...で作成されたタスクでプライベートfutexを使用できますが、CLONE_VMその人はfutex()これを禁止します。

しかし、これは重要な問題ではありません。マニュアルは（外見上不要に見える）制限を課しますが、何も壊さない。まあ、ここにもっと興味深い例があります。

閉鎖

システムコールマニュアルからclose()：

また、次のシナリオを検討してください。糸 同じファイル記述子に対して操作を実行します。

(1) 1 ワイヤー ファイル記述子へのI / Oシステムコールがブロックされました。たとえば、いっぱいのパイプに書き込もうとしたり（2）、現在利用可能なデータがないストリームソケットから読み込もうとします（2）。

(2)他ワイヤーファイル記述子を閉じます。

この場合、動作はシステムによって異なります。 <...>

明らかに、ここでは2つの操作がファイル記述子テーブルを共有していると仮定していますが、スレッドになること（クローンと同じように）はファイル記述子テーブルを共有すると主張する必要はありません。

作成操作を使用するとすべてがCLONE_THREAD|...|CLONE_FILES問題ありませんがCLONE_THREAD|...（許可されている場合）、2つのスレッド（複製のように）はファイル記述子を共有せず、複製された操作を使用することは...|CLONE_FILES次のとおりです。いいえ糸ですがするファイル記述子を共有！

質問

まず、これは（少なくとも例close()）マニュアルのバグですか？clone()システムコールが設計される前に作成されたためですか？それとも私が何かを見逃しているのでしょうか？

一般的に：マニュアルの特定のシステムコールで「スレッド」という用語を使用するときに何を意味するのか、どうすればわかりますか？

特に（将来のカーネルバージョンで動作するコードを書くと仮定するとき）、VMを共有しますが、スレッドは共有しないタスク（たとえば、レプリケーション）でプライベートfutexを使用できますか？closeスレッドから呼び出すときにスレッドセーフですか（クローンなど）。いいえ常識的にファイル記述子テーブルを共有しますか？