三、软件看门狗：任务级看门狗实现、多线程喂狗策略、死锁检测与恢复
软件看门狗，说白了就是给系统装了个心跳监测仪。
硬件看门狗大家都不陌生，但真正到了多任务、多线程的复杂系统里，硬件看门狗往往只能告诉你「系统挂了」，却说不清「谁把系统搞挂的」。这时候，软件看门狗的价值就体现出来了。
我个人习惯把软件看门狗分成三个层次：任务级、线程级、系统级。今天咱们重点聊前两个，再加上死锁检测这个老大难问题。
3.1 任务级看门狗：给每个任务装上心跳
任务级看门狗的核心思想很简单：每个周期性任务都要在规定时间内「签到」。如果某个任务超时未签到，就说明它可能卡住了。
我在项目中遇到过这样一个案例：一个伺服驱动的电流环任务，周期是100μs。正常情况下，每次执行完都会更新一个时间戳。结果有一次，因为某个中断优先级配置错误，电流环被长时间阻塞，电机直接抖成了筛子。硬件看门狗没触发，因为系统还在跑，但电流环已经废了。
从那以后，我坚持给每个关键任务都配一个软件看门狗。
任务级看门狗的实现要点：
- 每个任务维护一个「最后喂狗时间戳」
- 监控线程定期检查所有任务的时间戳
- 超时阈值一般设为任务周期的2~3倍
- 超时后触发回调：记录日志、尝试恢复、或安全停机
// 任务级看门狗 - 简化实现
typedef struct {
uint32_t task_id;
uint32_t last_feed_time; // 最后喂狗时间（ms）
uint32_t timeout_ms; // 超时阈值
uint8_t is_alive; // 是否存活
void (*on_timeout)(uint32_t task_id);
} TaskWatchdog_t;
void TaskWatchdog_Feed(uint32_t task_id) {
// 更新喂狗时间戳
g_task_wd[task_id].last_feed_time = GetSysTickMs();
g_task_wd[task_id].is_alive = 1;
}
void TaskWatchdog_Monitor(void) {
uint32_t now = GetSysTickMs();
for (int i = 0; i < TASK_COUNT; i++) {
if ((now - g_task_wd[i].last_feed_time) > g_task_wd[i].timeout_ms) {
// 超时！触发恢复机制
g_task_wd[i].is_alive = 0;
if (g_task_wd[i].on_timeout) {
g_task_wd[i].on_timeout(i);
}
}
}
}避坑指南：我曾经犯过一个低级错误——把喂狗操作放在了中断服务函数里。结果任务本身已经卡死了，中断却还在正常触发，看门狗永远不超时。记住：喂狗必须在任务上下文中执行，不能放在中断里。
3.2 多线程喂狗策略：别让看门狗饿死
多线程环境下的喂狗，比单任务复杂得多。你想想看，如果多个线程共用一个看门狗，一个线程喂了，另一个线程卡了，看门狗会不会误判？
答案是：会。
所以多线程喂狗，核心策略就是「独立喂狗、统一监控」。每个线程有自己的看门狗实例，监控线程统一检查。
我常用的策略有三种：
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 独立看门狗 | 线程数少（<10） | 隔离性好，定位精准 | 资源开销大 |
| 分组看门狗 | 线程按功能分组 | 平衡开销与精度 | 组内无法区分 |
| 层级看门狗 | 复杂系统 | 可嵌套，灵活 | 实现复杂 |
我个人最常用的是独立看门狗策略。虽然资源开销大一点，但排查问题的时候，能直接定位到是哪个线程卡了，省去大量调试时间。
// 多线程喂狗 - 独立看门狗示例
void* Thread_ControlLoop(void* arg) {
uint32_t thread_id = (uint32_t)arg;
while (1) {
// 执行控制算法
DoControl();
// 喂狗
TaskWatchdog_Feed(thread_id);
// 精确延时
usleep(1000); // 1ms周期
}
}
void* Thread_Monitor(void* arg) {
while (1) {
TaskWatchdog_Monitor();
sleep(1); // 每秒检查一次
}
}注意：喂狗频率不是越高越好。我曾经见过一个项目，喂狗线程每100μs喂一次，结果看门狗监控线程本身占用了大量CPU。喂狗周期建议设为任务周期的1/2到1/3，既保证及时性，又不浪费资源。
3.3 死锁检测与恢复：系统卡死的最后防线
死锁，是运动控制系统里最让人头疼的问题之一。两个任务互相等待对方释放资源，谁也动不了。
为什么会这样？说白了就是资源分配顺序出了问题。比如任务A先拿锁1再拿锁2，任务B先拿锁2再拿锁1。如果时机凑巧，两人各拿一把锁，就死锁了。
我经历过最惨的一次：一个六轴机器人，在高速运动时发生了死锁。位置环和速度环互相等待，系统直接僵死。机器人带着惯性冲出去，撞坏了夹具。那次事故之后，我花了两周时间重构了整个锁机制。
死锁检测的常用方法：
- 超时检测：获取锁时设置超时，超时则判定可能死锁
- 资源分配图：维护一个图结构，检测是否存在环路
- 锁顺序检查：运行时检查锁的获取顺序是否一致
// 死锁检测 - 超时机制示例
int TryLockWithTimeout(pthread_mutex_t* mutex, uint32_t timeout_ms) {
struct timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += timeout_ms / 1000;
ts.tv_nsec += (timeout_ms % 1000) * 1000000;
int ret = pthread_mutex_timedlock(mutex, &ts);
if (ret == ETIMEDOUT) {
// 超时！记录死锁信息
LogDeadlockInfo(mutex);
// 尝试恢复：释放其他锁，重新尝试
return DEADLOCK_DETECTED;
}
return ret;
}死锁恢复策略（按优先级排序）：
- 资源抢占：强制释放低优先级任务的锁
- 任务回滚：回退到上一个安全状态
- 任务重启：杀死卡住的任务，重新创建
- 系统复位：最后手段，软件复位整个系统
嗯，这里要注意：恢复策略一定要有优先级。不能一检测到死锁就直接复位系统，那太粗暴了。我一般会先尝试资源抢占，如果不行再逐步升级。
个人经验：死锁最好的办法是预防，而不是检测。我现在的习惯是：所有锁的获取顺序必须全局统一，并且在代码审查时专门检查这一点。另外，能用无锁数据结构的地方，尽量不用锁。比如环形缓冲区、原子操作，很多时候比锁更靠谱。
3.4 软件看门狗的整体架构
说了这么多，咱们用一张图来总结软件看门狗的完整架构。这张图是我在实际项目中总结出来的，经过多次迭代才稳定下来。
这张图展示了我常用的三层架构：应用层任务负责喂狗，看门狗管理层负责监控和检测，恢复层负责处理异常。每一层各司其职，互不干扰。
最后说一句：软件看门狗不是万能的。它解决的是「任务卡死」和「死锁」问题，但解决不了「逻辑错误」和「数据异常」。那些问题，需要靠单元测试、边界检查、以及良好的编码习惯来保证。
嗯，关于软件看门狗，今天就聊这么多。记住：好的看门狗设计，应该像空气一样——平时感觉不到它的存在，但一旦出问题，它就是你最后的救命稻草。