Android GKI内核5.15中的锁机制详解

前言

在现代操作系统内核开发中，并发控制是一个至关重要的主题。随着多核处理器的普及和内核抢占机制的引入，Linux内核开发者必须深入理解各种锁机制的原理和适用场景。本文将深入剖析Android GKI内核5.15版本中的锁机制，帮助开发者正确使用这些同步原语。

并发问题的本质

竞态条件(Race Condition)

竞态条件是多线程编程中最常见的问题之一。当多个执行线程同时访问共享资源，且至少有一个线程在修改资源状态时，就可能出现不可预期的结果。

举例说明：

very_important_count++;

这段看似简单的自增操作，在多线程环境下可能产生意外的结果。理想情况下，两个线程应该顺序执行自增操作，但实际上可能同时读取相同的值，导致最终结果比预期少1。

临界区(Critical Region)

临界区是指包含共享资源访问的代码段，这些代码段需要保证原子性执行。内核提供了多种锁机制来保护临界区，确保同一时间只有一个执行线程可以进入临界区。

Linux内核中的锁机制

基本原则

内核锁机制设计的第一原则是：保持简单。开发者应当谨慎引入新的锁，避免过度设计。

两种主要锁类型

1. 自旋锁(Spinlock)

   • 特性：忙等待锁，持有者不会主动放弃CPU
   • 适用场景：短时持有的锁，不可睡眠的上下文（如中断处理）
   • 头文件：include/asm/spinlock.h

2. 互斥锁(Mutex)

   • 特性：阻塞锁，获取不到锁时会睡眠
   • 适用场景：可能长时间持有的锁，进程上下文
   • 头文件：include/linux/mutex.h

需要注意的是，这两种锁都不是递归锁，同一线程重复获取会导致死锁。

不同上下文中的锁使用

用户上下文中的锁

当共享数据仅在用户上下文（系统调用）中被访问时，使用互斥锁是最简单的选择。常用函数：

• mutex_lock_interruptible()：可被信号中断的加锁
• mutex_unlock()：解锁

用户上下文与软中断共享数据

当数据在用户上下文和软中断之间共享时，需要使用spin_lock_bh()：

• 禁用本地CPU的软中断
• 获取自旋锁 对应的解锁函数是spin_unlock_bh()

任务let和定时器之间的锁

• 相同任务let/定时器：无需额外锁，因为它们不会在多个CPU上并发执行
• 不同任务let/定时器：使用spin_lock()和spin_unlock()

硬件中断上下文

在硬件中断处理程序中共享数据时：

• 与软中断/任务let共享：使用spin_lock_irq()，它会禁用本地中断
• 与另一个中断处理程序共享：使用spin_lock_irqsave()，它会保存中断状态

锁使用速查表

以下是不同上下文间共享数据时的最小锁需求：

上下文	IRQ Handler	Softirq	Tasklet	Timer	User Context
IRQ Handler	-	SLI	SLI	SLI	SLI
Softirq	SLI	SL	SL	SL	SLBH
Tasklet	SLI	SL	-	SL	SLBH
Timer	SLI	SL	SL	-	SLBH
User Context	SLI	SLBH	SLBH	SLBH	MLI

缩写说明：

• SLIS: spin_lock_irqsave
• SLI: spin_lock_irq
• SL: spin_lock
• SLBH: spin_lock_bh
• MLI: mutex_lock_interruptible

实际应用示例

用户上下文中的缓存实现

下面是一个在用户上下文中实现的简单缓存系统，使用互斥锁保护共享数据：

#include <linux/list.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/mutex.h>
#include <asm/errno.h>

struct object {
    struct list_head list;
    int id;
    char name[32];
    int popularity;
};

static DEFINE_MUTEX(cache_lock);
static LIST_HEAD(cache);
static unsigned int cache_num = 0;
#define MAX_CACHE_SIZE 10

/* 必须在持有cache_lock时调用 */
static struct object *__cache_find(int id)
{
    struct object *i;
    list_for_each_entry(i, &cache, list)
        if (i->id == id) {
            i->popularity++;
            return i;
        }
    return NULL;
}

/* 缓存添加和删除函数实现... */

int cache_add(int id, const char *name)
{
    struct object *obj;
    /* 分配内存等操作... */
    mutex_lock(&cache_lock);
    __cache_add(obj);
    mutex_unlock(&cache_lock);
    return 0;
}

void cache_delete(int id)
{
    mutex_lock(&cache_lock);
    __cache_delete(__cache_find(id));
    mutex_unlock(&cache_lock);
}

最佳实践建议

1. 锁的粒度：保持锁的持有时间尽可能短，避免在锁内进行耗时操作
2. 锁的顺序：当需要多个锁时，确保所有线程以相同的顺序获取锁，避免死锁
3. 测试验证：即使在单处理器系统上，也要使用CONFIG_SMP和CONFIG_PREEMPT配置测试代码
4. 性能考量：对于高频访问的临界区，考虑使用读写锁或RCU等高级同步机制

通过深入理解这些锁机制和正确使用它们，开发者可以构建出既安全又高效的Android内核代码。