一、任务概念与TCB：什么是任务？任务控制块（TCB）的结构与作用
各位同学，咱们今天聊点实在的。任务这个概念，说白了就是操作系统里要干的一件「事儿」。你想想看，一个嵌入式系统里，可能同时要处理按键扫描、屏幕刷新、串口收发数据——这些「事儿」就是任务。
我刚开始做嵌入式开发那会儿，对任务的理解特别肤浅。觉得任务不就是个函数嘛，调一下不就完了？后来被现实狠狠教育了一顿——裸机编程里，一个延时函数就能把整个系统卡死。嗯，那时候我才真正明白，任务不是简单的函数调用，它是操作系统调度的基本单位。
1.1 什么是任务？
任务，也叫线程（Thread），是操作系统能够独立调度和执行的最小单位。每个任务都有自己的执行流、栈空间和一组寄存器上下文。
举个例子：你在手机上一边听音乐一边刷网页。听音乐是一个任务，刷网页是另一个任务。操作系统在它们之间快速切换，让你感觉是「同时」在运行。其实CPU在同一时刻只能干一件事，只是切换得够快，你感觉不到。
任务的核心特征：
- 独立性：每个任务有自己的栈和寄存器上下文
- 并发性：多个任务可以「同时」推进（宏观上）
- 动态性：任务可以创建、挂起、恢复、删除
- 调度性：任务的执行顺序由调度器决定
我在一个工业控制项目中遇到过这样的问题：两个任务同时访问一个全局变量，结果数据全乱了。后来加了互斥锁才解决。这就是任务之间需要同步和通信的原因——任务不是孤立的，它们共享CPU和内存资源。
1.2 任务控制块（TCB）是什么？
任务控制块，英文叫 Task Control Block，简称 TCB。你可以把它理解成任务的「身份证」和「档案袋」。
操作系统怎么管理几十上百个任务？靠的就是TCB。每个任务都有一个对应的TCB，里面记录了任务的所有关键信息。调度器看TCB就知道哪个任务该运行了，哪个任务在睡觉，哪个任务出了毛病。
我习惯把TCB比作医院的病历本。医生（调度器）翻看病历本，就知道病人（任务）的病史、当前状态、该用什么药（分配什么资源）。没有病历本，医生就抓瞎了。没有TCB，操作系统就没法管理任务。
个人经验： 我在移植FreeRTOS到一款国产MCU时，发现TCB结构体里有个字段对齐的问题，导致任务切换时栈指针错乱。查了两天才找到原因。所以大家写TCB相关代码时，一定要注意结构体对齐和内存布局。
1.3 TCB的结构
不同操作系统的TCB结构大同小异。我以最常见的嵌入式RTOS为例，给你看看TCB里都装了些什么。
// 一个典型的TCB结构体（简化版）
typedef struct tcb {
uint32_t *stack_ptr; // 栈指针，指向当前栈顶
uint32_t *stack_base; // 栈基址，栈的起始地址
uint32_t stack_size; // 栈大小，单位字节
uint8_t priority; // 任务优先级
uint8_t state; // 任务状态：就绪、运行、阻塞、挂起
char name[16]; // 任务名称，方便调试
void (*entry)(void*); // 任务入口函数
void *param; // 入口函数参数
uint32_t delay_ticks; // 延时计数，用于延时阻塞
struct tcb *next; // 链表指针，用于就绪队列等
} tcb_t;你看，这个结构体里包含了任务运行所需的一切。我挑几个重点说说：
| 字段 | 作用 | 我的理解 |
|---|---|---|
| stack_ptr | 保存当前栈顶位置 | 任务切换时，CPU寄存器就压在这里 |
| priority | 决定任务被调度的优先级 | 数值越小优先级越高（常见做法） |
| state | 标记任务当前处于什么状态 | 调度器只看这个字段决定要不要理你 |
| entry | 任务从哪里开始执行 | 就是你的任务函数地址 |
| delay_ticks | 延时阻塞的计时器 | 每次tick中断减1，减到0就醒来 |
注意： 我曾经见过一个新手把stack_size设得太小，结果任务函数里定义了一个大数组，直接把栈给踩爆了。系统跑着跑着就死机，查了三天才找到原因。所以栈大小一定要根据任务的实际需求来估算，留足余量。
1.4 TCB的作用
TCB的作用，说白了就是三件事：
- 记录任务身份：这个任务叫什么名字、优先级多高、入口在哪
- 保存任务上下文：任务被切换出去时，CPU寄存器的值全部保存到TCB的栈里。下次切回来时，从栈里恢复，任务就能接着上次的地方继续跑
- 管理任务状态：任务当前是就绪、运行还是阻塞？调度器根据TCB里的state字段来决定下一步操作
你想想看，如果没有TCB，操作系统怎么知道哪个任务该运行？怎么知道任务上次执行到哪一行代码？怎么知道任务的栈还剩多少空间？这些信息全都靠TCB来承载。
我做一个物联网网关项目时，系统里同时跑了12个任务。调试阶段经常要看TCB里的信息，比如某个任务的栈使用率、当前状态、优先级等。没有TCB，这种多任务系统根本没法调试和维护。
1.5 任务状态与状态转换
任务不是一直都能运行的。它有几种状态，我画个图给你看：
这个图我画得比较直观。任务在四个状态之间来回切换：
- 就绪：任务啥都准备好了，就等CPU来执行它
- 运行：任务正在占用CPU，代码正在执行
- 阻塞：任务在等某个事件，比如等串口数据、等延时结束
- 挂起：任务被强制暂停，需要别人来唤醒它
为什么会这样设计？你想想看，如果任务在等串口数据，还占着CPU不放，那其他任务就没法运行了。所以任务在等待的时候，主动让出CPU，把自己挂到阻塞队列里。等数据来了，再回到就绪队列，等待调度器分配CPU。
避坑指南： 我曾经在一个项目中，有个任务在阻塞态里等了很久的资源，结果其他任务都跑完了它还没醒。后来发现是资源释放的条件写错了，导致这个任务永远等不到资源。这就是所谓的「死等」问题。所以写阻塞代码时，一定要确认唤醒条件一定能被满足。
1.6 小结
任务和TCB是操作系统的基石。没有任务，操作系统就是个空壳。没有TCB，任务就是一盘散沙。理解透这两个概念，后面学调度策略、同步机制、内存管理，都会轻松很多。
我个人建议，初学者可以自己动手写一个简单的TCB结构体，然后模拟一下任务切换的过程。不用跑在真实硬件上，用C语言在PC上模拟就行。我当年就是这么干的，写了一个只有两个任务的「迷你操作系统」，虽然简陋，但对理解任务调度帮助特别大。
嗯，今天就聊到这儿。记住一句话：TCB是任务的灵魂，调度器是操作系统的心脏。两者缺一不可。
可可精品资料库