在schedule()之后恢复线程
另一个新手问题：
在下面的代码中，如果线程在调用“set_current_state”之后但在调用“schedule”之前被抢占怎么办？当代码再次被调度时，它是否从“schedule”调用开始并从运行队列中删除？或者这次忽略“schedule”调用并从 set_current_state(TASK_RUNNING) 语句开始？
{
...
set_current_state(TASK_INTERRUPTIBLE); /* suppose thread is preempted just after this function call */
schedule();
set_current_state(TASK_RUNNING);
...
}
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);
...
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果在第一行之后和第二行之前发生非自愿抢占，将会发生以下情况（或多或少）：
调度程序将运行（sched.c 中的scheduler() 函数） - 因为这就是被抢占的含义。
现在，在外部将其标记为可运行之前，您的任务将不会被安排。这可能是由于发送到任务的信号而发生，或者假设任务在等待队列中排队，由于唤醒队列所属的事件发生，但外部的某些东西必须再次将任务标记为可运行，否则永远不会被调度。这就是为什么如果您查看等待队列代码，它首先将任务放入等待队列，然后才执行与您的代码类似的操作。
当您的任务被标记为可运行时，调度程序将在某个时刻选择它并将上下文切换到任务代码中。
然后，schedule() 函数将被调用。调度程序很可能会再次选择相同的任务，因为它刚刚被它选择为最适合运行的任务，并且这不太可能发生改变。
在从调度程序返回的路上，最后一个 set_current_state 基本上是一个 no 操作，因为此时任务在这种情况下已经被标记为可运行。
Here's (more or less) what will happen if involuntary preemption happens after the first line and before the second:
The scheduler will run (scheduler() function from sched.c) - since this is what being preempted mean.
Since your task is marked as not runnable, the scheduler will remove it from the run queue and will pick another task.
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.
When your task is marked as runnable, at some point the scheduler will pick it and will context switch into the task code.
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.
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.