linux实现多线程 实现多线程有几种方式
本篇文章给大家谈谈linux实现多线程,以及实现多线程有几种方式对应的知识点,文章可能有点长,但是希望大家可以阅读完,增长自己的知识,最重要的是希望对各位有所帮助,可以解决了您的问题,不要忘了收藏本站喔。
...linux下多线程和多进程通信的实现方法,请通俗解释
兄弟看到你这么高的分我就找了些资料:也算是对昨天学的知识总结一下吧
一、先说概念不管是windows还是linux下的进程和线程概念都是一样的,只是管理进程和线程的方式不一样,这个是前提,到时候你可别问我windows下进程和线程啊。这个涉及到操作系统原理。下面给你解答。
说道进程不得不提作业这个名词,我想兄弟你电脑里不会有一个程序吧对不?当你的系统启动完毕后你看看你的任务管理器里是不是有很多进程呢?那么多程序是怎么调如内存呢?能理解吗?这里要明白程序和进程的关系,程序是你磁盘上的一个文件,当你需要它时进入内存后才成为进程,好比QQ在磁盘上就是一个文件而已,只有进入了内存才成为进程,进程是活动的。QQ要扫描你文件啊,记录你聊天记录啊,偷偷上传个啥东西什么的你也不知道对不,他是活动的。这个能明白吗?
再看作业,这个作业可不是你写作业的那个作业啊。系统一看好家伙你个QQ那么大的家伙你想一下子进入内存啊?没门!慢慢来嘛,系统就把QQ程序分为好几块,这几块不能乱分的,要符合自然结构就是循环啦选择啦这样的结构,你把人家循环结构咔嚓截断了,怎么让人家QQ运行啊?这就是作业要一块一块的进入内存,同时要为作业产生JCB(JOB CONTROL BLOCK)作业控制块,你进入内存不能乱跑啊,要听系统的话,你要是进入系统自己的内存。框一下,内存不能读写对话框就出来了,严重点直接蓝脸给你!你懂得。这是window下的,linux下直接给你报错!没事了就!所一系统通过jcb控制进程。JCB包含了进程号优先级好多内容,你打开你的windows任务管理器看看进程是不是有好多属性啊?那就是PCB(PRCESS,CONTROL BLOCK)同理作业也包含那些内容只是多少而已。下面写出进程特点:
1、进程是分配计算机资源最小的单位。你想啊人是要用程序干活的吧?你把程序调入内存成了就成了进程,所以说进程是分配资源的最小单位。你在linux下打开终端输入top命令看是不是有好多进程?
2、进程有操作系统为作业产生。有“父进程”产生“子进程”之间是父子关系,并可以继续向下产生“子进程”。还拿QQ来说,你双击QQ.exe。QQ启动了输入账号密码打开主界面了。这时候你要聊天,QQ进程赶紧产生个“儿子”说“儿子你去陪主人聊天去吧。这样子进程产生了。突然你想看美女要传照片这时候那个”儿子“有”生“了一个”儿子“说”儿子“你去传照片。那个“儿子领到任务去传照片了。这时你想关了QQ,QQ提示你说”你还有个“儿子”和“孙子”还在干活呢你真要结束吗?你蒽了确定。QQ对他“儿子”(你聊天窗口)说:”儿子啊对不起了,主人要关闭我你也不能活啊“咔嚓一下”儿子“死了,儿子死之前对他儿子说:“儿子啊你爷爷不让我活了,你也别活了咔嚓孙子也死了。最后世界安静了。这就是进程的父子关系。能明白吗?记住:进程之活动在内存中。不能使用CPU,只管分配资源。
再说线程:线程也产生在内存中并且在内存中存在相当长的时间,但它的活动区域主要在CPU中,并且运行和灭亡都存在于CPU中,可以这么说,线程是程序中能被系统调度进入CPU中最小程序单位,它能直接使用进程分配的CPU的资源。
还拿QQ来说当你要传文件时QQ总要判断一下文件的扩展名吧,ok这时那个”儿子“赶紧对它爸爸说我需要一个线程判断扩展名QQ赶紧对一个管这个的线程说:”快点去CPU里计算下那个扩展名是什么然后向主人报告计算完了就“死了”消亡了,但是它的线程还在内存中!还等着你下一次传文件然后计算然后消亡!
线程之间是相互独立的。一个在CPU,一个在内存里还能有关系吗对不?CPU在每一个瞬间只能进入一个线程,当线程进入CPU时立即产生一个新的线程,新线程仍停留在内存中,就好比上面那个传文件还会等着你再传文件再计算扩展名。
线程相对线程是独立的,但它在内存中并不是独立的,这就好比你不开QQ能用QQ传输文件吗?它只存在与进程分配的资源中,也就是说计算扩展名这个线程只能停留在QQ这个进程中,不能跑到别的进程里!!相当于程序产生了新的进程和线程,进程向CPU申请资源,再有线程来使用,他们都是为程序服务的只是分工不同!
因为你没提问linux下是怎么管理进程和线程的所以我就不回答了,这个问题我建议你还是看看《笨兔兔的故事》里面讲到了linux是怎么管理进程和线程的。挺幽默的比我说得还好。
你第二个问题说实话我回答不了你!我想你现在连进程和线程还没理解第二个你更理解不了了你说对不?我猜的其实你用C/C++不管是在windows下编程还是在Linux下编程思想都是一样的对吧,如果你理解了在windows下线程间通信,在linux更没问题了!
参考资料:黑客手册2009合订本非安全第一二季244页,245页,328页,329页,398页,399页
浅谈操作系统原理(一二三)
ubuntu中文论坛笨兔兔的故事
希望我的回答你能理解
如何实现linux下多线程之间的互斥与同步
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;
};
linux线程查询指令linux线程查询
怎么在linux系统下查看网卡状态信息?
方法一:
ethtooleth0采用此命令可以查看到网卡相关的技术指标。
(不一定所有网卡都支持此命令)
ethtool-ieth1加上-i参数查看网卡驱动。
可以尝试其它参数查看网卡相关技术参数。
方法二:
也可以通过dmesg|grepeth0等看到网卡名字(厂家)等信息。
通过查看/etc/sysconfig/network-scripts/ifcfg-eth0可以看到当前的网卡配置包括IP、网关地址等信息。
当然也可以通过ifconfig命令查看。
Linux是一套免费使用和自由传播的类Unix操作系统,是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想,是一个性能稳定的多用户网络操作系统。Linux操作系统诞生于1991年10月5日(这是第一次正式向外公布时间)。Linux存在着许多不同的Linux版本,但它们都使用了Linux内核。Linux可安装在各种计算机硬件设备中,比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。严格来讲,Linux这个词本身只表示Linux内核,但实际上人们已经习惯了用Linux来形容整个基于Linux内核,并且使用GNU工程各种工具和数据库的操作系统。
linux查看活跃线程命令?
可以执行ps-ef进行查看
Linux多线程通信?
PIPE和FIFO用来实现进程间相互发送非常短小的、频率很高的消息;
这两种方式通常适用于两个进程间的通信。
共享内存用来实现进程间共享的、非常庞大的、读写操作频率很高的数据(配合信号量使用);
这种方式通常适用于多进程间通信。
其他考虑用socket。这里的“其他情况”,其实是今天主要会碰到的情况:
分布式开发。
在多进程、多线程、多模块所构成的今天最常见的分布式系统开发中,
socket是第一选择
。消息队列,现在建议不要使用了----因为找不到使用它们的理由。在实际中,我个人感觉,PIPE和FIFO可以偶尔使用下,共享内存都用的不多了。在效率上说,socket有包装数据和解包数据的过程,所以理论上来说socket是没有PIPE/FIFO快,不过现在计算机上真心不计较这么一点点速度损失的。你费劲纠结半天,不如我把socket设计好了,多插一块CPU来得更划算。另外,进程间通信的数据一般来说我们都会存入数据库的,这样万一某个进程突然死掉或者整个服务器死了,也不至于丢失重要数据、便于回滚到之前的状态。从这个角度考虑,适用共享内存的情况也更少了,所以socket使用得更多。再多说一点关于共享内存的:共享内存的效率确实高,但它的重点在“共享”二字上。如果的确有好些进程共享一大块数据(如果把每个进程都看做是类的对象的话,那么共享数据就是这个类的static数据成员),那么共享内存就是一个不二的选择了。但是在面向对象的今天,我们更多的时候是多线程+锁+线程间共享数据。因此共享进程在今天使用的也越来越少了。不过,在面对一些极度追求效率的需求时,共享内存就会成为唯一的选择,比如高频交易系统。除此以外,一般是不需要特意使用共享内存的。另外,
PIPE和共享内存是不能跨LAN的
(FIFO可以但FIFO只能用于两个进程通信)
。
如果你的分布式系统随着需求的增加而越来越大所以你想把不同的模块放在不同机器上而你之前开发的时候用了PIPE或者共享内存,那么你将不得不对代码进行大幅修改......同时,即使FIFO可以跨越LAN,其代码的可读性、易操作性和可移植性、适应性也远没有socket大。这也就是为什么一开始说socket是第一选择的原因。最后还有个信号简单说一下。
请注意,是信号,不是信号量。
信号量是用于同步线程间的对象的使用的(建议题主看我的答案,自认为比较通俗易懂:
semaphore和mutex的区别?-Linux-知乎
)。信号也是进程间通信的一种方式。比如在Linux系统下,一个进程正在执行时,你用键盘按Ctrl+c,就是给这个进程发送了一个信号。进程在捕捉到这个信号后会做相应的动作。虽然信号是可以自定义的,但这并不能改变信号的局限性:
不能跨LAN、信息量极其有限
。在现代的分布式系统中,通常都是
消息驱动:
即进程受到某个消息后,通过对消息的内容的分析然后做相应的动作。如果你把你的分布式系统设置成信号驱动的,这就表示你收到一个信号就要做一个动作而一个信号的本质其实就是一个数字而已。这样系统稍微大一点的话,系统将变得异常难以维护;甚至在很多时候,信号驱动是无法满足我们的需求的。因此现在我们一般也不用信号了。因此,请记住:
除非你有非常有说服力的理由,否则请用socket。
顺便给你推荐个基于socket的轻量级的消息库:ZeroMQ。
linux下,如何查看工控机的串口被哪个线程占用,能否使该线程强制释放串口?
在串口的驱动程序注册的open函数里加入这样一句话:printk("process%dhasopenttyn",current->pid);可以判断出来哪个进程打开了串口设备,或者是否有进程打开串口current->pid的值表示进程号!