tasklet / 工作队列 / 软中断

最新推荐文章于 2023-05-25 08:50:46 发布

h490516509

最新推荐文章于 2023-05-25 08:50:46 发布

阅读量260

点赞数

分类专栏：系统编程

系统编程专栏收录该内容

24 篇文章 0 订阅

订阅专栏

只有中枢的内核代码才使用软中断，而如果用户想要使用这种方式，直接使用软中断并不是一个好的选择，内核为用户提供了另外一种方便的方式即tasklet，tasklet本质上也是一种软中断，准确来说是系统从软中断类型中拿出一种来支持tasklet，所以tasklet就是一种软中断，不过在软中断的基础上，tasklet进行了更细的划分。每个CPU维护一个tasklet链表，其中保存当前CPU所有注册的tasklet。由于tasklet本质上仍然是软中断，所以其处理方式依赖于软中断的处理时机，在系统检查处理软中断时，检查到tasklet类型的软中断，调用tasklet_action函数进行处理。

软中断、tasklet和工作队列并不是Linux内核中一直存在的机制，而是由更早版本的内核中的“下半部”（bottom half）演变而来。下半部的机制实际上包括五种，但2.6版本的内核中，下半部和任务队列的函数都消失了，只剩下了前三者。本文重点在于介绍这三者之间的关系。

（1）上半部和下半部的区别
上半部指的是中断处理程序，下半部则指的是一些虽然与中断有相关性但是可以延后执行的任务。举个例子：在网络传输中，网卡接收到数据包这个事件不一定需要马上被处理，适合用下半部去实现；但是用户敲击键盘这样的事件就必须马上被响应，应该用中断实现。
两者的主要区别在于：中断不能被相同类型的中断打断，而下半部依然可以被中断打断；中断对于时间非常敏感，而下半部基本上都是一些可以延迟的工作。由于二者的这种区别，所以对于一个工作是放在上半部还是放在下半部去执行，可以参考下面四条：
a）如果一个任务对时间非常敏感，将其放在中断处理程序中执行。
b）如果一个任务和硬件相关，将其放在中断处理程序中执行。
c）如果一个任务要保证不被其他中断（特别是相同的中断）打断，将其放在中断处理程序中执行。
d）其他所有任务，考虑放在下半部去执行。

（2）为什么要使用软中断？
软中断作为下半部机制的代表，是随着SMP（share memory processor）的出现应运而生的，它也是tasklet实现的基础（tasklet实际上只是在软中断的基础上添加了一定的机制）。软中断一般是“可延迟函数”的总称，有时候也包括了tasklet（请读者在遇到的时候根据上下文推断是否包含tasklet）。它的出现就是因为要满足上面所提出的上半部和下半部的区别，使得对时间不敏感的任务延后执行，而且可以在多个CPU上并行执行，使得总的系统效率可以更高。它的特性包括：
a）产生后并不是马上可以执行，必须要等待内核的调度才能执行。软中断不能被自己打断，只能被硬件中断打断（上半部）。
b）可以并发运行在多个CPU上（即使同一类型的也可以）。所以软中断必须设计为可重入的函数（允许多个CPU同时操作），因此也需要使用自旋锁来保护其数据结构。

（3）为什么要使用tasklet？（tasklet和软中断的区别）
由于软中断必须使用可重入函数，这就导致设计上的复杂度变高，作为设备驱动程序的开发者来说，增加了负担。而如果某种应用并不需要在多个CPU上并行执行，那么软中断其实是没有必要的。因此诞生了弥补以上两个要求的tasklet。它具有以下特性：
a）一种特定类型的tasklet只能运行在一个CPU上，不能并行，只能串行执行。
b）多个不同类型的tasklet可以并行在多个CPU上。
c）软中断是静态分配的，在内核编译好之后，就不能改变。但tasklet就灵活许多，可以在运行时改变（比如添加模块时）。
tasklet是在两种软中断类型的基础上实现的，因此如果不需要软中断的并行特性，tasklet就是最好的选择。

（4）为什么要使用工作队列work queue？（work queue和软中断的区别）
上面我们介绍的可延迟函数运行在中断上下文中（软中断的一个检查点就是do_IRQ退出的时候），于是导致了一些问题：软中断不能睡眠、不能阻塞。由于中断上下文出于内核态，没有进程切换，所以如果软中断一旦睡眠或者阻塞，将无法退出这种状态，导致内核会整个僵死。但可阻塞函数不能用在中断上下文中实现，必须要运行在进程上下文中，例如访问磁盘数据块的函数。因此，可阻塞函数不能用软中断来实现。但是它们往往又具有可延迟的特性。
因此在2.6版的内核中出现了在内核态运行的工作队列（替代了2.4内核中的任务队列）。它也具有一些可延迟函数的特点（需要被激活和延后执行），但是能够能够在不同的进程间切换，以完成不同的工作。

工作队列类似 tasklets，允许内核代码请求在将来某个时间调用一个函数，不同在于:

（1）tasklet 在软件中断上下文中运行，所以 tasklet 代码必须是原子的; 而工作队列函数在一个特殊内核进程上下文运行，有更多的灵活性，且能够休眠。
（2）tasklet 只能在最初被提交的处理器上运行，而这只是工作队列的默认工作方式。
（3）内核代码可以请求工作队列函数被延后一个给定的时间间隔。
（4）tasklet 执行的很快, 短时期, 并且在原子态, 而工作队列函数可能是长周期且不需要是原子的，两个机制有它适合的情形。

tasklet函数详解

它对于中断处理特别有用：硬件中断必须尽快处理, 但大部分的数据管理可以延后到以后安全的时间执行。

tasklet 以一个数据结构形式存在，使用前必须被初始化。初始化能够通过调用一个特定函数或者通过使用某些宏定义声明结构:

#include <linux/interrupt.h>   
struct tasklet_struct  
{  
    struct tasklet_struct *next; 
 
    unsigned long state; 
 
    atomic_t count;  

    void (*func)(unsigned long);  

    unsigned long data;  
};  
void tasklet_init(struct tasklet_struct *t,  
 void (*func)(unsigned long), unsigned long data);  
  
#define DECLARE_TASKLET(name, func, data) \  
struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data }  
#define DECLARE_TASKLET_DISABLED(name, func, data) \  
struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data }  
  
void tasklet_disable(struct tasklet_struct *t);  
 
/*函数暂时禁止给定的 tasklet被 tasklet_schedule 调度，直到这个 tasklet 被再次被enable；若这个 tasklet 当前在运行, 这个函数忙等待直到这个tasklet退出*/  
void tasklet_disable_nosync(struct tasklet_struct *t);  
 
/*和tasklet_disable类似，但是tasklet可能仍然运行在另一个 CPU */  
void tasklet_enable(struct tasklet_struct *t);  
 
/*使能一个之前被disable的 tasklet;若这个 tasklet 已经被调度, 它会很快运行。 tasklet_enable 和tasklet_disable必须匹配调用, 因为内核跟踪每个 tasklet 的"禁止次数"*/   
void tasklet_schedule(struct tasklet_struct *t);   

/*调度 tasklet 执行，如果tasklet在运行中被调度, 它在完成后会再次运行; 这保证了在其他事件被处理当中发生的事件受到应有的注意. 这个做法也允许一个 tasklet 重新调度它自己*/  
void tasklet_hi_schedule(struct tasklet_struct *t);   

/*和tasklet_schedule类似，只是在更高优先级执行。当软中断处理运行时, 它处理高优先级 tasklet 在其他软中断之前，只有具有低响应周期要求的驱动才应使用这个函数, 可避免其他软件中断处理引入的附加周期*/  
void tasklet_kill(struct tasklet_struct *t);   
/* 确保了 tasklet 不会被再次调度来运行，通常当一个设备正被关闭或者模块卸载时被调用。如果 tasklet 正在运行, 这个函数等待直到它执行完毕。若 tasklet 重新调度它自己，则必须阻止在调用 tasklet_kill 前它重新调度它自己，如同使用 del_timer_sync*/

tasklet

Tasklet的使用比较简单，只需要定义tasklet及其处理函数并将两者关联

例子：

Void my_tasklet_func(unsigned long) //定义一个函数

DECLARE_TASKLET(my_tasklet.my_tasklet_func,data) //初始化 tasklet

代码DECLARE_TASKLET实现了定义名称为my_tasklet的tasklet并将其与my_tasklet_func这个函数绑定，而传入这个函数的参数为data。

需要调度tasklet的时候引用一个tasklet_schedule()函数就能使系统在适当的时候进行调度，如下所示

Tasklet_schedule(&my_tasklet) //调度tasklet

下面给出驱动模板

void xxx_do_tasklet(unsigned long);  
  
DECLARE_TASKLET(xxx_tasklet,xxx_do_tasklet,0);  
  
void xxx_do_tasklet(unsigned long)  
  
{   
……  
}  
  
irqreturn_t xxx_interrupt(int irq,void *dev_id,struct pt_regs *regs)  
  
{  
      ……  
      tasklet_schedule(&xxx_tasklet);  
      ……  
}  
  
int _init xxx_init(void)  
  
{  
      ……  
      result=request_irq(xxx_irq,xxx_interrupt,SA_INTERRUPT,”xxx”,NULL)  
      ……  
}  
  
void _exit xxx_exit(void)  
  
{  
      ……  
      free_irq(xxx_irq,xxx_irq_interrupt);  
      ……  
}

工作队列

工作队列函数详解

工作队列有 struct workqueue_struct 类型，在 <linux/workqueue.h> 中定义。一个工作队列必须明确的在使用前创建，宏为:

struct workqueue_struct *create_workqueue(const char *name);
struct workqueue_struct *create_singlethread_workqueue(const char *name);

每个工作队列有一个或多个专用的进程("内核线程"), 这些进程运行提交给这个队列的函数。若使用 create_workqueue, 就得到一个工作队列它在系统的每个处理器上有一个专用的线程。在很多情况下，过多线程对系统性能有影响，如果单个线程就足够则使用 create_singlethread_workqueue 来创建工作队列。

提交一个任务给一个工作队列，在这里《LDD3》介绍的内核2.6.10和我用的新内核2.6.22.2已经有不同了，老接口已经不能用了，编译会出错。这里我只讲2.6.22.2的新接口，至于老的接口我想今后内核不会再有了。从这一点我们可以看出内核发展。

/*需要填充work_struct或delayed_work结构，可以在编译时完成, 宏如下: */  
  
struct work_struct {  
    atomic_long_t data;  
#define WORK_STRUCT_PENDING 0        /* T if work item pending execution */  
#define WORK_STRUCT_FLAG_MASK (3UL)  
#define WORK_STRUCT_WQ_DATA_MASK (~WORK_STRUCT_FLAG_MASK)  
    struct list_head entry;  
    work_func_t func;  
};  
  
struct delayed_work {  
    struct work_struct work;  
    struct timer_list timer;  
};  
  
DECLARE_WORK(n, f)      
/*n 是声明的work_struct结构名称, f是要从工作队列被调用的函数*/  
DECLARE_DELAYED_WORK(n, f)  
/*n是声明的delayed_work结构名称, f是要从工作队列被调用的函数*/  
  
/*若在运行时需要建立 work_struct 或 delayed_work结构, 使用下面 2 个宏定义:*/  
INIT_WORK(struct work_struct *work, void (*function)(void *));   
PREPARE_WORK(struct work_struct *work, void (*function)(void *));   
INIT_DELAYED_WORK(struct delayed_work *work, void (*function)(void *));   
PREPARE_DELAYED_WORK(struct delayed_work *work, void (*function)(void *));   
/* INIT_* 做更加全面的初始化结构的工作，在第一次建立结构时使用. PREPARE_* 做几乎同样的工作, 但是它不初始化用来连接 work_struct或 delayed_work 结构到工作队列的指针。如果这个结构已经被提交给一个工作队列, 且只需要修改该结构,则使用 PREPARE_* 而不是 INIT_* */  
  
/*有 2 个函数来提交工作给一个工作队列:*/  
int queue_work(struct workqueue_struct *queue, struct work_struct *work);  
int queue_delayed_work(struct workqueue_struct *queue, struct delayed_work *work, unsigned long delay);  
/* 每个都添加work到给定的workqueue。如果使用 queue_delay_work, 则实际的工作至少要经过指定的 jiffies 才会被执行。 这些函数若返回 1 则工作被成功加入到队列; 若为0，则意味着这个 work 已经在队列中等待，不能再次加入*/

工作队列的使用

定义一个工作队列

Struct work_struct my_wq;

Void my_wq_func(unsigned long);

通过INIT_WORK可以初始化这个工作队列并将工作队列与处理函数绑定

INIT_WORK(&my_wq,(void(*)(void*))my_wq_func,NULL)

调度工作队列

Schedule_work(&my_wq)

h490516509

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
tasklet / 工作队列 / 软中断

只有中枢的内核代码才使用软中断，而如果用户想要使用这种方式，直接使用软中断并不是一个好的选择，内核为用户提供了另外一种方便的方式即tasklet，tasklet本质上也是一种软中断，准确来说是系统从软中断类型中拿出一种来支持tasklet，所以tasklet就是一种软中断，不过在软中断的基础上，tasklet进行了更细的划分。每个CPU维护一个tasklet链表，其中保存当前CP...
复制链接

扫一扫

专栏目录