linux 工作队列上睡眠的认识--不要在默认共享队列上睡眠

最新推荐文章于 2025-08-01 15:30:03 发布

原创最新推荐文章于 2025-08-01 15:30:03 发布 · 2.1k 阅读

7 ·

CC 4.0 BY-SA版权

linux 专栏收录该内容

6 篇文章

订阅专栏

本文探讨了Linux内核中工作队列与睡眠的关系，通过实验发现，在系统共享队列上进行睡眠会导致内核部分功能阻塞，从而造成系统卡死。解决办法是创建自定义队列。

最近项目组做xen底层，我已经被完爆无数遍了，关键在于对内核、驱动这块不熟悉，导致分析xen代码非常吃力。于是准备细细的将几本 linux 书籍慢慢啃啃。

正好看到LINUX内核设计与实现，对于内核中中断下半段该如何选择？大牛的原话是这样的：“从根本上来说，你有休眠的需要吗？要是有，工作队列就是你的唯一选择，否则最好用tasklet。……”

书中一直强调工作队列是可以休眠的，而且翻译的人总是强调”工作队列是运行在进程上下文的”，对于这个翻译，我不是很理解，进程上下文难道就是指用户态而言吗，完全糊涂了，准备自己做个实验。于是我在网上收了下，并自己写了一个工作队列的例子，基本代码如下：

struct work_struct test_task;

void task_handler(void *data)
{
    char c = 'a';
    int i = 0;
   
    while (task_doing == 1)
    {
        c = 'a'+ i%26;
        printk(KERN_ALERT "---%c\n", c);
        
        if (i++ > 50)
        {
            printk(KERN_ALERT "i beyone so quit");
            break;
        }
       
        //msleep(1000);
        wait_event_interruptible(my_dev->test_queue, my_dev->test_task_step !=0);
    }

    printk(KERN_ALERT "quit task task_doing %d\n",task_doing);
       
}
static int
test_ioctl(struct inode *inode, struct file *filp,
		  unsigned int cmd, unsigned long arg)
{
    switch(cmd)
    {
        case IOCTL_INIT_TASK:
            task_doing = 1;
            INIT_WORK(&test_task, task_handler);
            printk(KERN_ALERT "ioctl init task \n");
            break;
         case IOCTL_DO_TASK:
            printk(KERN_ALERT "ioctl do task \n");
            schedule_work(&test_task);
            break;
        default:
            printk(KERN_ALERT "unknown ioctl cmd\n");
            break;
    }
    return 0;
}

用户态测试程序通过 ioctl 命令发送 IOCTL_INIT_TASK 和 IOCTL_DO_TASK 命令。通过书中介绍，INIT_WORK 是初始化一个工作队列，其后调用schedule_work(&test_task) 后，才会执行工作队列上注册的回调函数。

在回调函数中，我进行了睡眠，开始用的是 msleep ，这个函数会放弃CPU到指定的时间，没想到我的内核居然挂住了，再也无法响应。看看驱动设计的代码，很少看到有人用msleep的，可能是自己用了不恰当的函数，于是换成如下代码：

wait_event_interruptible(my_dev->test_queue, my_dev->test_task_step !=0);

重新将虚拟机恢复后，执行同样的测试，还是不行，一运行注册的回调函数，内核就立刻挂起，再也无法操作。

更加无法理解了，说好的工作队列是可以睡眠的，但是我调用睡眠，内核居然就永远无法醒来啦。已经没有机会执行一个动作让 my_dev->test_task_step == 1 了，那么书中所说的工作队列可以睡眠是什么意思呢？

同时看了设备驱动详解中阻塞IO的例子，书中说在 linux 中一个等待队列头可以如下动态创建：

wait_queue_head_t my_queue;
init_waitqueue_head(&my_queue);

可是书后面的手动睡眠有有如下的介绍，手动睡眠的过程是这样的：

第一步是创建和初始化一个等待队列. 这常常由这个宏定义完成:

DEFINE_WAIT(my_wait);

其中, name 是等待队列入口项的名子. 你可用 2 步来做:

wait_queue_t my_wait;
init_wait(&my_wait);

但是常常更容易的做法是放一个 DEFINE_WAIT 行在循环的顶部, 来实现你的睡眠.

下一步是添加你的等待队列入口到队列, 并且设置进程状态. 2 个任务都由这个函数处理:

void prepare_to_wait(wait_queue_head_t *queue, wait_queue_t *wait, int state);

这里, queue 和 wait 分别地是等待队列头和进程入口. state 是进程的新状态; 它应当或者是 TASK_INTERRUPTIBLE(给可中断的睡眠, 这常常是你所要的)或者 TASK_UNINTERRUPTIBLE(给不可中断睡眠).

在调用 prepare_to_wait 之后, 进程可调用 schedule -- 在它已检查确认它仍然需要等待之后. 一旦 schedule 返回, 就到了清理时间. 这个任务, 也, 被一个特殊的函数处理:

void finish_wait(wait_queue_head_t *queue, wait_queue_t *wait);

同时，书中还有一个例子：

/* Wait for space for writing; caller must hold device semaphore. On
 * error the semaphore will be released before returning. */
static int scull_getwritespace(struct scull_pipe *dev, struct file *filp)
{

        while (spacefree(dev) == 0)
        { /* full */
                DEFINE_WAIT(wait);

                up(&dev->sem);
                if (filp->f_flags & O_NONBLOCK)
                        return -EAGAIN;

                PDEBUG("\"%s\" writing: going to sleep\n",current->comm);
                prepare_to_wait(&dev->outq, &wait, TASK_INTERRUPTIBLE);
                if (spacefree(dev) == 0)
                        schedule();
                finish_wait(&dev->outq, &wait);
                if (signal_pending(current))

                        return -ERESTARTSYS; /* signal: tell the fs layer to handle it */
                if (down_interruptible(&dev->sem))
                        return -ERESTARTSYS;
        }
        return 0;

}

问题在于，手动睡眠的方式和上面调用 wait_event_interruptible 有什么区别呢 ？从代码上看，手动睡眠有一个等待队列头，而且有一个等待队列单个元素 wait, prepare_to_wait 函数会将 该单个等待元素挂到等待队列头里面去。 一直想搞明白调用 prepare_to_wait 后，会不会进入睡眠 ？ 做了一个实验，答案是肯定的，调用prepare_to_wait后，内核立刻进入睡眠状态，只有在其他地方调用 wake_up_interruptible 后才会通知它醒来。。。而且 不必再每次 prepare_to_wait醒来后都调用 finish_wait ,只需要最后调用一次就可以了，因为prepare_to_wait 的内部会做检查，发现该元素不在头链表上时，才会添加该元素到头链表。

在看看 wait_event_interruptible 的代码：

#define __wait_event_interruptible(wq, condition, ret)			\
do {									\
	DEFINE_WAIT(__wait);						\
									\
	for (;;) {							\
		prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE);	\
		if (condition)						\
			break;						\
		if (!signal_pending(current)) {				\
			schedule();					\
			continue;					\
		}							\
		ret = -ERESTARTSYS;					\
		break;							\
	}								\
	finish_wait(&wq, &__wait);					\
} while (0)

原来这个函数对手动睡眠的过程进行了封装，所以调用的时候只用到工作队列（实际就是等待队列）头，它内部自己封装了一个等待元素。。

现在看来，linux 内核设计与实现中，对工作队列可以睡眠的说法是比较模糊的，工作队列上的回调函数是不能睡眠的。工作队列本身就是一种等待队列，队列是可以睡眠的，但是工作队列的上任务回调函数，看来是不能睡眠的。今天先睡了，后面还要进一步分析看看。

今天在网上查了下相关的东西，有个家伙写得不错：“使用内核提供的共享列队，列队是保持顺序执行的，做完一个工作才做下一个，如果一个工作内有耗时大的处理如阻塞等待信号或锁，那么后面的工作都不会执行。如果你不喜欢排队或不好意思让别人等太久，那么可以创建自己的工作者线程，所有工作可以加入自己创建的工作列队，列队中的工作运行在创建的工作者线程中。”

问题可能就是出在上面了，如果我使用了内核提供的共享队列，可想而知，如果我进入了睡眠或者阻塞，内核中肯定有其他的工作也在这个共享队列上运行，此时便会阻塞内核的某些工作，当然系统就看起来卡死一样了。这样说，如果我创建自己的工作队列，然后在自己的工作队列上挂起，那样就不会出现卡死现象了。做了下试验，果然是这样。

看来，纸上得来总觉浅，深知此事要恭行。linux 内核设计与实现这本书是比较简洁的，作者只告诉我们，利用工作队列甚至可以睡眠，但是他没有强调：“最好不要在系统提供的共享队列上进行睡眠，如果自己的工作是非阻塞的，可以就近利用默认的共享队列。但是如果自己的工作需要睡眠或者阻塞，此时万万不可使用系统提供的默认共享队列，否则会导致内核中一部分关键工作得不到执行，而陷入系统卡死的状态。

这是一个坑，如果不小心处理，会导致系统挂起。