問題タブ [nptl]

nptl/glibc にはかなり大きな commit-git がありました。

http://sourceware.org/git/?p=glibc.git;a=commit;h=e51deae7f6ba2e490d5faeb8fbf4eeb32ae8f1ee

Ulrich Drepper と Jakub Jelinek @ 2007

lll_lock/lll_unlock の変更に興味があります

SMP コードでは、lll_unlock が次のように変更されました。

ここ$0で、 はfutex アドレスのゼロであり、%P3MULTIPLE_THREADS_OFFSET 定数です。

それで、何に保存されますか$gs:MULTIPLE_THREADS_OFFSET（別名$gs:(offsetof (tcbhead_t, multiple_threads))？この値はプログラムの存続期間中にどのように変更されますか？

NPTLスレッドとPOSIXスレッドの基本的な違いは何ですか？これら2つはどのように進化しましたか？

glibcのtls.hからの次のコードセグメントが何をしているのか、そしてその理由を理解しようとしています。

fsレジスタに格納されている値をに移動するという基本的な動作は理解できたと思います__seg。ただし、いくつか質問があります。

1. 私の理解では、fs16ビットだけです。これは正しいです？値がクアッドワードメモリの場所に移動するとどうなりますか？これは、上位ビットが0に設定されることを意味しますか？

2. __segさらに重要なことに、セグメントの開始時に宣言される変数のスコープは、このセグメントに限定されていると思います。では、どのように__seg役立ちますか？glibcの作者にはこれを行う正当な理由があると 確信していますが、ソースコードを見てそれが何であるかを理解することはできません。

このコードのアセンブリを生成しようとしましたが、次のようになりましたか？

eaxしたがって、私の場合は、に使用されたように見え__segます。しかし、それが常に起こっているのか、それとも私がコンパイルした小さなテストファイルで起こったのかはわかりません。それが常に使用されるのであれば、eaxなぜアセンブリはそのように書かれないのでしょうか？__segコンパイラが他のレジスタを選択する可能性がある場合、マクロの最後でスコープから外れるため、プログラマはどのレジスタにアクセスするかをどのように知るのでしょうか。最後に、このマクロがglibcソースコードでgrepしたときにどこにも使用されていなかったため、その目的が何であるかについてさらに混乱が生じました。コードが何をしているのか、そしてその理由についての説明はありがたいです。

glibc に組み込まれている linuxthreads の代わりに nptl を使用して特定のバイナリをテストできるかどうかを知りたいです。glibc は特定のハードウェア/ソフトウェアで提供されているものであり、すべてを壊したくないため、glibc を再コンパイルしたくありません。この実装をテストして、何が得られるかを確認したいだけです

前もって感謝します

カーネル レベルのスレッドを実装する必要がありますが、ネットで検索しているときに、Linux でカーネル レベルのスレッドを作成するには 3 つの方法があることがわかりました。

1. NPTL
2. kthread
3. Linuxスレッド

linuxThreads は現在放棄されているとどこかに書かれていました。しかし、NPTL と kthread の現在のサポートを見つけることができません。また、それらの機能の使用方法を簡単に説明できるソースを見つけることができません。

現在サポートされている、カーネル レベルのスレッドを使用するのに適したライブラリはどれですか?

また、これらのライブラリをインストールして使用するためのリソースを共有してください。

NPTLを使用していると思われるUbuntu 12.04 LTSサーバーx64（3.2カーネル）でいくつかのコードをテストしました。

私が走るとき

私は得る

以下はテストコードです。gcc -g -Wall -pthread でコンパイルしました

プログラムを実行すると、すべて予想どおりのようです。2 つのスレッドの pid が同じです。

しかし、htop (top のようなツールで、apt-get で取得できます) では、次のように表示されます: 2 つのスレッドの pid が異なります

pid 2108を強制終了すると、プロセスが強制終了されます

そして、gdb を介してプログラムを実行すると、LWPが表示されます。

NPTL のスレッドは 1 つの PID を共有し、LWP はカーネル 2.6 より前の LinuxThreads 用だと思います。上記は、NPTL がまだ LWP を使用しているようです。私は正しいですか？NTPLとLWPの真相が知りたいです。

ありがとう。

POSIX スレッドを使用してコードを確認し、POSIX スレッドの古い LinuxThreads 実装を使用して Linux プラットフォームで実行しています (クロスコンパイルされたコード、違いがある場合は MIPS/uClibc をターゲットにします)。NPTL 実装の答えに違いがある場合は、完全を期すためにそれも知りたいです。pthread_t質問は、C ライブラリ ヘッダー ファイルから、uClibc と glibc の両方で定義されていることがわかるタイプに関するものですunsigned long int(実際には組み込み GNU C ライブラリ – 参照として利用できるのは Ubuntu だけです)。

質問に... タイプの変数はpthread_t、プロパティの所有者を格納するために使用されます。私を悩ませているのは、0どのスレッドもそのプロパティを所有していないことを示す の代入が表示されることです。pthread_t 型は不透明であるとPOSIX 標準が述べていることを知っているので、気になります。たとえば、プロパティがスレッドによって所有されているかどうかを判断するには、ブール値フラグを使用する方がよいことはわかっています。私は、長期的には POSIX 標準を尊重するようにコードを修正する必要があるという意見を持っています (他の理由ではなく、将来の世代がコードの堅牢性について熟考するのを防ぐため)。次の質問への答え:の値は決して設定できないと仮定できますか?pthread_t0pthread_create(3) このプラットフォームでpthread_t(私が知る限り、値を取得する唯一の方法です)、その後: value への代入は、このプラットフォームで0未使用のプロパティをマークする堅牢な方法ですか?