正点原子嵌入式linux驱动开发——Linux并发与竞争

Linux是一个多任务操作系统,肯定会存在多个任务共同操作同一段内存或者设备的情况,多个任务甚至中断都能访问的资源叫做共享资源。在驱动开发中要注意对共享资源的保护,也就是要处理对共享资源的并发访问。在Linux驱动编写过程中对于并发控制的管理非常重要,本章就来学习一下如何在Linux驱动中处理并发

并发与竞争

并发与竞争简介

并发就是多个“用户”同时访问同一个共享资源。Linux系统是个多任务操作系统,会存在多个任务同时访问同一片内存区域,这些任务可能会相互覆盖这段内存中的数据,造成内存数据混乱。针对这个问题必须要做处理,严重的话可能会导致系统崩溃。现在的Linux系统并发产生的原因很复杂,总结一下有下面几个主要原因:

  1. 多线程并发访问:Linux是多任务(线程)的系统,所以多线程访问是最基本的原因。
  2. 抢占式并发访问,从2.6版本内核开始,Linux内核支持抢占,也就是说调度程序可以在任意时刻抢占正在运行的线程,从而运行其他的线程。
  3. 中断程序并发访问。
  4. SMP(多核)核间并发访问,现在ARM架构的多核SOC很常见,多核CPU存在核间并发访问。

并发访问带来的问题就是竞争,临界区就是共享数据段,对于临界区必须保证一次只有一个线程访问,也就是要保证临界区是原子访问的,原子访问就表示这一个访问是一个步骤,不能再进行拆分。如果多个线程同时操作临界区就表示存在竞争,在编写驱动的时候一定要注意避免并发和防止竞争访问。一般在编写驱动的时候就要考虑到并发与竞争,而不是驱动都编写完了然后再处理并发与竞争。

保护内容

前面一直说要防止并发访问共享资源,换句话说就是要保护共享资源,防止进行并发访问。那么问题来了,什么是共享资源?也就是保护的内容是什么?保护的不是代码,而是数据!某个线程的局部变量不需要保护,要保护的是多个线程都会访问的共享数据。找到要保护的数据才是重点,而这个也是难点,因为驱动程序各不相同,那么数据也千变万化,一般像全局变量,设备结构体这些肯定是要保护的,至于其他的数据就要根据实际的驱动程序而定了

当发现驱动程序中存在并发和竞争的时候一定要处理掉,接下来依次来学习一下Linux内核提供的几种并发和竞争的处理方法。

原子操作

原子操作就是指不能再进一步分割的操作,一般原子操作用于变量或者位操作。假如现在要对无符号整形变量a赋值,值为3,用C语言实现很简单,但是C语言要先编译为成汇编指令,ARM架构不支持直接对寄存器(内存)进行读写操作,要借助寄存器R0、R1等来完成赋值操作。假设变量a的地址为0X3000000,“a=3”这一行C语言可能会被编译为如下所示的汇编代码:

示例代码27.2.1.1 汇编示例代码 
1 ldr r0, =0X30000000 /* 变量a地址 */ 
2 ldr r1, = 3 /* 要写入的值 */ 
3 str r1, [r0] /* 将3写入到a变量中 */

示例代码27.2.1.1只是一个简单的举例说明,实际的结果要比示例代码复杂的多。从上述代码可以看出, C语言里面简简单单的一句“a=3”,编译成汇编文件以后变成了3句,那么程序在执行的时候肯定是按照示例代码27.2.1.1中的汇编语句一条一条的执行。假设现在线程A要向a变量写入10这个值,而线程 B也要向a变量写入20这个值,理想中的执行顺序如下图所示:
理想执行情况
按照上图流程,确实可以实现线程A将a变量设置为10,线程B将a变量设置为20。但是实际上的执行流程可能如下图所示:
可能的执行流程
按照上图所示的流程,线程A最终将变量a设置为了20,而并不是要求的10!线程B没有问题。这就是一个最简单的设置变量值的并发与竞争的例子,要解决这个问题就要保证示例代码27.2.1.1中的三行汇编指令作为一个整体运行,也就是作为一个原子存在。Linux内核提供了一组原子操作API函数来完成此功能,Linux内核提供了两组原子操作API函数,一组是对整形变量进行操作的,一组是对位进行操作的

原子整形操作API函数

Linux内核定义了叫做atomic_t的结构体来完成整形数据的原子操作,在使用中用原子变量来代替整形变量,此结构体定义在include/linux/types.h文件中,定义如下:

示例代码27.2.2.1 atomic_t 结构体
171 typedef struct {
172     int counter;
173 } atomic_t;

如果要使用原子操作API函数,首先要先定义一个atomic_t的变量,如下所示:

atomic_t a; //定义a

也可以在定义原子变量的时候给原子变量赋初值,如下所示:

atomic_t b = ATOMIC_INIT(0); //定义原子变量b并赋初值为0

可以通过宏ATOMIC_INIT向原子变量赋初值。

原子变量有了,接下来就是对原子变量进行操作,比如读、写、增加、减少等等,Linux内核提供了大量的原子操作API函数,如下图所示:
原子整形操作API函数表
Cortex-A7是32位的架构,所以就只需要用上图所示的32位原子操作函数即可。原子变量和相应API的使用可以参考下例:

示例代码27.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函数如下图所示:
原子位操作函数表

自旋锁

自旋锁简介

原子操作只能对整形变量或者位进行保护,但是,在实际的使用环境中不可能只有整形变量或位这么简单的临界区。举个最简单的例子,设备结构体变量就不是整型变量,对于结构体中成员变量的操作也要保证原子性,在线程A对结构体变量使用期间,应该禁止其他的线程来访问此结构体变量,这些工作原子操作都不能胜任,需要本节要讲的锁机制,在Linux内核中就是自旋锁

当一个线程要访问某个共享资源的时候首先要先获取相应的锁,锁只能被一个线程持有,只要此线程不释放持有的锁,那么其他的线程就不能获取此锁。对于自旋锁而言,如果自旋锁正在被线程A持有,线程B想要获取自旋锁,那么线程B就会处于忙循环-旋转-等待状态,线程B不会进入休眠状态或者说去做其他的处理,而是会一直等待锁可用

自旋锁的“自旋”也就是“原地打转”的意思,“原地打转”的目的是为了等待自旋锁可以用,可以访问共享资源。把自旋锁比作一个变量a,变量a=1的时候表示共享资源可用,当a=0的时候表示共享资源不可用。现在线程A要访问共享资源,发现a=0(自旋锁被其他线程持有)那么线程A就会不断的查询a的值,直到a=1。从这里可以看到自旋锁的一个缺点:等待自旋锁的线程会一直处于自旋状态,这样会浪费处理器时间,降低系统性能,所以自旋锁的持有时间不能太长。自旋锁适用于短时期的轻量级加锁,如果遇到需要长时间持有锁的场景那就需要换其他的方法了。

Linux内核使用了结构体spinlock_t表示自旋锁,结构体定义如下;

示例代码27.3.1.1 spinlock_t结构体 
61 typedef struct spinlock { 
62     union { 
63         struct raw_spinlock rlock; 
64 
65 #ifdef CONFIG_DEBUG_LOCK_ALLOC 
66 # define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map)) 
67         struct { 
68             u8 __padding[LOCK_PADSIZE];
69             struct lockdep_map dep_map; 
70         }; 
71 #endif 
72     }; 
73 } spinlock_t;

在使用自旋锁之前,肯定要先定义一个自旋锁变量,定义方法如下所示:

spinlock_t lock; //定义自旋锁

定义好自旋锁变量以后就可以使用相应的API函数来操作自旋锁。

自旋锁API函数

最基本的自旋锁API函数如下图所示:
自旋锁基本API函数表
上图中的自旋锁API函数适用于SMP或支持抢占的单CPU下线程之间的并发访问,也就是用于线程与线程之间,被自旋锁保护的临界区一定不能调用任何能够引起睡眠和阻塞的API函数,否则的话会可能会导致死锁现象的发生。自旋锁会自动禁止抢占,也就说当线程A得到锁以后会暂时禁止内核抢占。如果线程A在持有锁期间进入了休眠状态,那么线程A会自动放弃CPU使用权。线程B开始运行,线程B也想要获取锁,但是此时锁被A线程持有,而且内核抢占还被禁止了!线程B无法被调度出去,那么线程A就无法运行,锁也就无法释放,死锁发生了!

上图中的API函数用于线程之间的并发访问,如果此时中断也要插一脚,中断也想访问共享资源,那该怎么办呢?首先可以肯定的是,中断里面可以使用自旋锁,但是在中断里面使用自旋锁的时候,在获取锁之前一定要先禁止本地中断(也就是本CPU中断,对于多核SOC来说会有多个CPU核),否则可能导致锁死现象的发生,下图所示:
中断打断线程
上图中,线程A先运行,并且获取到了lock这个锁,当线程A运行functionA函数的时候中断发生了,中断抢走了CPU使用权。右边的中断服务函数也要获取lock这个锁,但是这个锁被线程A占有着,中断就会一直自旋,等待锁有效。但是在中断服务函数执行完之前,线程A是不可能执行的,死锁发生!

最好的解决方法就是获取锁之前关闭本地中断,Linux内核提供了相应的API函数,如下图所示:
线程与中断并发访问处理API函数
使用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_unlock,示例代码如下所示:

示例代码27.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 }

下半部(BH)也会竞争共享资源,有些资料也会将下半部叫做底半部。关于下半部后面会讲解,如果要在下半部里面使用自旋锁,可以使用下图中的API函数:
下半部竞争处理函数

其他类型的锁

在自旋锁的基础上还衍生出了其他特定场合使用的锁,这些锁在驱动中其实用的不多,更多的是在Linux内核中使用,本节简单来了解一下这些衍生出来的锁。

读写自旋锁

某个数据结构,读和写不能同时进行,但是可以多人并发的读取。当某个数据结构符合读/写或生产者/消费者模型的时候就可以使用读写自旋锁。

读写自旋锁为读和写操作提供了不同的锁,一次只能允许一个写操作,也就是只能一个线程持有写锁,而且不能进行读操作。但是当没有写操作的时候允许一个或多个线程持有读锁,可以进行并发的读操作。Linux内核使用rwlock_t结构体表示读写锁,结构体定义如下(删除了条件编译):

示例代码27.3.3.1 rwlock_t结构体 
typedef struct { 
    arch_rwlock_t raw_lock; 
} rwlock_t;

读写锁操作API函数分为两部分,一个是给读使用的,一个是给写使用的,这些API函数如下图所示:
读写锁API函数

顺序锁

顺序锁在读写锁的基础上衍生而来的,使用读写锁的时候读操作和写操作不能同时进行。使用顺序锁的话可以允许在写的时候进行读操作,也就是实现同时读写,但是不允许同时进行并发的写操作。虽然顺序锁的读和写操作可以同时进行,但是如果在读的过程中发生了写操作,最好重新进行读取,保证数据完整性顺序锁保护的资源不能是指针,因为如果在写操作的时候可能会导致指针无效,而这个时候恰巧有读操作访问指针的话就可能导致意外发生,比如读取野指针导致系统崩溃。Linux内核使用seqlock_t结构体表示顺序锁,结构体定义如下:

示例代码27.3.3.2 seqlock_t结构体 
404 typedef struct { 
405     struct seqcount seqcount; 
406     spinlock_t lock; 
407 } seqlock_t;

关于顺序锁的API函数如下图所示;
顺序锁API函数表

自旋锁使用注意事项

综合前面关于自旋锁的信息,我们需要在使用自旋锁的时候要注意一下几点:

  1. 因为在等待自旋锁的时候处于“自旋”状态,因此锁的持有时间不能太长,一定要短,否则的话会降低系统性能。如果临界区比较大,运行时间比较长的话要选择其他的并发处理方式,比如稍后要讲的信号量和互斥体。
  2. 自旋锁保护的临界区内不能调用任何可能导致线程休眠的API函数,否则的话可能导致死锁。
  3. 不能递归申请自旋锁,因为一旦通过递归的方式申请一个正在持有的锁,那么就必须“自旋”,等待锁被释放,然而此时正处于“自旋”状态,根本没法释放锁。结果就是自己把自己锁死了!
  4. 在编写驱动程序的时候必须考虑到驱动的可移植性,因此不管用的是单核的还是多核的SOC,都将其当做多核SOC来编写驱动程序

信号量

信号量简介

Linux内核也提供了信号量机制,信号量常常用于控制对共享资源的访问

相比于自旋锁,信号量可以使线程进入休眠状态,可以看出,使用信号量会提高处理器的使用效率,毕竟不用一直在那里“自旋”等待。但是,信号量的开销要比自旋锁大,因为信号量使线程进入休眠状态以后会切换线程,切换线程就会有开销。总结一下信号量的特点:

  1. 因为信号量可以使等待资源线程进入休眠状态,因此适用于那些占用资源比较久的场合
  2. 因此信号量不能用于中断中,因为信号量会引起休眠,中断不能休眠。
  3. 如果共享资源的持有时间比较短,那就不适合使用信号量了,因为频繁的休眠、切换线程引起的开销要远大于信号量带来的那点优势。

信号量有一个信号量值,可以通过信号量来控制访问共享资源的访问数量,信号量控制访问资源的线程数,在初始化的时候将信号量值设置的大于1,那么这个信号量就是计数型信号量,计数型信号量不能用于互斥访问,因为它允许多个线程同时访问共享资源。如果要互斥的访问共享资源那么信号量的值就不能大于1,此时的信号量就是一个二值信号量。

信号量API函数

Linux内核使用semaphore结构体表示信号量,结构体内容如下所示:

示例代码27.4.2.1 semaphore结构体 
15 struct semaphore { 
16     raw_spinlock_t     lock; 
17     unsigned int       count; 
18     struct list_head   wait_list; 
19 };

要想使用信号量就得先定义,然后初始化信号量。有关信号量的API函数如下图所示:
信号量API函数
信号量的使用如下所示:

示例代码27.4.2.2 信号量使用示例 
struct semaphore sem; /* 定义信号量 */ 

sema_init(&sem, 1)/* 初始化信号量 */ 

down(&sem); /* 申请信号量 */ 
/* 临界区 */ 
up(&sem); /* 释放信号量 */

互斥体

互斥体简介

在FreeRTOS中也有互斥体,将信号量的值设置为1就可以使用信号量进行互斥访问了,虽然可以通过信号量实现互斥,但是Linux提供了一个比信号量更专业的机制来进行互斥,它就是互斥体mutex。互斥访问表示一次只有一个线程可以访问共享资源,不能递归申请互斥体。在编写Linux驱动的时候遇到需要互斥访问的地方建议使用mutex。Linux内核使用mutex结构体表示互斥体,定义如下(省略条件编译部分):

示例代码27.5.1.1 mutex结构体 
struct mutex { 
    atomic_long_t owner; 
    spinlock_t wait_lock; 
};

在使用mutex之前要先定义一个mutex变量。在使用mutex的时候要注意如下几点:

  1. mutex可以导致休眠,因此不能在中断中使用mutex,中断中只能使用自旋锁。
  2. 和信号量一样,mutex保护的临界区可以调用引起阻塞的API函数
  3. 因为一次只有一个线程可以持有mutex,因此,必须由mutex的持有者释放mutex。并且mutex不能递归上锁和解锁

互斥体API函数

有关互斥体的API函数如下图所示:
互斥体API函数
互斥体的使用如下所示:

示例代码27.5.2.1 互斥体使用示例 
1 struct mutex lock; /* 定义一个互斥体 */ 
2 mutex_init(&lock); /* 初始化互斥体 */ 
3 
4 mutex_lock(&lock); /* 上锁 */ 
5 /* 临界区 */ 
6 mutex_unlock(&lock); /* 解锁 */

Linux内核还有很多其他的处理并发和竞争的机制,主要讲解了常用的原子操作、自旋锁、信号量和互斥体。以后在编写Linux驱动的时候就会频繁的使用到这几种机制。

原子操作实验

这里就是在之前的gpioled.c的基础上进行修改,使用原子操作来实现对LED的互斥访问,即一次只能允许一个应用程序使用LED

实验程序编写

修改设备树文件

这里就是用的LED,之前已经添加过了,所以不需要修改。

LED驱动修改

在gpioled的设备结构体gpioled_dev中,添加了atomic_t结构体变量lock,用来表示原子变量,之后使用static定义一个具象化的gpioled_dev的gpioled,表征led设备。

之后再led_open中,通过atomic_dec_and_test(&gpioled.lock)来判断原子变量的值,进而判断LED是否被别的应用使用,如果返回值<0,证明设备被占用,那就通过atomic_inc(&gpioled.lock)来使得原子变量=0;如果返回值=0为真,说明设备未被占用,设置私有数据private_data。

之后的led_release中,关闭驱动文件的时候通过atomic_inc(&dev->lock)释放原子变量,即将lock+1。

在led_init的初始化中,gpioled.lock通过(atomic_t)ATOMIC_INIT(0)来初始化原子变量,并通过atomic_set设置原子变量初始值为1,这样每次只允许用1个应用使用LED。

编写测试代码

这里与之前的区别,就是在写入数据write之后,会通过while循环模拟占用LED灯25s,这其中每间隔5s会print一次循环次数。

运行测试

编译驱动程序

就是把Makefile的obj-m的值变为atomic.o,然后“make -j8”就可以了。

编译测试APP

可以通过如下命令编译atomicApp.c:

arm-none-linux-gnueabihf-gcc atomicApp.c -o atomicApp

运行测试

将编译得到的atomic.ko和atomicApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载atomic.ko驱动模块:

depmod //第一次加载驱动的时候需要运行此命令
modprobe atomic.ko //加载驱动

加载成功后,可以通过如下命令来运行atomicApp软件,来控制LED:

./atomicApp /dev/gpioled 1 & //打开LED灯

完成后,红色LED会被点亮,通过会输出如下图所示信息:
打开LED灯
此时,可以输入如下命令关闭LED:

./atomicApp /dev/gpioled 0 //关闭LED灯

输入上述命令后,可以看到如下信息:
关闭LED灯
从上图可以看出,打开/dev/gpioled失败!原因是在上图中运行的atomicAPP软件正在占用/dev/gpioled,如果再次运行atomicApp软件去操作/dev/gpioled肯定会失败。必须等待上图中的atomicApp运行结束,也就是25s结束以后其他软件才能去操作/dev/gpioled。这个就是采用原子变量实现一次只能有一个应用程序访问LED灯

如果要卸载驱动的话输入如下命令即可:

rmmod atomic.ko

自旋锁实验

上一节使用原子变量实现了一次只能有一个应用程序访问LED灯,本节使用自旋锁来实现此功能。在使用自旋锁之前,先回顾一下自旋锁的使用注意事项:

  1. 自旋锁保护的临界区要尽可能的短,因此在open函数中申请自旋锁,然后在release函数中释放自旋锁的方法就不可取。可以使用一个变量来表示设备的使用情况,如果设备被使用了那么变量就加1,设备被释放以后变量就减1,只需要使用自旋锁保护这个变量即可
  2. 考虑驱动的兼容性,合理的选择API函数。

综上所述,在本节例程中,通过定义一个变量dev_stats表示设备的使用情况,dev_stats为0的时候表示设备没有被使用,dev_stats大于0的时候表示设备被使用。驱动open函数中先判断dev_stats是否为0也就是判断设备是否可用,如果为0的话就使用设备,并且将dev_stats加 1,表示设备被使用了。使用完以后在release函数中将dev_stats减1,表示设备没有被使用了。因此真正实现设备互斥访问的是变量dev_stats,但是要使用自旋锁对dev_stats来做保护

实验程序编写

修改设备树文件

这里不需要修改。

LED驱动修改

将原来使用atomic的地方换为spinlock即可,其他代码不需要修改。

gpioled_dev中换成spinlock_t lock来表示自旋锁,同时通过int dev_stats表示使用状态。

在led_open中,定义一个unsigned long flags,通过spin_lock_irqsave上锁,然后通过gpioled.dev_stats来判断设备使用情况,如果=1说明被使用了,就通过spin_unlock_irqrestore解锁;否则就直接gpioled.dev_stats++表示被占用,同时使用spin_unlock_irqrestore解锁。

在led_release中,关闭驱动文件的时候调用spin_lock_irqsave上锁,此时如果设备被占用,就直接dev->dev_stats–,之后通过spin_unlock_irqrestore解锁。

之后,在初始化的led_init函数中,调用spin_lock_init初始化自旋锁。

编写测试APP

与上一小节的atomicApp.c一样就可以了。

运行测试

将Makefile的obj-m的值改为spinlock.o,然后“make -j8”编译就可以了。

编译测试APP

通过如下命令编译:

arm-none-linux-gnueabihf-gcc spinlockApp.c -o spinlockApp

运行测试

将上一小节编译出来的spinlock.ko和spinlockApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载spinlock.ko驱动模块:

depmod //第一次加载驱动的时候需要运行此命令
modprobe spinlock.ko //加载驱动

可以通过如下的命令开关LED,实验现象与上一小节是一样的:

./spinlockApp /dev/gpioled 1 & //打开LED灯
./spinlockApp /dev/gpioled 0 //关闭LED灯

卸载驱动可以通过如下命令:

rmmod spinlock.ko

信号量实验

使用信号量来实现一次只能有一个应用程序访问LED灯,信号量可以导致休眠,因此信号量保护的临界区没有运行时间限制,可以在驱动的open函数申请信号量,然后在release函数中释放信号量。但是信号量不能用在中断中,本节实验不会在中断中使用信号量。

实验程序编写

修改设备树文件

这里不需要修改。

LED驱动修改

将原来使用到自旋锁的地方换为信号量即可,其他的内容基本不变。

在gpioled_dev设备结构体中,最后换成struct semaphore sem添加一个信号量。

在led_open中,先设置私有数据,然后可以通过down_interruptible(&gpioled.sem)获取信号量,这里进入休眠是可以被信号打断的,这里如果>=1就可以使用LED;如果=0就不能使用,应用程序就会进入休眠态,等到信号量值>=1才会被唤醒,申请信号量来获取LED使用权。

在led_release中,通过up(&dev->sem)释放信号量,信号量count+1。

在led_init中,通过sema_init(&gpioled.sem, 1)初始化信号量,表明是一个二值信号量。

编写测试APP

这里直接将之前的拷贝过来就可以了。

运行测试

编译驱动程序

把Makefile的obj-m改成semaphore.o然后“make”就可以了。

编译测试APP

通过下面的命令编译即可:

arm-none-linux-gnueabihf-gcc semaApp.c -o semaApp

运行测试

将上一小节编译出来的semaphore.ko和semaApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载semaphore.ko驱动模块:

depmod //第一次加载驱动的时候需要运行此命令
modprobe semaphore.ko //加载驱动

测试方法也与之前一样:

./semaApp /dev/gpioled 1 & //打开LED灯
./semaApp /dev/gpioled 0 & //关闭LED灯

这两条命令连续输入,第一条命令先获取到信号量,因此可以操作LED灯,将LED灯打开,并且占有25S。第二条命令因为获取信号量失败而进入休眠状态,等待第一条命令运行完毕并释放信号量以后才拥有LED灯使用权,将LED灯关闭,运行结果如下图所示:
命令运行过程
卸载驱动可使用如下命令:

rmmod semaphore.ko

互斥体实验

这里LED只涉及开关状态,所以最适合的其实是互斥体mutex。

实验程序编写

修改设备树文件

这里不需要修改。

LED驱动修改

将原来使用到信号量的地方换为mutex即可,其他的内容基本不变。

在gpioled_dev设备结构体中,最后换成struct mutex lock来表示互斥体。

led_open中,通过mutex_lock_interruptible(&gpioled.lock)获取互斥体mtex,如果成功那么就可以使用LED灯,摔了就进入休眠。

led_release中,通过mutex_unlock释放互斥锁。

led_init中,通过mutex_init初始化互斥锁。

编写测试APP

这里直接把之前的拷贝过来就可以了。

运行测试

编写驱动程序

将Makefile的obj-m换成mutex.o,然后直接“make”就可以了。

编译测试APP

可以通过如下命令来编译:

arm-none-linux-gnueabihf-gcc mutexApp.c -o mutexApp
### 运行测试 将上一小节编译出来的mutex.ko和mutexApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载mutex.ko驱动模块:
depmod //第一次加载驱动的时候需要运行此命令
modprobe mutex.ko //加载驱动

测试就跟之前是一样的,这里不赘述了。

如果要卸载驱动,可以通过如下命令:

rmmod mutex.ko

总结

这一篇笔记,内容其实跟之前学FreeRTOS很类似,除了没有自旋锁和原子操作,后面的信号量就是一样的,互斥体就是二值信号量。主要的代码驱动编写,也是掌握住几个API就可以了。

主要关注自旋锁和信号量。

自旋锁的上锁和解锁是在led_open之中就可以完成的,通过spin_lock_irqsave上锁,通过自行设定dev_stats来表示使用状态,=0就可以使用,由spin_unlock_irqrestore解锁;在led_release总,还是由dev_stats判断使用情况,一样要先spin_lock_irqsave上锁之后判断使用情况,有使用就dev_stats–然后spin_unlock_irqrestore解锁;同时在led_init之中要通过spin_lock_init初始化自旋锁。

信号量和互斥体就很类似,都是在gpioled_dev定义一个结构体来使用信号量/互斥体;然后在led_open中获取信号量,在led_release释放信号量,在led_init中初始化信号量。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值