Linux 并发与竞争
Linux 并发与竞争
并发与竞争
Linux 系统是个多任务操作系统,会存在多个任务同时访问同一片内存区域,这些任务可能会相互覆盖这段内存中的数据,造成内存数据混乱。针对这个问题必须要做处理,严重的话可能会导致系统崩溃。现在的 Linux 系统并发产生的原因很复杂,总结一下有下面几个主要原因:
①、多线程并发访问, Linux 是多任务(线程)的系统,所以多线程访问是最基本的原因。
②、抢占式并发访问,从 2.6 版本内核开始, Linux 内核支持抢占,也就是说调度程序可以在任意时刻抢占正在运行的线程,从而运行其他的线程。
③、中断程序并发访问,
④、 SMP(多核)核间并发访问,现在 ARM 架构的多核 SOC 很常见,多核 CPU 存在核间并发访问。
所谓的临界区就是共享数据段,对于临界区必须保证一次只有一个线程访问,也就是要保证临界区是原子访问的,原子访问就表示这一个访问是一个步骤,不能再进行拆分。
防止并发访问共享资源,换句话说就是要保护共享资源,防止进行并发访问,因为驱动程序各不相同,那么数据也千变万化,一般像全局变量,设备结构体这些肯定是要保护的,至于其他的数据就要根据实际的驱动程序而定了。
原子操作
原子操作就是指不能再进一步分割的操作,一般原子操作用于变量或者位操作。假如现在要对无符号整形变量 a 赋值,值为 3,对于 C 语言来讲很简单,直接就是:
a = 3
C 语言要先编译为成汇编指令, ARM 架构不支持直接对寄存器进行读写操作,比如要借助寄存器 R0、 R1 等来完成赋值操作。假设变量 a 的地址为 0X3000000,“a=3”这一行 C语言可能会被编译为如下所示的汇编代码:
示例代码 47.2.1.1 汇编示例代码
1 ldr r0, =0X30000000 /* 变量 a 地址 */
2 ldr r1, = 3 /* 要写入的值 */
3 str r1, [r0] /* 将 3 写入到 a 变量中 */
假设现在线程 A要向 a 变量写入 10 这个值,而线程 B 也要向 a 变量写入 20 这个值,可能得到的执行顺序如下:
但是实际上的执行流程可能如下图所示:
线程 A 最终将变量 a 设置为了 20,而并不是要求的 10!线程B 没有问题。这就是一个最简单的设置变量值的并发与竞争的例子,要解决这个问题就要保证三行汇编指令作为一个整体运行,也就是作为一个原子存在。 Linux 内核提供了一组原子操作 API 函数来完成此功能, Linux 内核提供了两组原子操作 API 函数,一组
是对整形变量进行操作的,一组是对位进行操作的。
原子整形操作 API 函数
Linux 内核定义了叫做 atomic_t 的结构体来完成整形数据的原子操作,在使用中用原子变量来代替整形变量,此结构体定义在 include/linux/types.h 文件中,定义如下:
示例代码 47.2.2.1 atomic_t 结构体
175 typedef struct {
176 int counter;
177 } atomic_t;
如果要使用原子操作 API 函数,首先要先定义一个 atomic_t 的变量,如下所示:
atomic_t a; //定义 a
也可以在定义原子变量的时候给原子变量赋初值,如下所示:
atomic_t b = ATOMIC_INIT(0); //定义原子变量 b 并赋初值为 0
可以通过宏 ATOMIC_INIT 向原子变量赋初值。原子变量有了,接下来就是对原子变量进行操作,比如读、写、增加、减少等等, Linux 内核提供了大量的原子操作 API 函数,如表所示:
ATOMIC_INIT(int i) 定义原子变量的时候对其初始化。
int atomic_read(atomic_t *v) 读取 v 的值,并且返回。
void atomic_set(atomic_t *v, int i) 向 v 写入 i 值。
void atomic_add(int i, atomic_t *v) 给 v 加上 i 值。
void atomic_sub(int i, atomic_t *v) 从 v 减去 i 值。
void atomic_inc(atomic_t *v) 给 v 加 1,也就是自增。
void atomic_dec(atomic_t *v) 从 v 减 1,也就是自减
int atomic_dec_return(atomic_t *v) 从 v 减 1,并且返回 v 的值。
int atomic_inc_return(atomic_t *v) 给 v 加 1,并且返回 v 的值。
int atomic_sub_and_test(int i, atomic_t *v) 从 v 减 i,如果结果为 0 就返回真,否则返回假
int atomic_dec_and_test(atomic_t *v) 从 v 减 1,如果结果为 0 就返回真,否则返回假
int atomic_inc_and_test(atomic_t *v) 给 v 加 1,如果结果为 0 就返回真,否则返回假
int atomic_add_negative(int i, atomic_t *v) 给 v 加 i,如果结果为负就返回真,否则返回假
如果使用 64 位的 SOC 的话,就要用到 64 位的原子变量, Linux 内核也定义了 64 位原子结构体,如下所示:
示例代码 47.2.2.2 atomic64_t 结构体
typedef struct {
long long counter;
} atomic64_t;
相应的也提供了 64 位原子变量的操作 API 函数,这里我们就不详细讲解了,和表 47.2.1.1中的 API 函数有用法一样,只是将“atomic_”前缀换为“atomic64_”,将 int 换为 long long。如果使用的是 64 位的 SOC,那么就要使用 64 位的原子操作函数。
例子:
示例代码 47.2.2.2 原子变量和 API 函数使用
atomic_t v = ATOMIC_INIT(0); /* 定义并初始化原子变零 v=0 */
atomic_set(&v, 10); /* 设置 v=10 */
atomic_read(&v); /* 读取 v 的值,肯定是 10 */
atomic_inc(&v); /* v 的值加 1, v=11 */
原子位操作 API 函数
位操作也是很常用的操作, Linux 内核也提供了一系列的原子位操作 API 函数,只不过原子位操作不像原子整形变量那样有个 atomic_t 的数据结构,原子位操作是直接对内存进行操作,API 函数如下所示:
void set_bit(int nr, void *p) 将 p 地址的第 nr 位置 1。
void clear_bit(int nr,void *p) 将 p 地址的第 nr 位清零。
void change_bit(int nr, void *p) 将 p 地址的第 nr 位进行翻转。
int test_bit(int nr, void *p) 获取 p 地址的第 nr 位的值。
int test_and_set_bit(int nr, void *p) 将 p 地址的第 nr 位置 1,并且返回 nr 位原来的值。
int test_and_clear_bit(int nr, void *p) 将 p 地址的第 nr 位清零,并且返回 nr 位原来的值。
int test_and_change_bit(int nr, void *p) 将 p 地址的第 nr 位翻转,并且返回 nr 位原来的值。
自旋锁
原子操作只能对整形变量或者位进行保护,但是,在实际的使用环境中怎么可能只有整形变量或位这么简单的临界区。设备结构体变量就不是整型变量,我们对于结构体中成员变量的操作也要保证原子性,在线程 A 对结构体变量使用期间,应该禁止其他的线程来访问此结构体变量,这些工作原子操作都不能胜任,需要本节要讲的锁机制,在 Linux内核中就是自旋锁。
当一个线程要访问某个共享资源的时候首先要先获取相应的锁, 锁只能被一个线程持有,只要此线程不释放持有的锁,那么其他的线程就不能获取此锁。对于自旋锁而言,如果自旋锁正在被线程 A 持有,线程 B 想要获取自旋锁,那么线程 B 就会处于忙循环-旋转-等待状态,线程 B 不会进入休眠状态或者说去做其他的处理,而是会一直傻傻的在那里“转圈圈”的等待锁可用。自旋锁的“自旋”也就是“原地打转”的意思,“原地打转”的目的是为了等待自旋锁可以用,可以访问共享资源。那就等待自旋锁的线程会一直处于自旋状态,这样会浪费处理器时间,降低系统性能,所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁,如果遇到需要长时间持有锁的场景那就需要换其他的方法了,
Linux 内核使用结构体 spinlock_t 表示自旋锁,结构体定义如下所示:
示例代码 47.3.1.1 spinlock_t 结构体
64 typedef struct spinlock {
65 union {
66 struct raw_spinlock rlock;
67
68 #ifdef CONFIG_DEBUG_LOCK_ALLOC
69 # define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map))
70 struct {
71 u8 __padding[LOCK_PADSIZE];
72 struct lockdep_map dep_map;
73 };
74 #endif
75 };
76 } spinlock_t;
在使用自旋锁之前,肯定要先定义一个自旋锁变量,定义方法如下所示:
spinlock_t lock; //定义自旋锁
自旋锁 API 函数
DEFINE_SPINLOCK(spinlock_t lock) 定义并初始化一个自选变量。
int spin_lock_init(spinlock_t *lock) 初始化自旋锁。
void spin_lock(spinlock_t *lock) 获取指定的自旋锁,也叫做加锁。
void spin_unlock(spinlock_t *lock) 释放指定的自旋锁。
int spin_trylock(spinlock_t *lock) 尝试获取指定的自旋锁,如果没有获取到就返回 0
int spin_is_locked(spinlock_t *lock)检查指定的自旋锁是否被获取,如果没有被获取就返回非 0,否则返回 0。
自旋锁API 函数适用于SMP或支持抢占的单CPU下线程之间的并发访问,
"SMP"是指“对称多处理”(Symmetric Multiprocessing)系统。在这种系统中,两个或多个处理器共享同一主内存和I/O设备,并且在操作系统的管理下平等地执行任务。这种架构与非对称多处理(Asymmetric Multiprocessing,AMP)相对,后者每个处理器或处理器组有专门的任务和可能有自己的内存或I/O设备。
SMP的特点:
- 处理器对等:所有处理器都具有相同的功能和对系统资源的访问能力。
- 内存共享:所有处理器共享同一物理内存,这意味着任何处理器都可以访问系统中的任何内存位置。
- 负载平衡:操作系统负责在所有处理器之间平衡负载,以提高效率和性能。
自旋锁在SMP系统中的应用:
在SMP系统中,由于多个处理器可能同时尝试访问共享资源,因此需要有效的同步机制来避免竞态条件和确保数据一致性。自旋锁是一种用于多线程同步的低级原语,特别适用于那些锁持有时间非常短的场景。
自旋锁的工作原理是:
- 当线程尝试获取一个已被其他线程持有的锁时,它将在一个循环中不断检查锁的状态(这个过程称为“自旋”),直到锁变为可用状态。
- 这意味着线程在等待锁的过程中会消耗CPU资源,因此自旋锁适用于锁持有时间短且线程不希望在操作系统层面进行上下文切换的情况。
也就是用于线程与线程之间,被自旋锁保护的临界区一定不能调用任何能够引起睡眠和阻塞的API 函数,否则的话会可能会导致死锁现象的发生。自旋锁会自动禁止抢占,也就说当线程 A得到锁以后会暂时禁止内核抢占。如果线程 A 在持有锁期间进入了休眠状态,那么线程 A 会自动放弃 CPU 使用权。线程 B 开始运行,线程 B 也想要获取锁,但是此时锁被 A 线程持有,而且内核抢占还被禁止了!线程 B 无法被调度出去,那么线程 A 就无法运行,锁也就无法释放,好了,死锁发生了!
下面看一个例子:
A先获取锁,并执行。当线程 A 运行 functionA 函数的时候中断发生了,中断抢走了 CPU 使用权。右边的中断服务函数也要获取 lock 这个锁,但是这个锁被线程 A 占有着,中断就会一直自旋,等待锁有效。但是中断服务函数执行完之前,线程A是不可能执行的。
最好的解决方法就是获取锁之前关闭本地中断, Linux 内核提供了相应的 API 函数,如表
47.3.2.2 所示:
函数 描述
void spin_lock_irq(spinlock_t *lock) 禁止本地中断,并获取自旋锁。
void spin_unlock_irq(spinlock_t *lock) 激活本地中断,并释放自旋锁。
void spin_lock_irqsave(spinlock_t *lock,
unsigned long flags)保存中断状态,禁止本地中断,并获取自旋锁。
void spin_unlock_irqrestore(spinlock_t*lock, unsigned long flags)将中断状态恢复到以前的状态,
并且激活本地中断,释放自旋锁。
使用 spin_lock_irq/spin_unlock_irq 的时候需要用户能够确定加锁之前的中断状态,但实际上内核很庞大,运行也是“千变万化”,我们是很难确定某个时刻的中断状态,因此不推荐使用spin_lock_irq/spin_unlock_irq。建议使用 spin_lock_irqsave/ spin_unlock_irqrestore,因为这一组函数会保存中断状态,在释放锁的时候会恢复中断状态。一般在线程中使用 spin_lock_irqsave/spin_unlock_irqrestore,在中断中使用spin_lock/spin_unloc
k.
示例代码 47.3.2.1 自旋锁使用示例
1 DEFINE_SPINLOCK(lock) /* 定义并初始化一个锁 */
2 3
/* 线程 A */
4 void functionA (){
5 unsigned long flags; /* 中断状态 */
6 spin_lock_irqsave(&lock, flags) /* 获取锁 */
7 /* 临界区 */
8 spin_unlock_irqrestore(&lock, flags) /* 释放锁 */
9 }
10
11 /* 中断服务函数 */
12 void irq() {
13 spin_lock(&lock) /* 获取锁 */
14 /* 临界区 */
15 spin_unlock(&lock) /* 释放锁 */
16 }
当然可以。让我们通过一个简单的网络数据包处理的例子来详细说明上半部和下半部是如何工作的,以及它们如何分离以提高系统的整体效率。
场景:网络数据包接收处理
假设一个网络设备(如以太网卡)接收到一个数据包,这会触发一个硬件中断。
上半部(Top Half):
- 中断触发:网络设备接收到数据包后,触发硬件中断。
- 中断服务例程(ISR)执行:
- 最小处理:ISR被调用,它的任务是尽快处理最紧急的事务。在这个例子中,ISR可能会读取数据包到一个缓冲区,并清除中断标志,以便网络设备可以继续接收更多数据包。
- 快速返回:ISR需要快速执行完毕,因为在执行ISR期间,大多数系统会禁止同一设备的其他中断,这可能会导致其他重要事件的延迟。
下半部(Bottom Half):
- 延迟处理:一旦ISR完成,它会调度一个下半部任务(如tasklet或work queue)来处理不那么紧急的工作。
- 处理数据包:
- 数据处理:下半部任务会处理ISR读入缓冲区的数据包。这可能包括检查数据包的完整性、执行路由决策、统计更新等。
- 转发/响应:根据数据包的内容,执行相应的动作,如向上层协议栈传递数据、生成响应或转发数据包。
- 允许中断:由于下半部的执行不会阻塞其他中断,系统可以继续响应其他硬件中断,这对于维持设备响应性至关重要。
为什么需要下半部?
使用下半部机制的主要原因是减少中断服务时间和提高系统的并发处理能力。通过将耗时的数据处理任务从ISR中剥离出来,我们保证了中断处理的快速执行,从而减少了对系统其他部分的干扰。此外,下半部可以在系统较不繁忙时执行,或者在多处理器系统中,可能在另一个CPU上并行执行,这进一步提高了系统的效率和吞吐量。
下半部里面使用自旋锁,可以使用表中的 API 函数:
函数 描述
void spin_lock_bh(spinlock_t *lock) 关闭下半部,并获取自旋锁。
void spin_unlock_bh(spinlock_t *lock) 打开下半部,并释放自旋锁。
其他类型的锁
1、读写自旋锁
比如存在一个数据,此表存放着学生的年龄、家庭住址、班级等信息,此表可以随时被修改和读取。自旋锁对其进行保护。每次只能一个读操作或者写操作,此表的读和写不能同时进行,但是可以多人并发的读取此表。像这样,当某个数据结构符合读/写或生产者/消费者模型的时候就可以使用读写自旋锁。
读写自旋锁为读和写操作提供了不同的锁,一次只能允许一个写操作,也就是只能一个线程持有写锁,而且不能进行读操作。但是当没有写操作的时候允许一个或多个线程持有读锁,可以进行并发的读操作。 Linux 内核使用 rwlock_t 结构体表示读写锁,结构体定义如下(删除了条件编译):
示例代码 47.3.3.1 rwlock_t 结构体
typedef struct {
arch_rwlock_t raw_lock;
} rwlock_t;
读写锁操作 API 函数分为两部分,一个是给读使用的,一个是给写使用的,这些 API 函数:
DEFINE_RWLOCK(rwlock_t lock) 定义并初始化读写锁
void rwlock_init(rwlock_t *lock) 初始化读写锁。
读锁
void read_lock(rwlock_t *lock) 获取读锁。
void read_unlock(rwlock_t *lock) 释放读锁。
void read_lock_irq(rwlock_t *lock) 禁止本地中断,并且获取读锁。
void read_unlock_irq(rwlock_t *lock) 打开本地中断,并且释放读锁。
void read_lock_irqsave(rwlock_t *lock,unsigned long flags)保存中断状态,禁止本地中断,并获取读锁。
void read_unlock_irqrestore(rwlock_t *lock,unsigned long flags)将中断状态恢复到以前的状态,并且
激活本地中断,释放读锁。
void read_lock_bh(rwlock_t *lock) 关闭下半部,并获取读锁。
void read_unlock_bh(rwlock_t *lock) 打开下半部,并释放读锁。
写锁
void write_lock(rwlock_t *lock) 获取写锁。
void write_unlock(rwlock_t *lock) 释放写锁。
void write_lock_irq(rwlock_t *lock) 禁止本地中断,并且获取写锁。
void write_unlock_irq(rwlock_t *lock) 打开本地中断,并且释放写锁。
void write_lock_irqsave(rwlock_t *lock,unsigned long flags)保存中断状态,禁止本地中断,并获取写锁。
void write_unlock_irqrestore(rwlock_t *lock,unsigned long flags)将中断状态恢复到以前的状态,并且激活本地
中断,释放读锁。
void write_lock_bh(rwlock_t *lock) 关闭下半部,并获取读锁。
void write_unlock_bh(rwlock_t *lock) 打开下半部,并释放读锁。
2、顺序锁
顺序锁的读和写操作可以同时进行,但是如果在读的过程中发生了写操作,最好重新进行读取,保证数据完整性。
顺序锁保护的资源不能是指针,因为如果在写操作的时候可能会导致指针无效,采用指针的时候,指针的不稳定性
当使用顺序锁保护一个指针时,如果在读操作进行时指针被写操作修改(例如指向另一个地址或被设为NULL),会出现以下问题:
指针失效:如果写操作改变了指针的指向,那么正在进行的读操作可能会继续使用旧的指针值访问已经不再有效或相关的内存地址。这可能导致访问已释放的内存,从而引发程序崩溃或数据损坏。
数据不一致:即使指针仍然有效,指向的数据可能在写操作中已经被修改。由于读操作在检查序列号前后可能会有延迟,它可能在数据结构不一致的状态下读取数据。这种情况下,读操作可能会得到部分更新的数据,导致数据不一致。
Linux 内核使用 seqlock_t 结构体表示顺序锁,结构体定义如下:
示例代码 47.3.3.2 seqlock_t 结构体
typedef struct {
struct seqcount seqcount;
spinlock_t lock;
} seqlock_t;
函数 描述
DEFINE_SEQLOCK(seqlock_t sl) 定义并初始化顺序锁
void seqlock_ini seqlock_t *sl) 初始化顺序锁。顺序锁写操作
void write_seqlock(seqlock_t *sl) 获取写顺序锁。
void write_sequnlock(seqlock_t *sl) 释放写顺序锁。
void write_seqlock_irq(seqlock_t *sl) 禁止本地中断,并且获取写顺序锁
void write_sequnlock_irq(seqlock_t *sl) 打开本地中断,并且释放写顺序锁。
void write_seqlock_irqsave(seqlock_t *sl,unsigned long flags)保存中断状态,禁止本地中断,并获取写顺序
锁。
void write_sequnlock_irqrestore(seqlock_t *sl,unsigned long flags)将中断状态恢复到以前的状态,并且激活本地中断,释放写顺序锁。
void write_seqlock_bh(seqlock_t *sl) 关闭下半部,并获取写读锁。
void write_sequnlock_bh(seqlock_t *sl) 打开下半部,并释放写读锁。顺序锁读操作
unsigned read_seqbegin(const seqlock_t *sl)读单元访问共享资源的时候调用此函数,此函数会返回顺序锁的顺序号。
unsigned read_seqretry(const seqlock_t *sl,unsigned start)读结束以后调用此函数检查在读的过程中有没有对资源进行写操作,如果有的话就要重读
自旋锁使用注意事项
因为在等待自旋锁的时候处于“自旋”状态,因此锁的持有时间不能太长,一定要短,否则的话会降低系统性能。如果临界区比较大,运行时间比较长的话要选择其他的并发处理方式,比如稍后要讲的信号量和互斥体。
②、自旋锁保护的临界区内不能调用任何可能导致线程休眠的 API 函数,否则的话可能导致死锁。
③、不能递归申请自旋锁,因为一旦通过递归的方式申请一个你正在持有的锁,那么你就必须“自旋”,等待锁被释放,然而你正处于“自旋”状态,根本没法释放锁。结果就是自己把自己锁死了!
④、在编写驱动程序的时候我们必须考虑到驱动的可移植性,因此不管你用的是单核的还是多核的 SOC,都将其当做多核 SOC 来编写驱动程序。
信号量
学过RTOS就知道信号量的定义和使用场景。下面来直接看信号量 API 函数:
Linux 内核使用 semaphore 结构体表示信号量,结构体内容如下所示:
示例代码 47.4.2.1 semaphore 结构体
struct semaphore {
raw_spinlock_t lock;
unsigned int count;
struct list_head wait_list;
};
有关信号量的 API 函数如表 47.4.2.1 所示:
函数 描述
DEFINE_SEAMPHORE(name) 定义一个信号量,并且设置信号量的值为 1。
void sema_init(struct semaphore *sem, int val) 初始化信号量 sem,设置信号量值为 val。
void down(struct semaphore *sem)获取信号量,因为会导致休眠,因此不能在中断中使用。
int down_trylock(struct semaphore *sem);尝试获取信号量,如果能获取到信号量就获取,并且返回 0。如果不能就返回非 0,并且不会进入休眠。
int down_interruptible(struct semaphore *sem)获取信号量,和 down 类似,只是使用 down 进入休眠状态的线程不能被信号打断。而使用此函数进入休眠以后是可以被信号打断的。
void up(struct semaphore *sem) 释放信号量
信号量的使用如下所示:
示例代码 47.4.2.2 信号量使用示例
struct semaphore sem; /* 定义信号量 */
sema_init(&sem, 1); /* 初始化信号量 */
down(&sem); /* 申请信号量 */
/* 临界区 */
up(&sem); /* 释放信号量 */
互斥体
在 FreeRTOS 和 UCOS 中也有互斥体,将信号量的值设置为 1 就可以使用信号量进行互斥访问了,虽然可以通过信号量实现互斥,但是 Linux 提供了一个比信号量更专业的机制来进行互斥,它就是互斥体—mutex。互斥访问表示一次只有一个线程可以访问共享资源,不能递归申请互斥体。在我们编写 Linux 驱动的时候遇到需要互斥访问的地方建议使用 mutex。
使用 mutex 结构体表示互斥体,定义如下(省略条件编译部分):
示例代码 47.5.1.1 mutex 结构体
struct mutex {
/* 1: unlocked, 0: locked, negative: locked, possible waiters */
atomic_t count;
spinlock_t wait_lock;
};
在使用 mutex 之前要先定义一个 mutex 变量。在使用 mutex 的时候要注意如下几点:
①、 mutex 可以导致休眠,因此不能在中断中使用 mutex,中断中只能使用自旋锁。
②、和信号量一样, mutex 保护的临界区可以调用引起阻塞的 API 函数。
③、因为一次只有一个线程可以持有 mutex,因此,必须由 mutex 的持有者释放 mutex。并且 mutex 不能递归上锁和解锁。
有关互斥体的 API 函数所示:
函数 描述
DEFINE_MUTEX(name) 定义并初始化一个 mutex 变量。
void mutex_init(mutex *lock) 初始化 mutex。
void mutex_lock(struct mutex *lock)获取 mutex,也就是给 mutex 上锁。如果获取不到就进休眠。
void mutex_unlock(struct mutex *lock) 释放 mutex,也就给 mutex 解锁。
int mutex_trylock(struct mutex *lock)尝试获取 mutex,如果成功就返回 1,如果失败就返回 0。
int mutex_is_locked(struct mutex *lock)判断 mutex 是否被获取,如果是的话就返回1,否则返回 0。
int mutex_lock_interruptible(struct mutex *lock)使用此函数获取信号量失败进入休眠以后可以被信号打断。
互斥体的使用如下所示:
示例代码 47.5.2.1 互斥体使用示例
1 struct mutex lock; /* 定义一个互斥体 */
2 mutex_init(&lock); /* 初始化互斥体 */
3 4
mutex_lock(&lock); /* 上锁 */
5 /* 临界区 */
6 mutex_unlock(&lock); /* 解锁 */
本文来自博客园,作者:Bathwind_W,转载请注明原文链接:https://www.cnblogs.com/bathwind/p/18247504