linux中的信号怎么理解？

linux的常用信号量BUS与SEGV二者都是错误信号，BUS表示总线错误，SEGV表示段错误，程序崩溃的时候99%都是这两个错误导致的。进程可以捕获和封锁这两类错误。内核对二者的默认处理是memorydumpWINCH窗口改变信号（WINdownCHanged）。例如虚拟终端的行数发生变化时将发送WINCH信号，绝大多数文本编辑器都能捕获WINCH信号自动进行重新配置。内核的默认处理是忽略该信号，并且不进行内存转储。进程可以捕获或者封锁该信号KILL 杀死/删除进程，编号为9STOP 挂起/暂停正在执行的进程，直到收到CONT为止KILLSTOP都不能够被捕获、封锁或者忽略，默认处理都不会产生内存转储。CONT 取消挂起，继续执行进程TSTP 是STOP信号的“软”版本，即在用户输入Ctrl+Z时由终端驱动程序发送的信号。捕获到该信号的进程通常清除它们的状态，如何给自己发送一个STOP信号。TSTP的默认处理不会导致内存转储。INT 中断信号，编号为2当用户输入Ctrl+C时由终端驱动程序发送INT信号INT信号是终止当前 *** 作的请求，简单程序捕获到INT信号时应该退出，拥有命令行或者输入模式的那些程序应该停止他们正在做的事情，清除状态，并等待用户再次输入。TERM 软件终止信号，编号为15TERM是请求彻底终止某项 *** 作的信号，它期望进程清楚自己的状态并退出QUIT 退出信号，编号为3与TERM类似，不同之处在于QUIT信号的默认处理是内存转储，而TERM信号的默认处理没有内存转储。HUP 挂起信号，编号为1，有两种解释：守护进程理解HUP为重新设置的请求，如果守护进程能够不用重新启动就能够重新读取它自己的配置文件并调整自己以适应变化的话，那么HUP信号通常可以用来触发这种行为HUP信号有时有终端驱动程序生成，试图用来清除（也就是终止）跟某个特定终端相连接的那些进程。例如当一个终端会话结束时，或者当一个Modem的连接不经意的断开时，就可能出现这种情况。如果需要某些进程在会话结束之后继续运行，那么在CShell中设法让这些进程变成后台程序，ksh或者bash中可以用nohup来模拟这种行为。++++++++++++++++++++++++++++++++++++++++++++++++++++++++++进程的四种状态runnable（可运行状态）只要有CPU时间，进程就可以执行。一旦进程执行了不能立即完成的系统调用，Linux会把进程转入睡眠状态sleeping（睡眠状态）进程在等待某些事件发生（如终端输入、网络连接）zombie（僵化状态）进程已经执行完毕并试图消亡，但是状态没有收集完stopped（停止状态）进程被挂起，不允许执行。进程收到STOP或者TSTP信号即进入停止状态，可以用CONT信号来重新启动

首先，一句话总结它们之间的区别：

字面上相似，但是本质上存在巨大的差别！请看详细解答...

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驱动系统的访问。

1 信号的响应动作

每个信号都有自己的响应动作，当接收到信号时，进程会根据信号的响应动作执行相应的 *** 作，信号的响应动作有以下几种：

中止进程(Term)

忽略信号(Ign)

中止进程并保存内存信息(Core)

停止进程(Stop)

继续运行进程(Cont)

用户可以通过signal或sigaction函数修改信号的响应动作（也就是常说的“注册信号”，在文章的后面会举例说明）。另外，在多线程中，各线程的信号响应动作都是相同的，不能对某个线程设置独立的响应动作。

2 信号类型

Linux支持的信号类型可以参考下面给出的列表。

2.1 在POSIX.1-1990标准中的信号列表

2.2 在SUSv2和POSIX.1-2001标准中的信号列表

2.3 其它信号

---