3

http://www.linuxjournal.com/article/8144を読んで、次の状況について考えています。

4253  /* Wait for kthread_stop */
4254  set_current_state(TASK_INTERRUPTIBLE);
4255  while (!kthread_should_stop()) {
4256          schedule();
4257          set_current_state(TASK_INTERRUPTIBLE);
4258  }
4259  set_current_state(TASK_RUNNING);
4260 return 0;

では、プロセスをスリープ状態に設定する 4254 行目の直前に kthread_stop が呼び出され、その行の直後に実際にプリエンプト/スケジュールが設定され、プロセスも実際にスリープ状態に移行した場合はどうなるでしょうか。

この場合、ウェイクアップ コールは状態を変更する直前に受信され (したがって影響はありません)、オペレーティング システムの通常の動作では、実際に何かを確認する前にスリープ状態になります。

おそらく、次の 2 つのオプションのいずれかが欠けていると思います。 set_current_state 呼び出しの後、schedule() 呼び出しの前。

ご協力ありがとうございます。

4

3 に答える 3

2

kthread_stop4254 行より前に呼び出された場合はkthread_should_stop()true を返し、schedule()呼び出されません。この特定のケースでは、はポリシー(タイム スライスを持たない)migration_threadで高い優先度でスケジュールSCHED_FIFOSCHED_FIFOされ、より高い優先度を持つ別のタスクによってのみプリエンプトされます ( sched_setschedulerを参照)。

于 2012-12-21T10:33:23.860 に答える
0

schedule() は、Linux カーネルがスレッド間でコンテキストを変更する唯一の方法です。

コードがコメントしているように、これはプロセッサ間で移行するためのものであるため、おそらくあまり頻繁には実行されません (比較的言えば)。

于 2012-12-21T10:03:24.730 に答える
0

ここに同様の質問と回答があります

http://fixunix.com/linux/7425-schedule_timeout-doubt-possible-infinite-sleep.html

リンクから引用すると、

[見積もり-]

私の理解が正しければ、プリエンプションが発生すると、PREEMPT_ACTIVE ビットがスレッドの preempt_count に追加されます。これは preempt_schedule / preempt_schedule_irq で発生します。次に、これらは、PREEMPT_ACTIVE がカウントに設定されているかどうかをチェックする schedule() を呼び出します。設定されている場合は、 deactivate_task() を呼び出しず、スレッドをアクティブ リストに残します。[-見積もり]

したがって、割り込みまたはプリエンプションが発生した場合、スレッドは実行キューから移動されません。

于 2016-06-24T04:29:23.387 に答える