Linux 内核代码的各种执行方式--理解中断上半部/下半部、软中断、tasklet、工作队列

Linux 内核就是在精心设计一套规则，来管理如何应对“突发紧急事件”和“常规计划任务”，并在多核心环境下高效、安全地完成所有工作。

1. 什么是 执行上下文（Execution Context）

上下文是一个理解操作系统和内核编程最核心、最基础的问题。理解“上下文”是理解一切并发、调度、中断处理的基础。

你可以把“上下文”理解为 “当前代码执行时所处的环境、背景和状态”。

想象一下你在公司里的角色：

• 场景A：你正在以“员工”的身份写项目代码。
• 场景B：你的手机响了，你以“儿子”的身份接听妈妈的电话。

这两个“场景”就是不同的上下文。它们决定了：

1. 你是谁（你的身份）：是员工还是儿子？
2. 你能做什么（你的权限）：能访问公司代码库还是能问妈妈要生活费？
3. 你被打断后如何恢复：接完电话后，你能准确地回到刚才写代码的地方继续工作，因为你记得代码写到哪一行了（这就是保存了上下文）。

在计算机中，上下文就是CPU在执行代码时，所有相关寄存器的值（如指令指针IP、栈指针SP、状态寄存器等）、内存状态、权限级别等一系列信息的集合。切换上下文就是保存当前这套信息，然后加载另一套信息。

执行上下文定义了代码执行时的环境，主要包括：

1. 当前地址空间：用户空间还是内核空间？
2. 调度状态：是否可以睡眠（被调度走）？
3. 抢占状态：是否可以被更高优先级的任务抢占？
4. 并发和重入：同一段代码是否可能在多个CPU上同时执行？

内核代码的执行方式主要分为三大类，

进程上下文 (Process Context)

• 是什么？ 当CPU在执行一个用户进程的代码，或者因为该进程的请求（如系统调用）而在执行内核代码时，就处于进程上下文。

• 关键比喻：“员工在做一个长期项目”。

  • 有明确身份：这个项目是为哪个客户（哪个进程）做的？项目负责人是谁（task_struct）？这些都清清楚楚。
  • 拥有资源：你有权使用这个项目的所有资源（进程的内存空间、打开的文件等）。
  • 可以被打断和暂停：老板（调度器）可以随时让你“停一下，先去干别的”，你只需要把当前的工作进度（寄存器、写到哪了）记到项目本（内核栈）上，就可以去干别的。之后回来，翻开项目本就能接着干。这个过程就是上下文切换。
  • 可以等待（睡眠）：如果你需要等另一份材料（比如等待磁盘读取数据），你可以主动去睡一觉，等材料到了再被叫醒。这不会浪费公司资源。

• 技术特点：

  • 代表一个进程在执行。
  • 可以睡眠：因为调度器知道当前是哪个进程在运行，睡眠后可以切换到另一个进程。
  • 可以发生缺页中断：可以访问用户空间内存。
  • 可以被抢占：除非显式禁止。

• 触发方式：系统调用、异常（如页错误）。

线程上下文 (Thread Context)

• 是什么？ 首先，在Linux内核中，线程被称为“轻量级进程”(Light-Weight Process, LWP)。内核并不区分线程和进程，线程就是共享了大部分资源（特别是内存地址空间）的进程。

• 关键比喻：“一个项目组里的多个员工一起做同一个大项目”。

  • 他们共享项目资源（共享内存、文件等）。
  • 但每个员工是独立的，有自己的任务进度（有自己的栈、寄存器状态），可以独立地被老板叫停或派去干别的事（被独立调度）。

• 技术特点：

  • 线程上下文本质上就是一种进程上下文。所以它拥有进程上下文的所有特性：可以睡眠、可以被抢占等。
  • 它与同进程的其他线程共享内存地址空间和文件等资源，但有自己独立的栈和寄存器状态。

• 结论：线程上下文是进程上下文的一种特殊形式。当你理解进程上下文后，线程上下文也就理解了。

内核线程上下文

内核线程上下文是一种特殊的进程上下文。 它们最大的区别在于：用户态进程上下文拥有“完整的双世界”（用户空间和内核空间），而内核线程上下文只生活在“内核世界”。

为了更直观地理解，我们用一个比喻：

• 用户态进程：像一个有自己私人领地（用户空间）的公民。他大部分时间生活在自己的领地里（执行用户代码）。当需要政府服务（系统调用）或遇到意外（异常）时，他就通过特定的通道进入政府大楼（内核空间）办理业务。办完后，又返回自己的领地。
• 内核线程：像一个政府大楼里的公务员。他生来就在政府大楼里工作，没有自己的私人领地。他的工作就是处理政府内部的事务（执行内核后台任务）。

以下表格清晰地列出了两者的主要区别：

1. 内存地址空间的根本区别（最核心的区别）

这是所有差异的根源。在Linux中，进程的地址空间由 struct mm_struct 描述。

• 用户态进程：它的 task_struct->mm 指针指向一个有效的 mm_struct，这个结构体同时管理着用户空间和内核空间的映射。虽然所有进程共享同一份内核代码和数据，但每个进程的“内核空间”视图是一致的。
• 内核线程：它的 task_struct->mm 指针通常是 NULL。这意味着它没有用户空间。那它需要页表吗？需要。它会借用上一个运行的用户进程的页表（task_struct->active_mm）。这样做纯粹是为了提高效率，避免切换页表时冲刷TLB（Translation Lookaside Buffer）。内核线程本身并不关心借用的是谁的页表，因为它只访问内核空间。

2. 系统调用的不同视角

• 用户态进程：系统调用是它主动请求内核服务的唯一方式，是一个“显式”的、跨越特权边界的行为。
• 内核线程：它本身就运行在内核态，可以直接调用内核函数。它不需要执行“系统调用”指令（如 int 0x80 或 syscall）来进入内核，因为它已经在里面了。例如，一个内核线程可以直接调用 vfs_write() 来写文件，而用户进程必须调用 write() 系统调用，最终才由内核陷入函数 sys_write() 来处理。

3. 共同点：都是进程上下文

尽管有上述区别，但最关键的是要认识到：当内核线程运行时，它处于进程上下文中。

这意味着它拥有进程上下文的所有关键特性，而这些特性是与中断上下文相对立的：

• 它可以睡眠：内核线程可以调用 schedule() 主动让出CPU，或者等待一个信号量、互斥锁而睡眠。
• 它可以被抢占：除非显式禁止，否则调度器可以随时切换走一个内核线程。
• 它可以发生缺页中断：虽然它没有用户空间，但它访问内核内存时如果该页面被换出（在某些架构上），也可能触发缺页中断，内核会妥善处理。

结论：
内核线程是内核的“后勤员工”，它没有用户空间的牵挂，全身心在内核世界工作。但它仍然遵守“进程”的基本规则：可以休息（睡眠）、可以被老板（调度器）调去干别的活（抢占）。而用户进程是“市民”，需要频繁地在“自家”和“政府”之间穿梭。

中断上下文 (Interrupt Context)

• 是什么？ 当硬件设备（如网卡、键盘）需要CPU立即关注时，会发出一个中断信号。CPU会强行暂停当前手头的工作，转而去执行一个特定的函数——中断处理程序。执行这个程序时所处的环境，就是中断上下文。

• 关键比喻：“火警警报突然响了”。

  • 没有身份：你跑去处理火警，此时你的身份不是“员工”，而是“紧急事件处理者”。你做的事与当前被打断的项目无关。
  • 极度紧急，必须立刻处理：你必须放下手头的一切事情。
  • 必须速战速决：警报处理必须非常快。你绝对不能在处理火警时中途睡着（中断上下文不能睡眠！）。因为警报器一直在响，你睡着了整个公司就完了（系统会卡死）。
  • 处理完就撤：处理完后，你回来继续做刚才被打断的工作，就像什么都没发生过一样。

• 技术特点：

  • 与任何进程无关：它异步地打断当前正在执行的任务。
  • 绝对禁止睡眠/阻塞：因为中断上下文没有“项目本”（task_struct），调度器不知道如果它睡了该恢复谁。睡眠会导致系统死锁。
  • 执行要尽可能快：长时间中断会导致中断丢失。
  • 不能与用户空间交互：因为不知道当前是哪个进程在运行。

• 触发方式：硬件中断。

为什么上下文如此重要？

因为你写的内核代码必须知道自己处在什么上下文，从而决定能做什么、不能做什么。

• 在进程上下文中：你可以使用可能会引起睡眠的机制，比如：

  • kmalloc(... GFP_KERNEL) （分配内存可能睡眠）
  • mutex_lock(...) （获取互斥锁可能睡眠）
  • msleep(...) （主动睡眠）

• 在中断上下文中：你绝对不能使用上述可能睡眠的函数。你必须使用：

  • kmalloc(... GFP_ATOMIC) （原子分配，绝不会睡眠）
  • spin_lock(...) （自旋锁，忙等待而非睡眠）

如果把该在进程上下文做的事放在了中断上下文，或者反之，轻则导致内核错误，重则直接让系统崩溃。所以，理解上下文是内核开发的基石。

2. 为什么有上下文

想象一下，Linux 内核就是一个非常繁忙的公司办公室，这个办公室里有：

• 多个员工（CPU核心）：可以同时处理多项工作（SMP多核系统）。
• 一位总经理（内核调度器）：负责分配任务，决定谁该做什么。

第一种方式：项目计划（进程上下文）

这是最常规、最主流的工作方式。

• 怎么触发的？

  • 就像外部客户（用户程序）打电话来（系统调用）说：“我们要做一个新项目（比如，读取一个文件）。”
  • 或者，员工在处理当前项目时发现缺了份关键材料（异常，比如页错误），需要先去申请这份材料。

• 工作状态（技术原理）：

  • 有身份：做这个项目的员工有明确的工位、名片（task_struct），代表公司（内核）为客户（用户进程）服务。
  • 可以被打断：总经理（调度器）可以随时让这个员工 “停一下，先去干个更急的事”（被抢占）。
  • 可以等待：如果项目需要等第三方快递（比如硬盘读写数据），员工可以 “先去泡杯咖啡休息一下”（睡眠），等快递到了再被叫醒继续工作。这不会浪费办公室资源。

• 适用场景（Use Case）：

  • 处理所有客户明确提出的、不那么紧急的需求。是最常见的执行环境。比如系统调用：open, read, write，或者内核线程在后台做内存整理等维护工作。

• 并发与影响：

  • 多个员工（多核）可以同时做不同的项目（真正并发）。
  • 一个员工在做项目A时，可能被总经理叫停，转去做项目B（伪并发/抢占）。
  • 如果两个项目需要同一份共享文件（共享数据），他们需要定个规矩——比如在文件上贴个“使用中”的便签（互斥锁mutex）——以免互相干扰。

• 技术原理：当用户程序执行系统调用或发生异常时，CPU从用户态切换到内核态。但此时代码仍在为原进程服务，拥有进程的所有资源（内存、文件描述符等）。因为它背后有一个完整的进程，所以它可以被调度器挂起（睡眠）或抢占。

第二种方式：紧急电话（中断上下文）

这是最高优先级、最紧急的工作方式。

• 怎么触发的？

  • 就像办公室的紧急热线电话（硬件中断） 突然响了！比如消防铃（硬件故障）、重要客户专线（网卡收到数据包）。

• 工作状态（技术原理）：

  • 没身份：接电话的员工不代表任何特定客户项目，他是以公司名义紧急响应。
  • 绝对不能停：接电话时，员工必须立刻放下手头所有事情（抢占一切），全程处理这个紧急事件。
  • 必须速战速决：电话内容必须极其简短。绝对不能在电话里说：“你等等，我先睡一觉”（禁止睡眠）。因为电话线占着，别人打不进来（不快速处理会导致中断丢失）。

• 适用场景：

  • 处理硬件最紧急的瞬间需求。比如：记录下键盘按了哪个键、告诉网卡“数据包我收到了你快去接下一个”。

• 并发与影响：

  • 紧急电话会粗暴地打断任何正在进行的项目工作（进程上下文）。
  • 如果一个员工在接消防电话，另一个员工的电话也响了（另一个中断），可能会根据优先级决定谁先响（中断嵌套）。
  • 因为要求快，它通常只做记录工作（把数据包放到一个队列），然后马上挂电话，后续工作交给别人（下半部）。
  • 不同种类的中断可以在不同CPU上同时发生，因此共享数据需用spin_lock_irqsave()保护。

• 技术原理：硬件中断到来时，CPU强制暂停当前工作，跳转到中断处理函数。该函数不与任何进程关联，它异步地打断了当前执行流。因为它需要极速响应并恢复被中断的工作，所以绝对不允许睡眠（睡眠会导致系统死锁）。

第三种方式：事后待办清单（下半部机制）

紧急电话（中断）虽然挂断了，但事情还没完。接电话的员工快速写了几张“待办事项”贴在看板上，后续来处理。这就是下半部（Bottom Half）。

下半部主要有三种实现：

c. 工作队列 (Workqueues)

主要有三种待办清单：

1. 高优先级待办（软中断 / Tasklets）

• 技术原理：

  • 这张清单上的事情仍然很急，但不用像电话那样瞬间响应。
  • 员工会在挂断紧急电话后、回去做项目前，赶紧先看看并处理这些高优先级待办。
  • 工作状态：处理这些待办时，仍然不能休息（不能睡眠），但可以稍微花点时间。
  • 区别：
    • 软中断：就像“处理所有客户投诉”清单。多个员工（多核）可以同时处理同一张清单上的不同投诉（并发执行），所以需要非常小心地协调（用自旋锁）。
    • Tasklets：就像“更换打印机墨盒”清单。一件事只允许一个员工来做，即使多个员工看到清单了，也会自动协商好只有一个人动手（串行执行），更简单安全。

• 适用场景：

  • 软中断：处理大量网络数据包（内核的NET_RX）、定时器回调等高性能需求场景。
  • Tasklets：大多数设备驱动中断后需要完成的后续工作，比如处理刚刚记录下来的键盘数据。

• 技术原理：内核预定义的一组（10个）高优先级队列。在中断处理末尾或由特定内核线程（ksoftirqd）检查并执行。执行时仍处于一种类似中断的上下文，禁止睡眠。

2. 普通待办（工作队列）

• 技术原理：

  • 这张清单上的事情不急了，可以慢慢做。
  • 公司专门请了几个后勤人员（内核工作线程），他们的工作就是不停地检查这个“普通待办”清单，有活就干。
  • 关键！ 后勤人员是正常员工，所以他们干活时累了可以休息（可以睡眠），等第三方快递（慢速I/O）都没问题。因此可以使用互斥锁、信号量等可能引起睡眠的机制。默认情况下，工作项可以在多个CPU上并发执行。

• 适用场景：

  • 任何不紧急、耗时长、可能需要等待的工作。比如：把刚收到的一大块数据真正写入磁盘、驱动模块的延迟初始化。

• 技术原理：将工作项排入队列，由专用的内核线程在后台取出执行。因为执行体是内核线程，所以它运行在进程上下文。

睡眠能力&优先级&抢占&并发

1. 睡眠能力：

   • 进程上下文和工作队列可以睡眠，因为它们背后有进程支撑。
   • 中断上下文、软中断和Tasklets绝对禁止睡眠，因为它们会破坏内核的异步响应能力。

2. 优先级与抢占：

   • 中断上下文拥有最高优先级，可以抢占一切。
   • 软中断/Tasklets优先级次之，会抢占进程上下文。
   • 进程上下文和工作队列优先级最低，可以被其他所有上下文抢占。

3. 并发性（关键区别）：

   • 软中断：追求极致性能，允许同类型任务在不同CPU上真正并发，因此编程最难。
   • Tasklets：简化编程，同类型任务在任何时刻只在一个CPU上运行（自动串行化）。
   • 工作队列：默认并发，但可通过绑定到特定CPU来控制。

4. 选择指南：

   • 需要睡眠或长时间运行？ -> 选工作队列。
   • 在中断处理程序中，需要快速完成非紧急工作？ -> 选Tasklets（简单安全）。
   • 对性能有极端要求，且能处理好复杂同步？ -> 选软中断。
   • 处理硬件最紧急的瞬间响应？ -> 在中断上下文中完成。

3. 不同上下文之间的关系

软中断和内核线程ksoftirqd的关系

软中断和内核线程是两种不同但协同工作的机制。内核线程（特指 ksoftirqd）是软中断的一种后备执行者，而不是“拉起”者。软中断的主要执行路径是硬件中断本身。

1. 软中断的执行触发点（谁“拉起”软中断？）

软中断的真正“拉起”者，是硬件中断处理流程。整个过程如下：

1. 硬件中断发生：网卡收到数据包，向CPU发出中断信号。
2. CPU执行中断处理程序（上半部）：
   • 快速应答硬件，将数据从硬件缓冲区移动到内核的队列（skb_queue）。
   • 在退出中断处理程序之前，会调用 irq_exit() 函数。
3. irq_exit() 的关键作用：
   • 在这个函数中，内核会检查是否有待处理的软中断（pending的软中断）。
   • 如果有，并且当前没有在中断上下文中，内核会立即执行软中断处理函数（如 net_rx_action 用于网络接收）。
   • 这被称为 “从中断返回路径中执行软中断”。

所以，软中断的首要和最快的执行者，是刚刚处理完硬件中断的那个CPU核心。它是在中断上下文的“尾巴”上执行的，优先级非常高，几乎无延迟。

2. 内核线程 (ksoftirqd) 的角色：为什么需要它？

既然中断返回路径已经能执行软中断，为什么还需要 ksoftirqd 这个内核线程？原因在于负载保护。

想象一个场景：一个高速网络环境下，每秒有成千上万个数据包到达。每次网卡中断都会触发软中断处理。

• 问题：如果中断太频繁，导致软中断的处理量巨大，CPU就会长时间停留在中断返回路径中执行软中断，而无法返回到被中断的进程上下文。从用户角度看，系统就会失去响应，ssh命令卡顿，鼠标移动迟缓。这种现象称为 “活锁”（livelock）——CPU忙得要死（100%利用率），但有用的工作（进程调度）却无法推进。

• 解决方案：ksoftirqd 内核线程就是解决这个问题的安全阀。它的工作逻辑是：

  1. 每个CPU核心都有自己专属的 ksoftirqd/x 线程（x 是CPU编号），优先级较低（nice=19）。
  2. 在中断返回路径 irq_exit() 中，内核如果发现本次触发的软中断太多，或者有软中断被重复触发，它就不会在原地执行完所有软中断，而是选择只执行一部分，然后唤醒本地的 ksoftirqd 线程，让它去处理剩下的软中断。
  3. ksoftirqd 线程作为普通的内核线程，它的优先级很低。当它运行时，如果有一个用户进程想要运行，调度器会优先调度用户进程，抢占 ksoftirqd。这样就保证了系统的交互性，不会出现“活锁”。

所以，ksoftirqd 不是“拉起”软中断，而是被“委派”去处理那些来不及在中断路径中处理完的软中断工作。它是一种负载均衡和系统保护机制。

3. 内核线程能主动“拉起”软中断吗？

不能。 这是一个非常重要的区别。

• 软中断的触发（raise）：是通过 raise_softirq(NR_NET_RX) 这样的函数实现的。这个函数只是设置一个当前CPU的位图标志（标记哪个软中断类型待处理），然后根据上述逻辑，要么在中断退出时执行，要么由 ksoftirqd 执行。

  • 谁能调用 raise_softirq？ 通常是硬件中断处理程序（上半部），或者其他的软中断（自我触发）。

• 内核线程的角色：内核线程（包括 ksoftirqd）是消费者，它们是执行（serve） 软中断的，而不是触发（raise） 软中断的。ksoftirqd 线程的核心就是一个循环，不断检查是否有待处理的软中断，如果有就调用 __do_softirq() 来执行它们。

这是一个非常棒的问题，它触及了Linux内核并发模型的核心细节。

直接答案：不可以。ksoftirqd 内核线程在执行软中断处理函数时，绝对不允许睡眠。

虽然 ksoftirqd 本身是一个可以睡眠的内核线程，但当它调用软中断的处理函数（如 net_rx_action）时，它就进入了“软中断上下文”。这个上下文继承了许多中断上下文的严格限制，其中最重要的一条就是禁止睡眠。

4. ksoftirqd 内核线程 拉起软中断 可以睡眠吗？

第一层：ksoftirqd 线程本身 (可以睡眠)

ksoftirqd 是一个标准的内核线程。它的生命周期大致是这样的：

static int ksoftirqd_should_run(unsigned int cpu) // 检查是否有软中断需要处理
static void run_ksoftirqd(unsigned int cpu)       // 主要工作函数
{
    local_irq_disable(); // 关闭本地中断（短暂）
    if (local_softirq_pending()) { // 检查是否有待处理的软中断
        __do_softirq();   // 【核心】执行软中断！
        local_irq_enable(); // 开启本地中断
        cond_resched();    // 【重点】这里可能主动调度，意味着睡眠！
        return;
    }
    local_irq_enable();
}

请注意 cond_resched() 这个调用。在两次执行 __do_softirq() 的间隙，ksoftirqd 线程是可以主动调用调度器、让出CPU的（即睡眠）。这是设计上保证系统响应性的关键。

第二层：__do_softirq() 函数内部 (禁止睡眠)

__do_softirq() 是真正遍历和执行所有pending状态软中断函数的地方。一旦进入这个函数，就意味着代码运行在“软中断上下文”中。

在软中断上下文中，内核处于一个非常微妙的状态：

1. 它不是在一个明确的中断处理程序中，所以没有硬件中断那么紧急。
2. 但它又不在任何一个进程的上下文中。它异步执行，与任何用户进程无关。

正因为这种“无进程”的状态，如果代码睡眠，会发生灾难性后果：

• 调度器无法工作：调度器需要保存当前“进程”的上下文，以便后续恢复。但软中断上下文没有 task_struct 关联，调度器不知道要保存什么，也不知道以后要恢复给谁。
• 系统极可能死锁：睡眠意味着可能等待某个事件（如锁）。而唤醒事件可能永远无法发生，因为唤醒者可能在等待这个CPU执行其他任务（包括可能清理软中断的任务）。

因此，所有软中断处理函数（比如网络收包的 net_rx_action）的编写都必须遵守一条铁律：绝不调用任何可能间接导致睡眠的函数。这包括：

• 使用 GFP_KERNEL 标志的内存分配（应使用 GFP_ATOMIC）。
• 获取互斥锁（mutex_lock）（应使用自旋锁 spin_lock）。
• 调用 msleep()、wait_event() 等函数。

好的，我们来深入浅出地解析软中断（Softirq）和Tasklet之间的关系和区别。这是Linux内核中下半部（Bottom Half）处理的两个核心机制，理解它们对掌握内核并发编程至关重要。

软中断 和Tasklet的关系

一句话概括：Tasklet是基于软中断实现的一种更高层的抽象和封装。

你可以把它们想象成：

• 软中断：像是汇编语言或CPU指令。它强大、高效，但使用起来非常繁琐，需要开发者精心处理所有细节（尤其是并发问题）。
• Tasklet：像是基于汇编实现的高级语言（如C语言）。它牺牲了一点点性能，但提供了更简单、更安全、更不易出错的编程接口。

具体来说：

1. 实现依赖：Tasklet是通过两个特定的软中断实现的：HI_SOFTIRQ（高优先级）和 TASKLET_SOFTIRQ（普通优先级）。
2. 执行路径：当你调度一个Tasklet（tasklet_schedule()）时，内核内部实际上是raise了对应的软中断。随后，在软中断的执行函数（tasklet_action() 和 tasklet_hi_action()）中，才会遍历Tasklet链表并依次执行它们。

软中断的并行原理

软中断的设计目标是最大化并行以提升性能。每个CPU核心都有一个独立的位图（softirq_pending）来表示本CPU上有哪些软中断类型待处理。

• 当CPU从中断返回时，它会检查自己的位图。
• 如果发现 NET_RX_SOFTIRQ 被置位，它就会立刻执行网络收包函数 net_rx_action()。
• 关键在于：与此同时，另一个CPU核心可能也收到了网络包，它的 NET_RX_SOFTIRQ 位也被置位，并且也在同时执行 net_rx_action()。

因此，同一个软中断处理函数 net_rx_action() 完全可能同时在多个CPU上执行。这就要求该函数访问任何共享数据时，都必须使用自旋锁（spin_lock）等同步机制来保护，否则会导致数据损坏。

Tasklet的串行原理

Tasklet的设计目标是简化驱动开发者的编程难度。它的实现引入了per-CPU 的链表和状态标志。

• 每个Tasklet都有一个状态字段（state），其中有一个重要的位是 TASKLET_STATE_RUN。
• 当一个CPU核心开始执行某个Tasklet时，它会先原子地检查并设置 TASKLET_STATE_RUN 位。
• 如果设置成功，就执行这个Tasklet。
• 关键在于：如果这个Tasklet在另一个CPU上也被调度了，那个CPU在尝试执行它时，会发现 TASKLET_STATE_RUN 位已经被设置，于是它就不会执行这个Tasklet，而是跳过它，继续执行链表中的下一个。

这种“检查并设置”的操作是原子的，从而保证了同一个Tasklet实例在任何时刻都最多只有一个CPU核心在执行。开发者因此无需担心自己的Tasklet函数会在多个CPU上与自己并发，大大降低了编写代码的心智负担。

关系： Tasklet是构建在软中断之上的“语法糖”，旨在为驱动开发者提供一个更友好的API。