Linux C++多线程同步的四种方式

Linux C++多线程同步的四种方式,第1张

From : https://blog.csdn.net/qq_39382769/article/details/960753461.同一个线程内部,指令按照先后顺序执行;但不同线程之间的指令很难说清楚是哪一个先执行,在并发情况下,指令执行的先后顺序由内核决定。 如果运行的结果依赖于不同线程执行的先后的话,那么就会形成竞争条件,在这样的情况下,计算的结果很难预知,所以应该尽量避免竞争条件的形成。 2.最常见的解决竞争条件的方法是:将原先分离的两个指令构成一个不可分割的原子 *** 作,而其他任务不能插入到原子 *** 作中! 3.对多线程来说,同步指的是在一定时间内只允许某一个线程访问某个资源,而在此时间内,不允许其他线程访问该资源! 互斥锁 条件变量 读写锁 信号量 一种特殊的全局变量,拥有lock和unlock两种状态。 unlock的互斥锁可以由某个线程获得,一旦获得,这个互斥锁会锁上变成lock状态,此后只有该线程由权力打开该锁,其他线程想要获得互斥锁,必须得到互斥锁再次被打开之后。 1.互斥锁的初始化, 分为静态初始化和动态初始化. 2.互斥锁的相关属性及分类 (1) attr表示互斥锁的属性 (2) pshared表示互斥锁的共享属性,由两种取值: 1)PTHREAD_PROCESS_PRIVATE:锁只能用于一个进程内部的两个线程进行互斥(默认情况) 2)PTHREAD_PROCESS_SHARED:锁可用于两个不同进程中的线程进行互斥,使用时还需要在进程共享内存中分配互斥锁,然后为该互斥锁指定属性就可以了。 互斥锁存在缺点: (1)某个线程正在等待共享数据内某个条件出现。 (2)重复对数据对象加锁和解锁(轮询),但是这样轮询非常耗费时间和资源,而且效率非常低,所以互斥锁不太适合这种情况。 当线程在等待满足某些条件时,使线程进入睡眠状态;一旦条件满足,就换线因等待满足特定条件而睡眠的线程。 程序的效率无疑会大大提高。 1)创建 静态方式:pthread_cond_t cond PTHREAD_COND_INITIALIZER 动态方式:int pthread_cond_init(&cond,NULL) Linux thread 实现的条件变量不支持属性,所以NULL(cond_attr参数) 2)注销 int pthread_cond_destory(&cond) 只有没有线程在该条件变量上,该条件变量才能注销,否则返回EBUSY 因为Linux实现的条件变量没有分配什么资源,所以注销动作只包括检查是否有等待线程!(请参考条件变量的底层实现) 3)等待 条件等待:int pthread_cond_wait(&cond,&mutex) 计时等待:int pthread_cond_timewait(&cond,&mutex,time) 1.其中计时等待如果在给定时刻前条件没有被满足,则返回ETIMEOUT,结束等待 2.无论那种等待方式,都必须有一个互斥锁配合,以防止多个线程同时请求pthread_cond_wait形成竞争条件! 3.在调用pthread_cond_wait前必须由本线程加锁 4)激发 激发一个等待线程:pthread_cond_signal(&cond) 激发所有等待线程:pthread_cond_broadcast(&cond) 重要的是,pthread_cond_signal不会存在惊群效应,也就是是它最多给一个等待线程发信号,不会给所有线程发信号唤醒,然后要求他们自己去争抢资源! pthread_cond_broadcast() 唤醒所有正在pthread_cond_wait()的同一个条件变量的线程。注意:如果等待的多个现场不使用同一个锁,被唤醒的多个线程执行是并发的。pthread_cond_broadcast &pthread_cond_signal1.读写锁比互斥锁更加具有适用性和并行性 2.读写锁最适用于对数据结构的读 *** 作读 *** 作次数多余写 *** 作次数的场合! 3.锁处于读模式时可以线程共享,而锁处于写模式时只能独占,所以读写锁又叫做共享-独占锁。 4.读写锁有两种策略:强读同步和强写同步 强读同步: 总是给读者更高的优先权,只要写者没有进行写 *** 作,读者就可以获得访问权限 强写同步: 总是给写者更高的优先权,读者只能等到所有正在等待或者执行的写者完成后才能进行读 1)初始化的销毁读写锁 静态初始化:pthread_rwlock_t rwlock=PTHREAD_RWLOCK_INITIALIZER 动态初始化:int pthread_rwlock_init(rwlock,NULL),NULL代表读写锁采用默认属性 销毁读写锁:int pthread_rwlock_destory(rwlock) 在释放某个读写锁的资源之前,需要先通过pthread_rwlock_destory函数对读写锁进行清理。释放由pthread_rwlock_init函数分配的资源 如果你想要读写锁使用非默认属性,则attr不能为NULL,得给attr赋值 int pthread_rwlockattr_init(attr),给attr初始化 int pthread_rwlockattr_destory(attr),销毁attr 2)以写的方式获取锁,以读的方式获取锁,释放读写锁 int pthread_rwlock_rdlock(rwlock),以读的方式获取锁 int pthread_rwlock_wrlock(rwlock),以写的方式获取锁 int pthread_rwlock_unlock(rwlock),释放锁 上面两个获取锁的方式都是阻塞的函数,也就是说获取不到锁的话,调用线程不是立即返回,而是阻塞执行,在需要进行写 *** 作的时候,这种阻塞式获取锁的方式是非常不好的,你想一下,我需要进行写 *** 作,不但没有获取到锁,我还一直在这里等待,大大拖累效率 所以我们应该采用非阻塞的方式获取锁: int pthread_rwlock_tryrdlock(rwlock) int pthread_rwlock_trywrlock(rwlock) 互斥锁只允许一个线程进入临界区,而信号量允许多个线程进入临界区。 1)信号量初始化 int sem_init(&sem,pshared, v) pshared为0,表示这个信号量是当前进程的局部信号量。 pshared为1,表示这个信号量可以在多个进程之间共享。 v为信号量的初始值。 返回值: 成功:0,失败:-1 2)信号量值的加减 int sem_wait(&sem):以原子 *** 作的方式将信号量的值减去1 int sem_post(&sem):以原子 *** 作的方式将信号量的值加上1 3)对信号量进行清理 int sem_destory(&sem)

Linux设备驱动中必须解决的一个问题是多个进程对共享资源的并发访问,并发访问会导致竞态,linux提供了多种解决竞态问题的方式,这些方式适合不同的应用场景。

Linux内核是多进程、多线程的 *** 作系统,它提供了相当完整的内核同步方法。内核同步方法列表如下:

中断屏蔽

原子 *** 作

自旋

读写自旋

顺序锁

信号量

读写信号量

BKL(大内核锁)

Seq锁

一、并发与竞态:

定义:

并发(concurrency)指的是多个执行单元同时、并行被执行,而并发的执行单元对共享资源(硬件资源和软件上的全局变量、静态变量等)的访问则很容易导致竞态(race conditions)。

在linux中,主要的竞态发生在如下几种情况:

1、对称多处理器(SMP)多个CPU

特点是多个CPU使用共同的系统总线,因此可访问共同的外设和存储器。

2、单CPU内进程与抢占它的进程

3、中断(硬中断、软中断、Tasklet、底半部)与进程之间

只要并发的多个执行单元存在对共享资源的访问,竞态就有可能发生。

如果中断处理程序访问进程正在访问的资源,则竞态也会会发生。

多个中断之间本身也可能引起并发而导致竞态(中断被更高优先级的中断打断)。

解决竞态问题的途径是保证对共享资源的互斥访问,所谓互斥访问就是指一个执行单元在访问共享资源的时候,其他的执行单元都被禁止访问。

访问共享资源的代码区域被称为临界区,临界区需要以某种互斥机制加以保护,中断屏蔽,原子 *** 作,自旋锁,和信号量都是linux设备驱动中可采用的互斥途径。

临界区和竞争条件:

所谓临界区(critical regions)就是访问和 *** 作共享数据的代码段,为了避免在临界区中并发访问,编程者必须保证这些代码原子地执行——也就是说,代码在执行结束前不可被打断,就如同整个临界区是一个不可分割的指令一样,如果两个执行线程有可能处于同一个临界区中,那么就是程序包含一个bug,如果这种情况发生了,我们就称之为竞争条件(race conditions),避免并发和防止竞争条件被称为同步。

死锁:

死锁的产生需要一定条件:要有一个或多个执行线程和一个或多个资源,每个线程都在等待其中的一个资源,但所有的资源都已经被占用了,所有线程都在相互等待,但它们永远不会释放已经占有的资源,于是任何线程都无法继续,这便意味着死锁的发生。

二、中断屏蔽

在单CPU范围内避免竞态的一种简单方法是在进入临界区之前屏蔽系统的中断。

由于linux内核的进程调度等 *** 作都依赖中断来实现,内核抢占进程之间的并发也就得以避免了。

中断屏蔽的使用方法:

local_irq_disable()//屏蔽中断

//临界区

local_irq_enable()//开中断

特点:

由于linux系统的异步IO,进程调度等很多重要 *** 作都依赖于中断,在屏蔽中断期间所有的中断都无法得到处理,因此长时间的屏蔽是很危险的,有可能造成数据丢失甚至系统崩溃,这就要求在屏蔽中断之后,当前的内核执行路径应当尽快地执行完临界区的代码。

中断屏蔽只能禁止本CPU内的中断,因此,并不能解决多CPU引发的竞态,所以单独使用中断屏蔽并不是一个值得推荐的避免竞态的方法,它一般和自旋锁配合使用。

三、原子 *** 作

定义:原子 *** 作指的是在执行过程中不会被别的代码路径所中断的 *** 作。

(原子原本指的是不可分割的微粒,所以原子 *** 作也就是不能够被分割的指令)

(它保证指令以“原子”的方式执行而不能被打断)

原子 *** 作是不可分割的,在执行完毕不会被任何其它任务或事件中断。在单处理器系统(UniProcessor)中,能够在单条指令中完成的 *** 作都可以认为是" 原子 *** 作",因为中断只能发生于指令之间。这也是某些CPU指令系统中引入了test_and_set、test_and_clear等指令用于临界资源互斥的原因。但是,在对称多处理器(Symmetric Multi-Processor)结构中就不同了,由于系统中有多个处理器在独立地运行,即使能在单条指令中完成的 *** 作也有可能受到干扰。我们以decl (递减指令)为例,这是一个典型的"读-改-写"过程,涉及两次内存访问。

通俗理解:

原子 *** 作,顾名思义,就是说像原子一样不可再细分。一个 *** 作是原子 *** 作,意思就是说这个 *** 作是以原子的方式被执行,要一口气执行完,执行过程不能够被OS的其他行为打断,是一个整体的过程,在其执行过程中,OS的其它行为是插不进来的。

分类:linux内核提供了一系列函数来实现内核中的原子 *** 作,分为整型原子 *** 作和位原子 *** 作,共同点是:在任何情况下 *** 作都是原子的,内核代码可以安全的调用它们而不被打断。

原子整数 *** 作:

针对整数的原子 *** 作只能对atomic_t类型的数据进行处理,在这里之所以引入了一个特殊的数据类型,而没有直接使用C语言的int型,主要是出于两个原因:

第一、让原子函数只接受atomic_t类型的 *** 作数,可以确保原子 *** 作只与这种特殊类型数据一起使用,同时,这也确保了该类型的数据不会被传递给其它任何非原子函数;

第二、使用atomic_t类型确保编译器不对相应的值进行访问优化——这点使得原子 *** 作最终接收到正确的内存地址,而不是一个别名,最后就是在不同体系结构上实现原子 *** 作的时候,使用atomic_t可以屏蔽其间的差异。

原子整数 *** 作最常见的用途就是实现计数器。

另一点需要说明原子 *** 作只能保证 *** 作是原子的,要么完成,要么不完成,不会有 *** 作一半的可能,但原子 *** 作并不能保证 *** 作的顺序性,即它不能保证两个 *** 作是按某个顺序完成的。如果要保证原子 *** 作的顺序性,请使用内存屏障指令。

atomic_t和ATOMIC_INIT(i)定义

typedef struct { volatile int counter} atomic_t

#define ATOMIC_INIT(i) { (i) }

在你编写代码的时候,能使用原子 *** 作的时候,就尽量不要使用复杂的加锁机制,对多数体系结构来讲,原子 *** 作与更复杂的同步方法相比较,给系统带来的开销小,对高速缓存行的影响也小,但是,对于那些有高性能要求的代码,对多种同步方法进行测试比较,不失为一种明智的作法。

原子位 *** 作:

针对位这一级数据进行 *** 作的函数,是对普通的内存地址进行 *** 作的。它的参数是一个指针和一个位号。

为方便其间,内核还提供了一组与上述 *** 作对应的非原子位函数,非原子位函数与原子位函数的 *** 作完全相同,但是,前者不保证原子性,且其名字前缀多两个下划线。例如,与test_bit()对应的非原子形式是_test_bit(),如果你不需要原子性 *** 作(比如,如果你已经用锁保护了自己的数据),那么这些非原子的位函数相比原子的位函数可能会执行得更快些。

四、自旋锁

自旋锁的引入:

如 果每个临界区都能像增加变量这样简单就好了,可惜现实不是这样,而是临界区可以跨越多个函数,例如:先得从一个数据结果中移出数据,对其进行格式转换和解 析,最后再把它加入到另一个数据结构中,整个执行过程必须是原子的,在数据被更新完毕之前,不能有其他代码读取这些数据,显然,简单的原子 *** 作是无能为力 的(在单处理器系统(UniProcessor)中,能够在单条指令中完成的 *** 作都可以认为是" 原子 *** 作",因为中断只能发生于指令之间),这就需要使用更为复杂的同步方法——锁来提供保护。

自旋锁的介绍:

Linux内核中最常见的锁是自旋锁(spin lock),自旋锁最多只能被一个可执行线程持有,如果一个执行线程试图获得一个被争用(已经被持有)的自旋锁,那么该线程就会一直进行忙循环—旋转—等待锁重新可用,要是锁未被争用,请求锁的执行线程便能立刻得到它,继续执行,在任意时间,自旋锁都可以防止多于一个的执行线程同时进入理解区,注意同一个锁可以用在多个位置—例如,对于给定数据的所有访问都可以得到保护和同步。

一个被争用的自旋锁使得请求它的线程在等待锁重新可用时自旋(特别浪费处理器时间),所以自旋锁不应该被长时间持有,事实上,这点正是使用自旋锁的初衷,在短期间内进行轻量级加锁,还可以采取另外的方式来处理对锁的争用:让请求线程睡眠,直到锁重新可用时再唤醒它,这样处理器就不必循环等待,可以去执行其他代码,这也会带来一定的开销——这里有两次明显的上下文切换, 被阻塞的线程要换出和换入。因此,持有自旋锁的时间最好小于完成两次上下文切换的耗时,当然我们大多数人不会无聊到去测量上下文切换的耗时,所以我们让持 有自旋锁的时间应尽可能的短就可以了,信号量可以提供上述第二种机制,它使得在发生争用时,等待的线程能投入睡眠,而不是旋转。

自旋锁可以使用在中断处理程序中(此处不能使用信号量,因为它们会导致睡眠),在中断处理程序中使用自旋锁时,一定要在获取锁之前,首先禁止本地中断(在 当前处理器上的中断请求),否则,中断处理程序就会打断正持有锁的内核代码,有可能会试图去争用这个已经持有的自旋锁,这样以来,中断处理程序就会自旋, 等待该锁重新可用,但是锁的持有者在这个中断处理程序执行完毕前不可能运行,这正是我们在前一章节中提到的双重请求死锁,注意,需要关闭的只是当前处理器上的中断,如果中断发生在不同的处理器上,即使中断处理程序在同一锁上自旋,也不会妨碍锁的持有者(在不同处理器上)最终释放锁。

自旋锁的简单理解:

理解自旋锁最简单的方法是把它作为一个变量看待,该变量把一个临界区或者标记为“我当前正在运行,请稍等一会”或者标记为“我当前不在运行,可以被使用”。如果A执行单元首先进入例程,它将持有自旋锁,当B执行单元试图进入同一个例程时,将获知自旋锁已被持有,需等到A执行单元释放后才能进入。

自旋锁的API函数:

其实介绍的几种信号量和互斥机制,其底层源码都是使用自旋锁,可以理解为自旋锁的再包装。所以从这里就可以理解为什么自旋锁通常可以提供比信号量更高的性能。

自旋锁是一个互斥设备,他只能会两个值:“锁定”和“解锁”。它通常实现为某个整数之中的单个位。

“测试并设置”的 *** 作必须以原子方式完成。

任何时候,只要内核代码拥有自旋锁,在相关CPU上的抢占就会被禁止。

适用于自旋锁的核心规则:

(1)任何拥有自旋锁的代码都必须使原子的,除服务中断外(某些情况下也不能放弃CPU,如中断服务也要获得自旋锁。为了避免这种锁陷阱,需要在拥有自旋锁时禁止中断),不能放弃CPU(如休眠,休眠可发生在许多无法预期的地方)。否则CPU将有可能永远自旋下去(死机)。

(2)拥有自旋锁的时间越短越好。

需 要强调的是,自旋锁别设计用于多处理器的同步机制,对于单处理器(对于单处理器并且不可抢占的内核来说,自旋锁什么也不作),内核在编译时不会引入自旋锁 机制,对于可抢占的内核,它仅仅被用于设置内核的抢占机制是否开启的一个开关,也就是说加锁和解锁实际变成了禁止或开启内核抢占功能。如果内核不支持抢 占,那么自旋锁根本就不会编译到内核中。

内核中使用spinlock_t类型来表示自旋锁,它定义在:

typedef struct {

raw_spinlock_t raw_lock

#if defined(CONFIG_PREEMPT) &&defined(CONFIG_SMP)

unsigned int break_lock

#endif

} spinlock_t

对于不支持SMP的内核来说,struct raw_spinlock_t什么也没有,是一个空结构。对于支持多处理器的内核来说,struct raw_spinlock_t定义为

typedef struct {

unsigned int slock

} raw_spinlock_t

slock表示了自旋锁的状态,“1”表示自旋锁处于解锁状态(UNLOCK),“0”表示自旋锁处于上锁状态(LOCKED)。

break_lock表示当前是否由进程在等待自旋锁,显然,它只有在支持抢占的SMP内核上才起作用。

自旋锁的实现是一个复杂的过程,说它复杂不是因为需要多少代码或逻辑来实现它,其实它的实现代码很少。自旋锁的实现跟体系结构关系密切,核心代码基本也是由汇编语言写成,与体协结构相关的核心代码都放在相关的目录下,比如。对于我们驱动程序开发人员来说,我们没有必要了解这么spinlock的内部细节,如果你对它感兴趣,请参考阅读Linux内核源代码。对于我们驱动的spinlock接口,我们只需包括头文件。在我们详细的介绍spinlock的API之前,我们先来看看自旋锁的一个基本使用格式:

#include

spinlock_t lock = SPIN_LOCK_UNLOCKED

spin_lock(&lock)

....

spin_unlock(&lock)

从使用上来说,spinlock的API还很简单的,一般我们会用的的API如下表,其实它们都是定义在中的宏接口,真正的实现在中

#include

SPIN_LOCK_UNLOCKED

DEFINE_SPINLOCK

spin_lock_init( spinlock_t *)

spin_lock(spinlock_t *)

spin_unlock(spinlock_t *)

spin_lock_irq(spinlock_t *)

spin_unlock_irq(spinlock_t *)

spin_lock_irqsace(spinlock_t *,unsigned long flags)

spin_unlock_irqsace(spinlock_t *, unsigned long flags)

spin_trylock(spinlock_t *)

spin_is_locked(spinlock_t *)

• 初始化

spinlock有两种初始化形式,一种是静态初始化,一种是动态初始化。对于静态的spinlock对象,我们用 SPIN_LOCK_UNLOCKED来初始化,它是一个宏。当然,我们也可以把声明spinlock和初始化它放在一起做,这就是 DEFINE_SPINLOCK宏的工作,因此,下面的两行代码是等价的。

DEFINE_SPINLOCK (lock)

spinlock_t lock = SPIN_LOCK_UNLOCKED

spin_lock_init 函数一般用来初始化动态创建的spinlock_t对象,它的参数是一个指向spinlock_t对象的指针。当然,它也可以初始化一个静态的没有初始化的spinlock_t对象。

spinlock_t *lock

......

spin_lock_init(lock)

• 获取锁

内核提供了三个函数用于获取一个自旋锁。

spin_lock:获取指定的自旋锁。

spin_lock_irq:禁止本地中断并获取自旋锁。

spin_lock_irqsace:保存本地中断状态,禁止本地中断并获取自旋锁,返回本地中断状态。

自旋锁是可以使用在中断处理程序中的,这时需要使用具有关闭本地中断功能的函数,我们推荐使用 spin_lock_irqsave,因为它会保存加锁前的中断标志,这样就会正确恢复解锁时的中断标志。如果spin_lock_irq在加锁时中断是关闭的,那么在解锁时就会错误的开启中断。

另外两个同自旋锁获取相关的函数是:

spin_trylock():尝试获取自旋锁,如果获取失败则立即返回非0值,否则返回0。

spin_is_locked():判断指定的自旋锁是否已经被获取了。如果是则返回非0,否则,返回0。

• 释放锁

同获取锁相对应,内核提供了三个相对的函数来释放自旋锁。

spin_unlock:释放指定的自旋锁。

spin_unlock_irq:释放自旋锁并激活本地中断。

spin_unlock_irqsave:释放自旋锁,并恢复保存的本地中断状态。

五、读写自旋锁

如 果临界区保护的数据是可读可写的,那么只要没有写 *** 作,对于读是可以支持并发 *** 作的。对于这种只要求写 *** 作是互斥的需求,如果还是使用自旋锁显然是无法满 足这个要求(对于读 *** 作实在是太浪费了)。为此内核提供了另一种锁-读写自旋锁,读自旋锁也叫共享自旋锁,写自旋锁也叫排他自旋锁。

读写自旋锁是一种比自旋锁粒度更小的锁机制,它保留了“自旋”的概念,但是在写 *** 作方面,只能最多有一个写进程,在读 *** 作方面,同时可以有多个读执行单元,当然,读和写也不能同时进行。

读写自旋锁的使用也普通自旋锁的使用很类似,首先要初始化读写自旋锁对象:

// 静态初始化

rwlock_t rwlock = RW_LOCK_UNLOCKED

//动态初始化

rwlock_t *rwlock

...

rw_lock_init(rwlock)

在读 *** 作代码里对共享数据获取读自旋锁:

read_lock(&rwlock)

...

read_unlock(&rwlock)

在写 *** 作代码里为共享数据获取写自旋锁:

write_lock(&rwlock)

...

write_unlock(&rwlock)

需要注意的是,如果有大量的写 *** 作,会使写 *** 作自旋在写自旋锁上而处于写饥饿状态(等待读自旋锁的全部释放),因为读自旋锁会自由的获取读自旋锁。

读写自旋锁的函数类似于普通自旋锁,这里就不一一介绍了,我们把它列在下面的表中。

RW_LOCK_UNLOCKED

rw_lock_init(rwlock_t *)

read_lock(rwlock_t *)

read_unlock(rwlock_t *)

read_lock_irq(rwlock_t *)

read_unlock_irq(rwlock_t *)

read_lock_irqsave(rwlock_t *, unsigned long)

read_unlock_irqsave(rwlock_t *, unsigned long)

write_lock(rwlock_t *)

write_unlock(rwlock_t *)

write_lock_irq(rwlock_t *)

write_unlock_irq(rwlock_t *)

write_lock_irqsave(rwlock_t *, unsigned long)

write_unlock_irqsave(rwlock_t *, unsigned long)

rw_is_locked(rwlock_t *)

六、顺序琐

顺序琐(seqlock)是对读写锁的一种优化,若使用顺序琐,读执行单元绝不会被写执行单元阻塞,也就是说,读执行单元可以在写执行单元对被顺序琐保护的共享资源进行写 *** 作时仍然可以继续读,而不必等待写执行单元完成写 *** 作,写执行单元也不需要等待所有读执行单元完成读 *** 作才去进行写 *** 作。

但是,写执行单元与写执行单元之间仍然是互斥的,即如果有写执行单元在进行写 *** 作,其它写执行单元必须自旋在哪里,直到写执行单元释放了顺序琐。

如果读执行单元在读 *** 作期间,写执行单元已经发生了写 *** 作,那么,读执行单元必须重新读取数据,以便确保得到的数据是完整的,这种锁在读写同时进行的概率比较小时,性能是非常好的,而且它允许读写同时进行,因而更大的提高了并发性,

注意,顺序琐由一个限制,就是它必须被保护的共享资源不含有指针,因为写执行单元可能使得指针失效,但读执行单元如果正要访问该指针,将导致Oops。

七、信号量

Linux中的信号量是一种睡眠锁,如果有一个任务试图获得一个已经被占用的信号量时,信号量会将其推进一个等待队列,然后让其睡眠,这时处理器能重获自由,从而去执行其它代码,当持有信号量的进程将信号量释放后,处于等待队列中的哪个任务被唤醒,并获得该信号量。

信号量,或旗标,就是我们在 *** 作系统里学习的经典的P/V原语 *** 作。

P:如果信号量值大于0,则递减信号量的值,程序继续执行,否则,睡眠等待信号量大于0。

V:递增信号量的值,如果递增的信号量的值大于0,则唤醒等待的进程。

信号量的值确定了同时可以有多少个进程可以同时进入临界区,如果信号量的初始值始1,这信号量就是互斥信号量(MUTEX)。对于大于1的非0值信号量,也可称为计数信号量(counting semaphore)。对于一般的驱动程序使用的信号量都是互斥信号量。

类似于自旋锁,信号量的实现也与体系结构密切相关,具体的实现定义在头文件中,对于x86_32系统来说,它的定义如下:

struct semaphore {

atomic_t count

int sleepers

wait_queue_head_t wait

}

信号量的初始值count是atomic_t类型的,这是一个原子 *** 作类型,它也是一个内核同步技术,可见信号量是基于原子 *** 作的。我们会在后面原子 *** 作部分对原子 *** 作做详细介绍。

信号量的使用类似于自旋锁,包括创建、获取和释放。我们还是来先展示信号量的基本使用形式:

static DECLARE_MUTEX(my_sem)

......

if (down_interruptible(&my_sem))

{

return -ERESTARTSYS

}

......

up(&my_sem)

Linux内核中的信号量函数接口如下:

static DECLARE_SEMAPHORE_GENERIC(name, count)

static DECLARE_MUTEX(name)

seam_init(struct semaphore *, int)

init_MUTEX(struct semaphore *)

init_MUTEX_LOCKED(struct semaphore *)

down_interruptible(struct semaphore *)

down(struct semaphore *)

down_trylock(struct semaphore *)

up(struct semaphore *)

• 初始化信号量

信号量的初始化包括静态初始化和动态初始化。静态初始化用于静态的声明并初始化信号量。

static DECLARE_SEMAPHORE_GENERIC(name, count)

static DECLARE_MUTEX(name)

对于动态声明或创建的信号量,可以使用如下函数进行初始化:

seam_init(sem, count)

init_MUTEX(sem)

init_MUTEX_LOCKED(struct semaphore *)

显然,带有MUTEX的函数始初始化互斥信号量。LOCKED则初始化信号量为锁状态。

• 使用信号量

信号量初始化完成后我们就可以使用它了

down_interruptible(struct semaphore *)

down(struct semaphore *)

down_trylock(struct semaphore *)

up(struct semaphore *)

down函数会尝试获取指定的信号量,如果信号量已经被使用了,则进程进入不可中断的睡眠状态。down_interruptible则会使进程进入可中断的睡眠状态。关于进程状态的详细细节,我们在内核的进程管理里在做详细介绍。

down_trylock尝试获取信号量, 如果获取成功则返回0,失败则会立即返回非0。

当退出临界区时使用up函数释放信号量,如果信号量上的睡眠队列不为空,则唤醒其中一个等待进程。

八、读写信号量

类似于自旋锁,信号量也有读写信号量。读写信号量API定义在头文件中,它的定义其实也是体系结构相关的,因此具体实现定义在头文件中,以下是x86的例子:

struct rw_semaphore {

signed long count

spinlock_t wait_lock

struct list_head wait_list

}

线程同步的方式包括:互斥锁、读写锁、条件变量、信号量和令牌。

以Java语言为例:

用synchronized关键字修饰同步方法。

同步有几种实现方法分别是synchronized,wait与notify

wait():使一个线程处于等待状态,并且释放所持有的对象的lock。

sleep():使一个正在运行的线程处于睡眠状态,是一个静态方法,调用此方法要捕捉InterruptedException异常。

notify():唤醒一个处于等待状态的线程,注意的是在调用此方法的时候,并不能确切的唤醒某一个等待状态的线程,而是由JVM确定唤醒哪个线程,而且不是按优先级。

Allnotity():唤醒所有处入等待状态的线程,注意并不是给所有唤醒线程一个对象的锁,而是让它们竞争。

同步是多线程中的重要概念。同步的使用可以保证在多线程运行的环境中,程序不会产生设计之外的错误结果。同步的实现方式有两种,同步方法和同步块,这两种方式都要用到synchronized关键字。

给一个方法增加synchronized修饰符之后就可以使它成为同步方法,这个方法可以是静态方法和非静态方法,但是不能是抽象类的抽象方法,也不能是接口中的接口方法。下面代码是一个同步方法的示例:

public synchronized void aMethod() {

// do something

}

public static synchronized void anotherMethod() {

// do something

}

线程在执行同步方法时是具有排它性的。当任意一个线程进入到一个对象的任意一个同步方法时,这个对象的所有同步方法都被锁定了,在此期间,其他任何线程都不能访问这个对象的任意一个同步方法,直到这个线程执行完它所调用的同步方法并从中退出,从而导致它释放了该对象的同步锁之后。在一个对象被某个线程锁定之后,其他线程是可以访问这个对象的所有非同步方法的。

同步块是通过锁定一个指定的对象,来对同步块中包含的代码进行同步;而同步方法是对这个方法块里的代码进行同步,而这种情况下锁定的对象就是同步方法所属的主体对象自身。如果这个方法是静态同步方法呢?那么线程锁定的就不是这个类的对象了,也不是这个类自身,而是这个类对应的java.lang.Class类型的对象。同步方法和同步块之间的相互制约只限于同一个对象之间,所以静态同步方法只受它所属类的其它静态同步方法的制约,而跟这个类的实例(对象)没有关系。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/7444229.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-05
下一篇 2023-04-05

发表评论

登录后才能评论

评论列表(0条)

保存