第2章任务与进程基础

二、任务与进程基础：任务的概念、任务状态转换、任务控制块(TCB)、任务优先级

好，咱们开始进入正题。这一章讲的是任务与进程的基础，说白了就是搞清楚机顶盒里那些程序到底是怎么“活”起来的。我做了这么多年机顶盒开发，发现很多新手工程师上来就写代码，结果系统跑起来各种卡顿、死机，最后查来查去，都是对任务的基本概念没吃透。嗯，咱们今天就把这块地基打牢。

任务是什么？我个人的理解是：任务就是一段程序加上它运行时的“上下文”。你想想看，光有代码不行，CPU得知道它执行到哪一行了、用到了哪些寄存器、堆栈里存了什么数据。这些信息合在一起，才构成一个完整的任务。

在机顶盒这种嵌入式系统里，任务和进程其实差别不大。我们通常说“任务”，因为它更轻量，切换开销小。我见过一些同事把PC上的多进程概念硬套过来，结果在资源受限的机顶盒上跑得惨不忍睹。说白了，机顶盒里跑的是实时操作系统（RTOS），任务就是它的基本调度单位。

核心要点：任务 = 代码 + 数据 + 执行状态。缺一不可。

举个例子，机顶盒里有个“播放视频”的任务，它负责从网络接收数据、解码、然后送显示。这个任务在运行的时候，CPU会一直执行它的代码。但如果用户按了“暂停”键，这个任务就得停下来，让出CPU给其他任务（比如处理遥控器输入的任务）。

任务不是一直傻跑的状态。它会在几个状态之间跳来跳去。我刚开始学的时候，觉得状态图很抽象，后来在项目里调试一个死锁问题，才真正体会到状态转换的重要性。

一般来说，任务有四种基本状态：

状态之间的转换，我画个简单的流程给你看：

创建 → 就绪 → 运行 → 阻塞
                ↑      ↓
                └── 就绪 ←┘

嗯，这里要注意：只有就绪态的任务才能被调度器选中去运行。我曾经遇到过一个bug，一个任务因为等不到信号量，一直卡在阻塞态，结果整个系统的响应都变慢了。查了半天才发现，是另一个任务释放信号量的逻辑写错了。

我的经验：调试任务状态转换时，可以用RTOS提供的调试工具打印每个任务的状态。我习惯在关键转换点加日志，比如“任务A从就绪进入运行”、“任务B因等待信号量进入阻塞”。这样能快速定位问题。

任务控制块，英文叫Task Control Block，简称TCB。你可以把它想象成任务的“身份证”或者“档案袋”。操作系统就是靠TCB来管理每个任务的。

TCB里都存了啥？我列一下常见的字段：

我记得有一次，系统莫名其妙地重启。我查了所有代码都没发现问题，最后用调试器打印了所有任务的TCB，发现有一个任务的堆栈指针指向了非法地址。原来是那个任务的堆栈空间设置得太小，溢出了。从那以后，我每次创建任务都会仔细算好堆栈大小，再留点余量。

避坑指南：我曾经因为TCB中的堆栈指针被意外修改，导致任务切换时CPU跑飞。所以，千万不要在任务代码里直接操作TCB的字段，那是操作系统的事。你只管调用API就好。

优先级，说白了就是给任务排个队。高优先级的任务先跑，低优先级的后跑。机顶盒里通常用抢占式调度，意思是高优先级任务一旦就绪，可以立刻打断正在运行的低优先级任务。

我个人的习惯是：优先级不要设太多级。比如32级就够用了，设个256级反而容易搞乱。你想想看，优先级差1级，实际效果可能差别不大，但调试起来头都大了。

常见的优先级分配策略：

这里有个经典问题叫优先级反转。简单说就是：一个高优先级任务在等一个低优先级任务占用的资源，而那个低优先级任务又被一个中等优先级任务抢占了CPU。结果高优先级任务反而被“饿死”了。

我在一个项目中就遇到过。当时机顶盒播放高清视频时，偶尔会卡顿一下。查了很久才发现，是视频解码任务（高优先级）在等一个共享缓冲区，而这个缓冲区被一个低优先级的网络任务占着。网络任务又被一个中等优先级的UI任务抢占了CPU。最后用优先级继承协议解决了这个问题。

关键点：设置优先级时，一定要考虑任务之间的资源依赖关系。别光看任务本身的实时性要求。

这一章的内容，说白了就是让你明白：任务不是凭空跑起来的，它有自己的生命周期、有自己的“档案”（TCB），还有优先级来决定谁先跑。这些概念是后面讲多任务调度、资源管理的基础。

嗯，我建议你学完这章后，去翻翻你用的RTOS的源码，看看TCB结构体到底长什么样。我当时就是这么干的，看完之后对任务的理解一下子就通了。

下一章咱们聊聊任务调度算法，看看操作系统是怎么决定“下一个该谁跑”的。