Linux驱动开发实战：信号量与互斥体的并发控制策略

1. 并发控制：Linux驱动开发的核心挑战

在Linux驱动开发中，多个进程或线程同时访问共享资源是家常便饭。想象一下，你的设备驱动程序需要处理来自不同应用程序的并发请求，比如多个用户程序同时读取传感器数据或控制同一个硬件设备。如果不加以控制，这种并发访问就会导致数据错乱、系统崩溃，甚至硬件损坏。

我刚开始做驱动开发时就踩过这个坑。当时写了一个简单的字符设备驱动，没有加任何保护措施，结果两个进程同时写入设备时，系统直接卡死了。后来才发现是并发访问导致了资源竞争。这种问题在真实项目中太常见了，所以掌握并发控制是每个驱动开发者必备的技能。

Linux内核提供了多种并发控制机制，其中最常用的就是信号量和互斥体。它们看起来相似，但在使用场景和性能表现上有着重要区别。选择合适的同步机制，往往决定了驱动的稳定性和性能表现。

2. 信号量：灵活的计数型同步机制

2.1 信号量的工作原理

信号量本质上是一个计数器，用来控制对共享资源的访问。它有两种基本类型：二元信号量（值只能是0或1）和计数信号量（值可以大于1）。计数信号量允许多个进程同时访问资源，只要不超过设定的限制。

我记得第一次用信号量是在一个网络设备驱动中。我们需要限制同时处理的数据包数量，避免内存耗尽。使用计数信号量就完美解决了这个问题 - 初始化时设置最大并发数，每个处理线程在开始前获取信号量，完成后释放。

#include <linux/semaphore.h>

// 定义并初始化信号量
static struct semaphore data_sem;
sema_init(&data_sem, 5); // 允许最多5个并发访问

// 在访问共享资源前
if (down_interruptible(&data_sem)) {
    // 被信号中断的处理
    return -ERESTARTSYS;
}

// 访问共享资源...
// 完成后释放
up(&data_sem);

2.2 信号量的三种获取方式

信号量提供了三种不同的获取方式，适应不同的使用场景：

down() 会一直等待直到获取信号量，这个过程不可被中断。适合那些必须完成的操作，但如果长时间等待可能会导致进程无法响应信号。

down_interruptible() 是我最常用的方式。它允许在等待时被信号中断，返回 -EINTR。这样用户空间程序可以通过Ctrl+C等方式中断操作，提高了用户体验。

down_trylock() 是非阻塞版本，立即返回获取结果。适合那些不需要严格同步，或者有备选方案的场景。

在实际项目中，我一般会优先选择 down_interruptible()，因为它既保证了同步，又不会让进程无法响应外部信号。特别是在用户空间接口的驱动中，这种可中断的等待非常重要。

3. 互斥体：专为互斥访问设计

3.1 互斥体的特性与优势

互斥体是专门为互斥访问设计的同步机制，它比二元信号量更加高效和安全。互斥体具有所有权概念，只有锁的持有者才能解锁，这避免了某些编程错误。

我在一个硬件控制驱动中深刻体会到了互斥体的价值。该驱动需要精确控制硬件的状态转换，任何并发访问都会导致硬件进入不可预测状态。使用互斥体确保了任何时候只有一个线程能操作硬件。

#include <linux/mutex.h>

// 定义并初始化互斥体
static DEFINE_MUTEX(hardware_mutex);

// 在硬件操作前
mutex_lock(&hardware_mutex);

// 执行硬件操作...
// 完成后解锁
mutex_unlock(&hardware_mutex);

互斥体相比信号量的一个重要优势是调试支持。内核提供了死锁检测机制，能够帮助开发者发现潜在的死锁问题。这对于复杂的驱动特别有用，因为并发问题往往很难重现和调试。

3.2 互斥体的使用模式

互斥体有两种获取方