操作系统 Chap.4 中断 / 异常 / 信号量

1. 引子: 模式转换(Mode Switch)

所谓模式转换, 意味着程序在运行过程中在不同的CPU模式之间切换.

先前提到过的CPU模式: (详见Chap.2中1.3的内容)
User Mode: 用户态(目态)
Kernel Mode: 内核态(管态)

所以, 到底什么时候会出现模式切换?

我们在此前的文章中已经提及了系统调用的内容(详见Chap.2中2.3), 本文我们将对中断与异常进行梳理总结.

通常我们能遇到的异常分两类:

程序异常(Programmed exceptions / Traps )
- int 0x80; 这是发出系统调用的旧方法
异常运行(Anomalous executions / Faults )
- $ a/0 $ ; 除0
- p = NULL; a = *p; 引用空指针

说到这了, 异常到底是怎么被捕获 / 处理的呢?

我们通过除0 这一典型问题来说明这一过程:

总结一下:

异常在出现的一瞬间会被处理器捕获, 并转向内核态唤醒异常处理程序(Exception Handlers). 随后异常处理程序通常会将该异常转化为一个在用户态能够表示的信号量(SIGNAL), 并退出内核态.

通常的终止方式有以下几种:

kill -signame pid / kill(pid, sig)
- pid的含义并不很简单:
  - pid > 0: 意味着指向某个真实的进程
  - pid == 0: 意味着 发送异常的进程的同组全部进程
  - pid == -1: ;意味着 发送异常的进程有权发送信号的全部进程
pthread_kill()
- 用于杀死某个发送进程的指定线程
tgkill(pid, tid, sig)
sigqueue(pid, sig, value)

需要明确, 当一个进程被终止时, 其父进程会收到 SIGCHILD 信号

我们在2.2异常处理的最后一步中涉及到了一个判断.

如果该进程定义了浮点异常信号的处理程序, 则执行该程序;

此即信号处理程序(Signal handler) 的意义所在.

正常情况下, 系统针对不同的信号有自己的一套处理机制, 比如上文中遇到SIGFPE信号时, 系统默认的反应是直接杀死该进程.

但当用户在自己的进程中定义了针对该信号的处理机制时, 系统会优先遵循用户的定义.

系统提供了两种函数来进行默认处理机制的更改:

signal(): 通常不推荐使用该函数. 当你定义的处理程序被调用一次后, 它就会失效, 后续的处理继续遵循系统默认的设置.
sigaction(): 相比前者功能更全面, 如:
- 当定义的处理程序被调用时, 会自动阻塞其它的信号
- 如果阻塞中的系统调用(比如read / write)被信号处理程序打断, 在信号处理程序执行完毕后, 系统调用会自动重启.