Home/ Questions/Q 6182579
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T01:13:20+00:00

Another newbie question: In the following code, what if the thread is preempted after

  • 0

Another newbie question:

In the following code, what if the thread is preempted after calling ‘set_current_state’ but before ‘schedule’ is called. When the code is scheduled again, does it start from ‘schedule’ call and is removed from the run queue? Or the ‘schedule’ call is ignored this time and starts from the set_current_state(TASK_RUNNING) statement?

{
...
set_current_state(TASK_INTERRUPTIBLE); /* suppose thread is preempted just after this function call */
schedule();
set_current_state(TASK_RUNNING);
...
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here’s (more or less) what will happen if involuntary preemption happens after the first line and before the second:

    1. The scheduler will run (scheduler() function from sched.c) – since this is what being preempted mean.

    2. Since your task is marked as not runnable, the scheduler will remove it from the run queue and will pick another task.

    3. Now your task will not be scheduled until something external will mark it as runnable again. This might happen due to a signal sent to the task or, assuming the task is queued in a wait queue, due to the event the wake queue belongs to happening, but something external MUST mark the task as runnable again or it will never be scheduled. This is why if you look at the wait queue code, it first put the task on the wait queue and only then does something similar to your code.

    4. When your task is marked as runnable, at some point the scheduler will pick it and will context switch into the task code.

    5. Then the schedule() function will get called. In all likelihood, the scheduler is going to pick the same task yet again, since it has just been picked by it as most eligible for running and it is not likely that this have changed.

    6. On the way back from the scheduler, the last set_current_state will basically be a no op, since the task by this time is already marked as runnable in this scenario.

    • 0