线程安全需要加锁吗？家用路由器开发中的真实场景

在家用路由器的固件开发中，多个设备同时连接、数据转发、配置更新等操作其实都涉及多线程。比如你刷剧时，孩子在上网课，老人在视频通话，这些请求可能同时被系统处理。这时候，多个线程访问同一个资源，比如共享的配置表或网络状态变量，就容易出问题。

不加锁会怎样？

假设路由器有一个记录在线设备数量的全局变量 device_count。两个线程同时执行增加操作：线程A读取值为5，准备写回6；与此同时线程B也读取到5，也写回6。最终结果是6，而不是应有的7。这种“竞态条件”会导致统计不准，甚至触发错误的限速或告警。

加锁是不是唯一办法？

不一定。加锁是最常见的手段，比如使用互斥量（mutex）保护共享资源：

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
int device_count = 0;

void add_device() {
    pthread_mutex_lock(&lock);
    device_count++;
    pthread_mutex_unlock(&lock);
}

这样能保证同一时间只有一个线程修改 device_count，解决了冲突。但锁也不是万能的。如果锁的粒度太粗，比如整个配置模块都用一把锁，那本来可以并行处理的Wi-Fi设置和家长控制修改也会互相阻塞，导致界面卡顿。

有没有不加锁也能安全的方式？

有。比如用原子操作。现代处理器支持对某些类型的操作（如整数增减）做到“不可分割”。在C11中可以用 atomic_int：

#include <stdatomic.h>
atomic_int device_count = 0;

void add_device() {
    atomic_fetch_add(&device_count, 1);
}

这种方式无需锁，性能更高，适合简单变量。再比如，有些场景可以通过设计避免共享，每个线程处理自己的数据副本，最后合并，像日志系统里每个线程写独立缓冲区，再由主线程统一输出。

所以，线程安全不等于必须加锁。关键看场景：频繁读写简单变量，优先考虑原子操作；复杂数据结构或临界区较长，锁更稳妥；而通过架构设计减少共享，才是治本之法。家里的智能网关越来越复杂，理解这些细节，才能让网络更稳、响应更快。