問題タブ [futex]

POSIXミューテックスがfutexより重いまたは遅いと見なされるのはなぜですか？pthreadミューテックスタイプのオーバーヘッドはどこから来ていますか？pthreadミューテックスはfutexに基づいていると聞きました。競合がない場合は、カーネルを呼び出さないでください。その場合、pthreadミューテックスはfutexの周りの単なる「ラッパー」であるように見えます。

オーバーヘッドは単に関数ラッパー呼び出しにあり、ミューテックス関数がfutexを「セットアップ」する必要がありますか（つまり、基本的にpthreadミューテックス関数呼び出しのスタックのセットアップ）？または、pthread mutexで行われている追加のメモリバリア手順はありますか？

futex syscall を使用してミューテックスと条件変数を実装しました。私の実装は正しいと思いますが、他の人に検証してもらいたいです。その正しさを検証していただける方がいらっしゃいましたら、大変助かります。

ミューテックスと条件変数のパフォーマンスをさらに改善するための提案も歓迎します。

ありがとう

スーダンシュ

Linuxのfutexシステムコール（FUTEX_WAIT操作）で問題が発生し、原因がないように見えることがあります。ドキュメントには、早期に（）なしで戻る可能性のある特定の条件が指定されていますFUTEX_WAKEが、これらはすべてゼロ以外の戻り値を含みます。futexEAGAINアドレスの値が一致しない場合、（再開）信号など。しかし、戻り値は0です。ポインタがfutexを指しているスレッドの終了以外に、戻り値0で戻る原因となる可能性があるのは何ですか。ETIMEDOUTEINTRFUTEX_WAKEset_tid_addressFUTEX_WAIT

便利な場合、私が待っていた特定のfutexはスレッドtidアドレス（clonesyscallで設定CLONE_CHILD_CLEARTID）であり、スレッドは終了していませんでした。スレッドが終了したときにのみ0を返す操作が発生する可能性があるという私の（明らかに間違った）仮定はFUTEX_WAIT、プログラムロジックに重大なエラーを引き起こします。これは、0を返してもループして再試行することで修正されましたが、今は興味があります。なぜそれが起こったのか。

最小限のテストケースは次のとおりです。

しばらく実行すると、最終的にはKilled（ ）で終了するはずです。これは、戻ったSIGKILLときにスレッドがまだ存在している場合にのみ可能です。FUTEX_WAIT

誰かがこれがスレッドの破壊を完了する前にfutexをウェイクアップしているカーネルであると想定する前に（これは実際にはここの私の最小のテストケースで発生している可能性があります）、私の元のコードでは、スレッドで実行されているユーザースペースコードを実際に観察したことに注意してくださいFUTEX_WAIT戻った後も。

Linux カーネル ソースのfutex.c で、制御がこのfutex_wake_op functionポイントに到達する方法を理解しようとしていました。これは、上記の関数で-EFAULT が返され、書き込み可能である場合に発生します。futex_atomic_op_inuseruaddr2

しかし、 のソースから、futex_atomic_op_inuserでのみ -EFAULT を返すことがわかりますif (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))。

futex_atomic_op_inuser__futex_atomic_op次に、コードに -EFAULT があるマクロを呼び出しますが、EFAULT へのパスには呼び出しが含まれていないと言われています__futex_atomic_op

コントロールはどのようにして前述のポイントに到達しますか (つまり、if (!fshared)goto retry_private ;)then?

前もって感謝します！

私は pthread 条件変数 (Linux futex に基づく) を実装しておりpthread_cond_broadcast、プロセス共有条件変数での「スタンピード効果」を回避するためのアイデアがあります。非プロセス共有条件変数の場合、futex 再キューイング操作は伝統的に (つまり NPTL によって) ウェイターを起動せずに cond 変数の futex からミューテックスの futex に再キューイングするために使用されますが、これは一般にプロセス共有条件変数では不可能です。pthread_cond_broadcast関連するミューテックスへの有効なポインターがない可能性があるためです。最悪のシナリオでは、ミューテックスがそのメモリ空間にマップされていない可能性さえあります。

この問題を克服するための私の考えはpthread_cond_broadcast、ミューテックスへの必要なポインターがあるため、ウェイターを 1 つだけ直接ウェイクし、そのウェイターがウェイクアップ時にリキュー操作を実行することです。

当然のことながら、このアプローチを追求する場合、考慮すべき多くの醜い競合状態がありますが、それらを克服できる場合、そのような実装が無効または望ましくない他の理由はありますか? 克服できないかもしれないと私が考えることができる1つの潜在的な問題は、リキューを担当するウェイター（別のプロセス）が動作する前に殺されるレースですが、condvarを配置することでこれでも克服できるかもしれません堅牢なミューテックス リストに futex を追加して、プロセスが終了したときにカーネルがウェイクを実行できるようにします。

Linuxでのミューテックス、セマフォなどのロックとロック解除などの同期操作のプロファイルを作成したいと思います。

私はそれらがfutexを使用して実装されていることを知っているので、futexのロックとロック解除のプロファイルを作成するだけで十分かもしれません（ここで間違っている場合は修正してください）。futex操作は通常ユーザースペースで発生するため、私の質問はそれをどのようにプロファイリングするかです。これをプロファイリングできるツールはありますか？

私は基本的に、futexと周波数をロックする関数を知ることに興味があります。

私はかなり人気のあるブラウザベースの Web ゲームを実行しており、Apache (ワーカー) と mod_perl で実行しています。サーバーが 1 分間に約 4200 のリクエストを処理しているピーク時には、3 ～ 15 分に 1 回程度、Apache プロセスがハングします。

これらのプロセスが「FUTEX_WAIT」状態でスタックし、何もしていないように見えることを確認しました。CPU を消費したり、RAM を大きくしたりしません。しかし、RAM を占有するだけなので、これは深刻な問題です。

私の現在の解決策は、futex_wait_queue_me でスタックしている Apache プロセスを選別する cron ジョブです。しかし、ハングした Apache プロセスからの応答をたまたま待っているユーザーがエラー (500: データを送り返さずにサーバーが接続を閉じた) を受け取るため、これは素晴らしいことではありません。

開発マシンで問題を再現できず、トラブルシューティングの進め方がわかりません。知りたいのですが、これをさらに診断するにはどうすればよいですか?

編集：トラフィックのバーストに続いて問題が発生することがわかりました.Apacheがさらにいくつかのワーカープロセスを生成し、その後それらを選別しようとします。これは、子供の視点から見た、正常に動作するときの様子です。

...しかし、時折、次のようになります。

...そしてそれ以上進みません。

これ以上デバッグする方法がわかりません。

この方法（関数には追加のパラメーターが必要になる場合があることに気づきました）：

アプリを新しい CentOS サーバーに移動しました。長い間いじった後、プレイしてコンパイルできなかったり、エラーが発生したりできません。シェル出力には、最後のファイルのコンパイルが表示され、ハングします。Scala 0.9.1 モジュールを実行しています。

私はstraceプロセスを行いました、これが私が得たすべてです。それが役立つかどうかはわかりません。

原因のアイデアはありますか？または、どこからトラブルシューティングを開始できますか?

ありがとう。

グローバル ファイル記述子で fclose を呼び出すと、プログラムがハングします。

クローンによって作成されたいくつかのスレッドが終了した後に発生しました。

以下はシーケンスです。

非スレッドは fid を扱います。

strace から、プログラムは "main_arena" を待っている futex でハングします。これはglibc内のミューテックスであるべきだと思います。

バックトレース:

これは、glibc 2.5 を使用する Linux では発生しますが、glibc 2.12 を使用する Linux では発生しません。

このような clone() を使用してスレッドを作成できないためかどうか疑問に思っています。NPTL では、set_robust_futex() やスレッド ローカル ストレージの設定など、さらに多くのことが行われます。

ありがとう！