
字面上相似,但是本质上存在巨大的差别!请看详细解答...
Linux信号(signal) 机制
signal,又简称为信号(软中断信号)用来通知进程发生了异步事件。
原理:
一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是进程间通信机制中唯一的异步通信机制,一个进程不必通过任何 *** 作来等待信号的到达,事实上,进程也不知道信号到底什么时候到达。进程之间可以互相通过系统调用kill发送软中断信号。内核也可以因为内部事件而给进程发送信号,通知进程发生了某个事件。信号机制除了基本通知功能外,还可以传递附加信息。
分类:
从两个不同的分类角度对信号进行:
可靠性方面:可靠信号与不可靠信号;
与时间的关系上:实时信号与非实时信号。
部分定义转自:http://www.cnblogs.com/hoys/archive/2012/08/19/2646377.html
Linux信号量(semaphore)机制
Linux内核的信号量用来 *** 作系统进程间同步访问共享资源。
原理:信号量在创建时需要设置一个初始值,表示同时可以有几个任务可以访问该信号量保护的共享资源,初始值为1就变成互斥锁(Mutex),即同时只能有一个任务可以访问信号量保护的共享资源。
一个任务要想访问共享资源,首先必须得到信号量,获取信号量的 *** 作将把信号量的值减1,若当前信号量的值为负数,表明无法获得信号量,该任务必须挂起在该信号量的等待队列等待该信号量可用;若当前信号量的值为非负数,表示可以获得信号量,因而可以立刻访问被该信号量保护的共享资源。
当任务访问完被信号量保护的共享资源后,必须释放信号量,释放信号量通过把信号量的值加1实现,如果信号量的值为非正数,表明有任务等待当前信号量,因此它也唤醒所有等待该信号量的任务。
常用的信号量的API:
DECLARE_MUTEX(name)
该宏声明一个信号量name并初始化它的值为0,即声明一个互斥锁。
DECLARE_MUTEX_LOCKED(name)
该宏声明一个互斥锁name,但把它的初始值设置为0,即锁在创建时就处在已锁状态。因此对于这种锁,一般是先释放后获得。
void sema_init (struct semaphore *sem, int val)
该函用于数初始化设置信号量的初值,它设置信号量sem的值为val。
void init_MUTEX (struct semaphore *sem)
该函数用于初始化一个互斥锁,即它把信号量sem的值设置为1。
void init_MUTEX_LOCKED (struct semaphore *sem)
该函数也用于初始化一个互斥锁,但它把信号量sem的值设置为0,即一开始就处在已锁状态。
void down(struct semaphore * sem)
该函数用于获得信号量sem,它会导致睡眠,因此不能在中断上下文(包括IRQ上下文和softirq上下文)使用该函数。该函数将把sem的值减1,如果信号量sem的值非负,就直接返回,否则调用者将被挂起,直到别的任务释放该信号量才能继续运行。
int down_interruptible(struct semaphore * sem)
该函数功能与down类似,不同之处为,down不会被信号(signal)打断,但down_interruptible能被信号打断,因此该函数有返回值来区分是正常返回还是被信号中断,如果返回0,表示获得信号量正常返回,如果被信号打断,返回-EINTR。
int down_trylock(struct semaphore * sem)
该函数试着获得信号量sem,如果能够立刻获得,它就获得该信号量并返回0,否则,表示不能获得信号量sem,返回值为非0值。因此,它不会导致调用者睡眠,可以在中断上下文使用。
void up(struct semaphore * sem)
该函数释放信号量sem,即把sem的值加1,如果sem的值为非正数,表明有任务等待该信号量,因此唤醒这些等待者。
实例:
信号量在绝大部分情况下作为互斥锁使用,下面以console驱动系统为例说明信号量的使用。
在内核源码树的kernel/printk.c中,使用宏DECLARE_MUTEX声明了一个互斥锁console_sem,它用于保护console驱动列表console_drivers以及同步对整个console驱动系统的访问。
linux的常用信号量
BUS与SEGV
二者都是错误信号,BUS表示总线错误,SEGV表示段错误,程序崩溃的时候99%都是这两个错误导
致的。进程可以捕获和封锁这两类错误。内核对二者的默认处理是memory dump
WINCH
窗口改变信号(WINdown CHanged)。例如虚拟终端的行数发生变化时将发送WINCH信号,绝大多数
文本编辑器都能捕获WINCH信号自动进行重新配置。内核的默认处理是忽略该信号,并且不进行内存
转储。
进程可以捕获或者封锁该信号
KILL
杀死/删除进程,编号为9
STOP
挂起/暂停正在执行的进程,直到收到CONT为止
KILL STOP都不能够被捕获、封锁或者忽略,默认处理都不会产生内存转储。
CONT
取消挂起,继续执行进程
TSTP
是STOP信号的“软”版本,即在用户输入Ctrl+Z时由终端驱动程序发送的信号。捕获到该信号的进程通常
清除它们的状态,如何给自己发送一个STOP信号。TSTP的默认处理不会导致内存转储。
INT
中断信号,编号为2
当用户输入Ctrl+C时由终端驱动程序发送INT信号
INT信号是终止当前 *** 作的请求,简单程序捕获到INT信号时应该退出,拥有命令行或者输入模式的那些
程序应该停止他们正在做的事情,清除状态,并等待用户再次输入。
TERM
软件终止信号,编号为15
TERM是请求彻底终止某项 *** 作的信号,它期望进程清楚自己的状态并退出
QUIT
退出信号,编号为3
与TERM类似,不同之处在于QUIT信号的默认处理是内存转储,而TERM信号的默认处理没有内存转储。
HUP
挂起信号,编号为1,有两种解释:
守护进程理解HUP为重新设置的请求,如果守护进程能够不用重新启动就能够重新读取它自己的配置文
件并调整自己以适应变化的话,那么HUP信号通常可以用来触发这种行为
HUP
信号有时有终端驱动程序生成,试图用来清除(也就是终止)跟某个特定终端相连接的那些进程。例如
当一个终端会话结束时,或者当一个Modem的连接不经意的断开时,就可能出现这种情况。
如果需要某些进程在会话结束之后继续运行,那么在C Shell中设法让这些进程变成后台程序,
ksh或者bash中可以用nohup来模拟这种行为。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
进程的四种状态
runnable(可运行状态)
只要有CPU时间,进程就可以执行。一旦进程执行了不能立即完成的系统调用,Linux会把进程转入
睡眠状态
sleeping(睡眠状态)
进程在等待某些事件发生(如终端输入、网络连接)
zombie(僵化状态)
进程已经执行完毕并试图消亡,但是状态没有收集完
stopped(停止状态)
进程被挂起,不允许执行。进程收到STOP或者TSTP信号即进入停止状态,可以用CONT信号来重新启动
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)