問題タブ [futex]

Linux 3.0 はfutexと呼ばれるシステム コールを提供します。最近の pthread_mutex 実装を含め、多くの同時実行ユーティリティはこのシステム コールに基づいています。コードを記述するときはいつでも、既存の実装を使用するか、それを自分で記述することがプロジェクトにとってより良い選択であるかを常に検討する必要があります。

上記は、futex とman futex(7)のセマンティクス記述に基づく Lock (ミューテックス、1 許可カウント セマフォ) の実装です。

複数のスレッドがロックとロック解除を数千回試行した後、スレッドが x == -1 の状態になり、すべてのスレッドが CompareWait でスタックするというデッドロック バグが含まれているようですが、誰も保持していません。ロック。

誰がバグがどこにあるかを見ることができますか?

更新: futex(7)/セマンティクスが非常に壊れていることに少し驚いています。次のようにLockを完全に書き直しました...これは正しいですか？

ここでの考え方は、x には次の 3 つの状態があるということです。

straceがトレースしているプログラムに異常を引き起こす可能性があるかどうか知りたいのですが。現在、私が呼び出した行で発生したランダムセグメンテーション違反エラー（ただし、straceを使用するとプログラムがそのようにクラッシュすることはないようです）をトレースしようとしていますpthread_cond_wait()。

プログラムを直接実行すると（実際にはc / c ++が混在しています）、想定どおりに動作する場合がありますが、前述のように、pthread_cond_wait()（ちなみに、誰かがその問題を解決したい場合は）でクラッシュすることがあります。 、ここを参照してください、どんな助けでも大歓迎です）。

プログラムを直接実行し、次のようにstraceをプロセスにアタッチする場合：

出力は、futexを待機していることを示すワンライナーです（事実上次のように:)

次のようにstraceからプログラムを実行すると、次のようになります。

次に、ファイル出力のある時点で、正確には、を呼び出すとpthread_cond_wait()、このような複数の行でスパムを送信し続けます（そして、毎回、futex()呼び出しが待機している値は以前よりも高くなります。ここでは15です）

また、プロセスの親ではなく子としてstraceを実行しようとしました（違いが生じることを期待して）。そして、私はそのランダムなセグメンテーション違反エラーをキャッチしようとしましたが、それは決して現れませんでした。

さて、私の質問は、これが一般的で意図的なものなのか、それとも私のstrace-callが偽物なのかということです。そうでない場合は、straceで機能しない可能性があるため、注意する必要のあるシステムコールはありますか、それともこの奇妙な動作はシステムコールのグループに関係しますか？これを回避する方法はありますか？

私はdebian-squeezeを使用しています。

アップデート1

私は複数のスレッド（POSIXスレッド）といくつかの子を実行していることを完全に忘れました。はレースに遭遇するpthread_cond_wait()べきではありませんが、それは間違いなく、pthread_mutex_lock()にアクセスし、pthread_cond_t引数pthread_mutex_tとして解析しているaの後の最初の呼び出しであるためです。pthread_cond_wait()しかし、内部に競合状態があるかどうかはわかりません。必要に応じてプログラムコードを提供します。

私のプログラムには、この奇妙な問題があります:

パイプを介していくつかのコマンドの出力を読み取ることにより、デバイスを見つけようとします。

次に、fgets()を使用してファイル ストリームを読み取り、pclose()を使用してパイプを閉じます。

シングルスレッドプログラムではうまくいきました。しかし、マルチスレッド プログラムに統合した後、fgets() 関数がスレッドをランダムにブロックし始めました。

確認したところ、fpが空のファイル ストリームとして返されることがあるため、 fgets()がブロックされることがわかりました。fpのステータスを非ブロッキングに設定し、 read()を使用して ID でファイルを読み取ると、空のファイル ストリームのためにread()が -1 を返し、pclose()がハングすることがわかります。これらはすべてランダムに発生します。

したがって、この場合、 popen() を介して実行されたコマンドはハングし、決して終了しないと思います。しかし、なぜランダムに発生するのでしょうか? マルチスレッド プログラムには、ユーザー インターフェイスとの対話用に別のスレッドしかありません。パイプはローカルでのみ使用されるため、問題ないと思います。

どんなアイデアでも大歓迎です。ありがとう！

アップデート

strace は、子プロセスが一連の munmap() 呼び出しの後に futex() を呼び出し、そこでハングする場合があることを示しています: futex(0xb72eaf00, FUTEX_WAIT_PRIVATE, 2, NULL

通常、futex は呼び出されません。

参考までに、メイン プロセスの strace の出力:

子プロセス シェルの strace の出力:

リクエストに応じて、テストできるようにコード全体を含めました。これは完了にはほど遠いですが、安定したtcp接続を介してパケットを送受信できるはずであることに注意してください。

実行すると、次のようになります。

そしてそれはただハングします。私もstraceを使用しましたが、それによって（停止した最後のビットのみが含まれます）：

システムモニターは、プログラムがスリープしていることを示し、futex_wait_queue_meを提供します。

これは、どこかでメモリリークが発生し、futexへの呼び出しが多すぎることが原因である可能性がありますか？

カーネル 2.6.18-238_xen_AMD64 を搭載した RHEL5.6 で berkeley db 4.3 (/usr/lib64/libdb-4.3.so) を使用して、C でプログラミングしています。

私のテスト (1,000,000 個のキーと値のペアの書き込み) では、db に対する操作の実行中に 1 つのプロセスが異常終了 (ctrl + c、kill、または assert の失敗) した場合、その db に対するその後の操作は開くときにブロックされます。Strace は、プロセスが __db.00x (例: __db.001、__db.002、__db.003) ファイルを開いた後、futex(ptr_to_something, FUTEX_WAIT, 2, NULL) 呼び出しでスタックしたことを示しています。

ロックをクリアする唯一の方法は __db.00x ファイルを削除することであり、次のテストではデータベースが破損していないことが示されました。それは私の要件を満たしていますが、この問題を解決するためのより良い（またはよりエレガントな）方法があるかどうか疑問に思っています。

ここでは、 strace stderr とデータベースを操作するためのコードをリストしました。

strace stderr の一部

データベースを操作するコード

64ビットLinuxのsem_tは32バイトですが、futex実装では8バイトで十分です( glibc sem_post )、それは本当ですか? それが本当なら、なぜバイトを無駄にするのですか?

実際には、8 バイトのみを使用するカスタム セマフォ実装を使用したいので、1 つのセマフォを 1 つの日付エントリに使用することが可能です。しかし、glibc の実装の他のバイトが単なるパディングであるかどうかはよくわかりません。

念のために言っておきますが、私は仕事でカスタム セマフォを使用するつもりはありません。

Linuxのfutexが競合する場合、システムはスピンロックに多くの時間を費やすことがわかりました。これは、futexが直接使用されていない場合でも、malloc / free、rand、glib mutex呼び出し、およびfutexを呼び出すその他のシステム/ライブラリ呼び出しを呼び出す場合にも問題になることに気付きました。この動作を取り除く方法はありますか？

カーネル2.6.32-279.9.1.el6.x86_64でCentOS6.3を使用しています。また、kernel.orgから直接ダウンロードした最新の安定したカーネル3.6.6も試しました。

元々、この問題は16GBのRAMを搭載した24コアサーバーで発生していました。プロセスには700のスレッドがあります。「perfrecord」で収集されたデータは、スピンロックが__lll_lock_wait_privateおよび__lll_unlock_wake_privateから呼び出されたfutexから呼び出され、CPU時間の50％を消費していることを示しています。gdbを使用してプロセスを停止すると、バックトレースは、__lll_lock_wait_private__lll_unlock_wake_privateへの呼び出しがmallocから行われ無料であることを示していました。

私は問題を減らそうとしていたので、スピンロックの問題を引き起こしているのは実際にfutexであることを示す簡単なプログラムを作成しました。

8つのスレッドを開始し、各スレッドは次のことを行います。

私はこれを十分なRAMを備えた8コアマシンで実行しています。

「トップ」を使用して、マシンが10％アイドル、ユーザーモードで10％、システムモードで90％であることを確認しました。

「perftop」を使用して、私は次のことを観察しました。

futexコードはfutex待機キューを取得する必要があるため、このコードはスピンロックでしばらく時間を費やすと思います。また、このコードスニペットでは、ユーザースペースで実行されているコードがほとんどないため、コードがシステム内である程度の時間を費やすことも予想されます。ただし、特にこのcpu時間が他の有用な作業を行うために必要な場合、スピンロックに費やされる時間の50％は過剰であるように思われます。

このブログ記事で説明されているのと基本的に同じスレッドとフォークを混在させる問題があります: http://rachelbythebay.com/w/2011/06/07/forked/

(スレッドとフォークを混在させると、一部の子プロセスが FUTEX 呼び出しでハングする原因になります)

彼女の分析は基本的に、SSH ライブラリがあらゆる種類のスレッドを作成していることであり、 ssh を使用する必要はないと結論付けています。

ssh が必要です。スレッドを生成しない python ssh ライブラリを知っている人はいますか?

スレッドがスリープ状態のスレッドをウェイクアップするために呼び出したときのレイテンシーを測定しようとしていました。多くの同期プリミティブが futex の上に開発されていると言われているので、futex は常に高速であると期待しています。しかし、私のテストでは反対の結果が得られました。何か悪いことをしたのだろうか、それとも事実なのだろうか。

私のテストの詳細は次のとおりです。

• プロセスは特定のコアにアフィニティを設定されています
• 時間は RDTSC() 命令から返された数によって比較されます
• 2 つのスレッドが作成され、ウェイク中のスレッド 2 の FIFO 優先度が高くなります。

Thread1 はミューテックスのロックを解除してシグナルを送信しているため、Thread2 は次のスケジュールでウェイクアップすることになっています。thread1 の sleep(1) は、mutex_unlock が呼び出されたときに、thread2 がミューテックスを待機してスリープ状態になるようにするためのものです。

同様のテストは、mutex を futex システム コールに置き換えることによって行われます。

mutx と futx の両方がグローバルに宣言されています。私の Core i7 930 マシンで、fedora17 を使用すると、mutex は一貫して futex よりも 5 ～ 10% 速くウェイクアップします。テスト アプリケーションは、デフォルト設定で gcc 4.7 によってコンパイルされました。なにか提案を？前もって感謝します。

私は64ビットのLinuxボックスを使用しています：

Linux illin793 2.6.32-279.5.2.el6.x86_64 #1 SMP Tue Aug 14 11:36:39 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

男フテックス より:

int futex(int *uaddr, int op, int val, const struct timespec *timeout, int *uaddr2, int val3);

したがって、ここで futex は 32 ビット値で動作します。

64 ビット値で動作する Linux 上の futex はありますか?