kernel delayed_workが再スケジュールされたときにどうなるか

Question

私はカーネル共有ワークキューを使用しています。すぐに実行するように再スケジュールするdelayed_work構造体があります。

delayed_workができるだけ早く実行されることを保証するコードはありますか？

cancel_delayed_work(work); 
schedule_delayed_work(work, 0); 

作業が既に実行されている状況はどうなりますか？ cancel_delayed_workは0を返しますが、作業が現在実行中または予定外の場合は、schedule_delayed_workが何を行うか分かりません。

Answer 1

まあ、あなたは、すべての発明（またはこの場合は研究）の母親である必要性について、彼らが言うことを知っています。私は本当にこの答えが必要で、kernel/workqueue.cを掘り下げて得ました。答えはDocumentation/workqueue.txtと組み合わされたdoc commentsにほとんど含まれていますが、Concurrency Managed Workqueue（cmwq）サブシステムで仕様全体を読んでいないと、明確なスペルはありません。

短い答え

ウィル[あなたのコードは] delayed_workをできるだけ早く実行されることを保証しますか？ （下記の注意点が）

はい

作業がすでに実行されている状況で何が起こる

？

他の作業が既に（原因である、または遅延作業）そのワークキューにキューに入れられたが、それは、後、現在実行中のdelayed_work関数が終了し、最後のものと同じCPU上のいくつかの時点で実行されますでしょう最初に実行します。これは、delayed_workまたはwork_structオブジェクトを再初期化しておらず、work->funcポインタを変更していないことを前提としています。

ロング回答

したがって、最初のオフ、struct delayed_workがその最初のメンバーとしてstruct work_structを埋め込むことによりstruct work_structから導出する疑似継承を使用します。このサブシステムは、いくつかの深刻な並行性を持つために、いくつかの驚くべき原子ビットフリッジングを使用します。 dataフィールドにWORK_STRUCT_PENDINGビットが設定されている場合、work_structは「所有」です。作業者が作業を実行するときには、releases ownershipがあり、最後の作業プールはプライベートset_work_pool_and_clear_pending()関数で記録されます。これはAPIがwork_structオブジェクトを最後に変更した時刻です（もちろんスケジュールを変更するまで）。 cancel_delayed_work()を呼び出すと全く同じことが行われます。

cancel_delayed_work()を呼び出すと、仕事関数がすでに実行されているときには、まだ実行中であっても誰も所有していないので、false（広告として）を返します。ただし、schedule_delayed_work()で再度追加しようとすると、examine the workが最後にpool_workqueueを見つけて、pool_workqueueの作業者のいずれかがあなたの作業を現在実行しているかどうかを確認します。それらが（work->funcポインターを変更していない）場合は、単にpool_workqueueのキューに作業を追加するだけで、再入場が回避されます。それ以外の場合は、現在のCPUのプールにキューを入れます。 （work->funcポインタチェックの理由はwork_structオブジェクトの再利用を可能にすることである。）

注しかし仕事は、あなたは間違いなく、まだキューに登録され、その場合、単純に最初にそれをキャンセルせずschedule_delayed_work()を呼び出すとに何変化が生じないということ最初にキャンセルする必要があります。

編集：ああ、もしあなたがDocumentation/workqueue.txtについての議論で混乱しているなら、無視してください。このフラグは廃止され、無視され、すべてのワークキューは非再入可能になりました。