Question

在Linux 2.6.11.12中，在shedule()函数选择要运行的“下一个”任务之前，它将锁定runqueue

spin_lock_irq(&rq->lock);

并且，在调用context_switch()执行上下文切换之前，它将调用prepare_arch_switch()，默认情况下为no-op：

/*
 * Default context-switch locking:
 */
#ifndef prepare_arch_switch
# define prepare_arch_switch(rq, next)  do { } while (0)
# define finish_arch_switch(rq, next)   spin_unlock_irq(&(rq)->lock)
# define task_running(rq, p)        ((rq)->curr == (p))
#endif

也就是说，它将保持rq->lock直到switch_to()返回，然后，宏finish_arch_switch()实际上会释放锁。

假设有任务A，B和C.现在A调用schedule()并切换到B（现在，rq->lock被锁定）。迟早，B会拨打schedule()。此时，B如何获得rq->lock，因为它被A？

锁定

还有一些依赖于arch的实现，例如：

/*
 * On IA-64, we don't want to hold the runqueue's lock during the low-level context-switch,
 * because that could cause a deadlock.  Here is an example by Erich Focht:
 *
 * Example:
 * CPU#0:
 * schedule()
 *    -> spin_lock_irq(&rq->lock)
 *    -> context_switch()
 *       -> wrap_mmu_context()
 *          -> read_lock(&tasklist_lock)
 *
 * CPU#1:
 * sys_wait4() or release_task() or forget_original_parent()
 *    -> write_lock(&tasklist_lock)
 *    -> do_notify_parent()
 *       -> wake_up_parent()
 *          -> try_to_wake_up()
 *             -> spin_lock_irq(&parent_rq->lock)
 *
 * If the parent's rq happens to be on CPU#0, we'll wait for the rq->lock
 * of that CPU which will not be released, because there we wait for the
 * tasklist_lock to become available.
 */
#define prepare_arch_switch(rq, next)       \
do {                                        \
    spin_lock(&(next)->switch_lock);        \
    spin_unlock(&(rq)->lock);               \
} while (0)
#define finish_arch_switch(rq, prev)    spin_unlock_irq(&(prev)->switch_lock)

在这种情况下，我非常确定此版本会在调用rq->lock之前解锁context_switch()之后做正确的事。

但是默认实现会发生什么？它怎么能做对的？

Answer 1

我在linux 2.6.32.68的context_switch()中找到了一条评论，它在代码下讲述了这个故事：

/*
 * Since the runqueue lock will be released by the next
 * task (which is an invalid locking op but in the case
 * of the scheduler it's an obvious special-case), so we
 * do an early lockdep release here:
 */

然而我们没有在lock被锁定的情况下切换到另一个任务，下一个任务将解锁它，如果新创建了下一个任务，函数ret_from_fork()也将最终调用finish_task_switch()解锁rq->lock

为什么schedule（）在使用默认的prepare_arch_switch（）时不会导致死锁

1 个答案: