├── Deep_into_OperatingSystem.md ├── README.md └── docs ├── Charpter 1.md ├── Charpter 10.md ├── Charpter 11.md ├── Charpter 12.md ├── Charpter 2.md ├── Charpter 3.md ├── Charpter 4.md ├── Charpter 5.md ├── Charpter 6.md ├── Charpter 7.md ├── Charpter 8.md └── Charpter 9.md /Deep_into_OperatingSystem.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 深入理解操作系统学习笔记 3 | date: 2020-11-08 20:07:00 4 | tags: 5 | - 深入理解操作系统学习笔记 6 | categories: 7 | - 操作系统 8 | --- 9 | 10 | 11 | 12 | # 第一章 13 | 14 | 15 | > 第一章的主要内容是 : 操作系统的一些知识 16 | 17 | ### 操作系统是什么？ 18 | 19 | 用户角度：操作系统是一个控制软件 20 | 21 | 22 | 23 | * 管理应用程序 24 | * 为应用程序提供服务 25 | * 杀死应用程序 26 | 27 | 程序角度：操作系统是资源管理器 28 | 29 | * 管理外设、分配资源 30 | * 抽象 31 | * 将CPU抽象成进程 32 | * 将磁盘抽象成文件 33 | * 将内存抽象成地址空间 34 | 35 | ### 操作系统层次 36 | 37 | 位于硬件之上，应用程序之下。 38 | 39 | ### 操作系统的界面和内核 40 | 41 | Linux Windows Android 的界面属于外壳(Shell) ，而不是内核(kernel)。操作系统研究的是内核，处于Shell之下。 42 | 43 | ### 操作系统内部组件 44 | 45 | * CPU调度器 46 | * 物理内存管理 47 | * 虚拟内存管理 48 | * 文件系统管理 49 | * 中断处理与设备驱动 50 | 51 | ### 操作系统特征 52 | 53 | * 并发 54 | * 一段时间内运行多个进程（并行 : 一个时间点运行多个进程，一般要求有多个CPU) 55 | * 需要OS管理和调度 56 | * 共享 57 | * “同时”共享 58 | * 互斥共享 59 | * 虚拟 60 | * 让每一个用户觉得的有一个计算机专门为他服务 61 | * 异步 62 | * 程序是走走停停，而不是一直运行 63 | 64 | 65 | 66 | # 第二章 67 | 68 | > 第二章的主要内容是 : 操作系统的异常/中断/系统调用 69 | 70 | ## 探究计算机启动过程 71 | 72 | **作用解析** 73 | 74 | Disk : 存放OS和Bootloader 75 | 76 | BOIS : 基于I/O处理系统 77 | 78 | Bootloader : 加载OS，将OS放入内存 79 | 80 | **结构** 81 | 82 | Disk 83 | 84 | |___ OS 85 | 86 | |___ Bootloader 87 | 88 | **开机流程** 89 | 90 | 1. BIOS 91 | * 开机后，寻找显卡和执行BIOS (此时, `CS : IP = 0xF000 : 0xFFF0`, CS/IP 两个寄存器) 92 | * 将Bootloader从磁盘的引导扇区加载到0x7C00 (Bootloader一共占用512M字节的内存) 93 | * 跳转到 `CS : IP = 0x0000 : 0x7C00` 94 | 95 | 2. Bootloader 96 | * 将操作系统的代码和数据从硬盘加载到内存中 97 | * 跳转到操作系统的起始地址 98 | 99 | ## 中断、异常、系统调用 100 | 101 | ### 中断 102 | 103 | 中断来源于外设，来自不同的硬件设备的计时器和网络的中断。 104 | 105 | **中断流程** 106 | 107 | 硬件：设置中断标记（CPU初始化） 108 | 109 | 1. 将内部、外部事件设置中断标记 110 | 2. 中断事件的ID 111 | 112 | 软件 113 | 114 | 1. 保存当前处理状态（寄存器之类的一些数据） 115 | 2. 根据中断事件的ID跳转到中断服务程序，中断服务程序处理 116 | 3. 清楚中断标记 117 | 118 | ### 异常 119 | 120 | 异常来源于不良的应用程序，非法指令或者其他坏的处理状态（如：内存出错）。 121 | 122 | **异常处理流程** 123 | 124 | 1. 保存现场 125 | 2. 异常处理 126 | 1. 杀死了产生异常的程序 127 | 2. 重新执行异常指令 128 | 3. 恢复现场 129 | 130 | ### 系统调用 131 | 132 | 系统调用来源于应用程序，应用程序主动向操作系统发出服务请求。程序访问主要是通过高层次的API，而不是直接调用系统调用函数。 133 | 134 | **APIs** 135 | 136 | - Win32 API 用于Windows 137 | - POSIX API 用于 POSIX-based systems（包括UNIX，LINUX，Mac OS X） 138 | - Java API 用于JAVA虚拟机 139 | 140 | **特点** 141 | 142 | - 通常情况下，每个系统调用有对应的序号 143 | - 系统调用接口根据这些序号来维护表的索引 144 | - 系统调用接口调用内核态中预期的系统调用 145 | - 并返回系统调用的状态和其他任何返回值 146 | - 用户不需要知道系统调用是如何实现的 147 | - 只需要获取API和了解操作系统将什么作为返回结果 148 | - 操作系统接口的细节大部分都隐藏在API中 149 | 150 | **用户态**：操作系统运行中，CPU处于的特权级别，不能直接执行特权指令 151 | 152 | **内核态**：操作系统运行中，CPU处于的特权级别，可以执行任何一条指令 153 | 154 | **系统调用**：触发CPU从用户态到内核态的转换，切换程序和内核的堆栈，需要一定的开销 155 | 156 | **跨越操作系统边界的开销（值得的且必须的，保证了操作系统的安全性）** 157 | 158 | - 在执行时间上的开销超过程序调用 159 | - 开销： 160 | - 建立中断、异常、系统调用号与对应服务例程映射关系的初始化开销 161 | - 建立内核堆栈 162 | - 验证参数 163 | - 内核态映射到用户态的地址空间（更新页面映射权限） 164 | - 内核态独立地址空间（TLB） 165 | 166 | ### 区别 167 | 168 | | 类型 | 源头 | 处理时间 | 响应 | 169 | | -------- | ------------------------ | ---------- | -------------------- | 170 | | 中断 | 外设 | 异步 | 持续，对应用程序透明 | 171 | | 异常 | 应用程序意向不到的行为 | 同步 | 杀死或重新执行指令 | 172 | | 系统调用 | 应用程序请求系统提供服务 | 同步或异步 | 等待和持续 | 173 | 174 | > 异步：应用程序不知道什么时候会发生中断 175 | 176 | > 同步：执行到某一条指令一定会发生该事件 177 | 178 | ### 为什么应用程序不能直接访问硬件？ 179 | 180 | - 在计算机运行时，内核是被信任的第三方 181 | - 只有内核可以执行特权指令 182 | - 为了方便应用程序 183 | 184 | 185 | 186 | # 第三章 187 | 188 | > 第三章的主要内容是 : 操作系统的物理内存管理 189 | 190 | ## 计算机体系结构 191 | 192 | 1. CPU 193 | 2. 内存 194 | 3. I/O 195 | 196 | ## 内存分层体系 197 | 198 | ### 内存分层体系 199 | 200 | 运行内存(主存) / 磁盘(虚拟内存). 主存是在运行程序时所需要保存的数据空间，而磁盘是用于持久化数据保存的数据空间. 201 | 202 | CPU可以访问的内存包括两大类 : 寄存器 / cache(L1缓存 / L2缓存) 203 | 204 | **层次** 205 | 206 | 微处理器(CPU访问) 207 | 208 | |___CPU寄存器 / L1缓存 209 | 210 | |___L2缓存 211 | 212 | 主存(程序访问) 213 | 214 | 磁盘(程序访问) 215 | 216 | > 从CPU寄存器到磁盘，读写速度不断降低，单位成本不断降低，大小不断增大。 217 | 218 | ### 内存管理目标 219 | 220 | * 抽象：逻辑地址空间 221 | 222 | * 保护：独立地址空间 223 | 224 | * 共享：访问相同内存 225 | 226 | * 虚拟：更多的地址空间 227 | 228 | ### 内存管理方法 229 | 230 | * 程序重定位 231 | * 分段 232 | * 分页 233 | * 虚拟内存 234 | * 按需分页虚拟内存 235 | 236 | > 实现高度依赖于硬件, 其中内存管理单元(MMU)负责处理CPU的内存访问请求 237 | 238 | ## 地址空间 239 | 240 | 地址空间的定义 241 | 242 | * 物理地址空间 —— 硬件支持的地址空间( address : [0, Max_sys] ) 243 | * 逻辑地址空间 —— 一个运行在程序所拥有的的内存范围( address : [0, Max_prog] ) 244 | 245 | ## 连续内存分配 246 | 247 | ### 内存碎片问题 248 | 249 | 内存碎片问题指的是空闲的内存无法被利用 250 | 251 | * 外部碎片 : 分配单元间的未使用内存 252 | * 内部碎片 : 分配单元内的未使用内存 253 | 254 | ### 分区的动态分配 255 | 256 | 分区的动态分配方式有以下三种 : 257 | 258 | 1. 第一匹配分配 : 在内存中找到第一个比需求大的空闲块, 分配给应用程序 259 | 2. 最优适配分配 : 在内存中找到最小的空闲块, 分配给应用程序 260 | 3. 最差适配分配 : 在内存中找到最大的空闲块, 分配给应用程序 261 | 262 | 分配方式的区别 263 | 264 | | 分配方式 | 第一匹配分配 | 最优适配分配 | 最差适配分配 | 265 | | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | 266 | | 分配方式实现需求 | 1. 按地址排序的空闲块列表
2. 分配需要寻找一个合适的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 1. 按尺寸排序的空闲块列表
2. 分配需要寻找一个合适的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 1. 按尺寸排序的空闲块列表
2. 分配最大的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 267 | | 优势 | 简单 / 易于产生更大空闲块 | 比较简单 / 大部分分配是小尺寸时高效 | 分配很快 / 大部分分配是中尺寸时高效 | 268 | | 劣势 | 产生外部碎片 / 不确定性 | 产生外部碎片 / 重分配慢 / 产生很多没用的微小碎片 | 产生外部碎片 / 重分配慢 / 易于破碎大的空闲块以致大分区无法被分配 | 269 | 270 | > 三种分配方式并无优劣之分，因为我们无法判断内存请求的大小 271 | 272 | ## 碎片整理方法 273 | 274 | 可以看到的是，三种分区动态分配的方式都会产生外部碎片，因此我们可以对碎片进行一定的整理来解决碎片问题。 275 | 276 | 1. 压缩式碎片整理 277 | * 重置程序以合并碎片 278 | * 要求所有程序是动态可重置的 279 | * 问题 : 280 | * 何时重置 ? (在程序处于等待状态时才可以重置) 281 | * 需要考虑内存拷贝的开销 282 | 283 | 2. 交换式碎片整理 284 | 285 | * 运行程序需要更多的内存时，抢占等待的程序并且回收它们的内存 286 | 287 | * 问题 : 288 | 289 | * 哪些程序应该被回收 ? 290 | 291 | * 情况 : 292 | 293 | 运行中 : P3 294 | 295 | 等待中 : P1 P2 P4 296 | 297 | 内存分布 -> 主存 : OS / P1 / P3 / P2 / P4 磁盘 : 空 298 | 299 | 当P3程序需要更大的内存时 -> 300 | 301 | 内存分布 -> 主存 : OS / P1 / P3 / P2 磁盘 : P4 302 | 303 | 304 | 305 | # 第四章 306 | 307 | > 第四章的主要内容是：操作系统的非连续内存分配 308 | 309 | 第三章介绍的是连续内存管理, 即 : 操作系统加载到内存以及程序加载到内存中时, 分配一块连续的空闲(内存)块. 但是容易出现碎片问题, 这一章介绍的非连续内存分配可以有效的减少碎片的出现. 310 | 311 | ## 非连续内存分配的必要性 312 | 313 | ### 连续内存分配的缺点 314 | 315 | 1. 分配给一个程序的物理内存是连续的 316 | 2. 内存利用率低 317 | 3. 有外碎片 / 内碎片的问题 318 | 319 | ### 非连续内存分配的优点 320 | 321 | 1. 一个程序的物理地址空间是非连续的 322 | 323 | 2. 更好的内存利用和管理 324 | 325 | 3. 允许共享代码与数据(共享库等...) 326 | 327 | 4. 支持动态加载和动态链接 328 | 329 | ### 非连续内存分配的缺点 330 | 331 | 1. 建立虚拟地址和物理地址的转换难度大 332 | 333 | * 软件方案 334 | 335 | * 硬件方案(采用硬件方案) : 分段 / 分页 336 | 337 | ## 非连续内存分配 338 | 339 | ### 分段(Segmentation) 340 | 341 | **段 :** 在程序中会有来自不同文件的函数 ; 在程序执行时, 不同的数据也有不同的字段, 比如 : 堆 / 栈 / .bss / .data 等 342 | 343 | **分段 : ** 更好的分离和共享 344 | 345 | 程序的分段地址空间如下图所示 : 346 | 347 | 348 | 349 | **分段寻址方案** 350 | 351 | 逻辑地址空间连续，但是物理地址空间不连续，使用映射机制进行关联. 352 | 353 | 一个段 : 一个内存"块" 354 | 355 | 程序访问内存地址需要 : 一个二维的二元组(s, addr) → (段号, 地址) 356 | 357 | 操作系统维护一张段表, 存储(段号, 物理地址中的起始地址, 长度限制) 358 | 359 | 物理地址 : 段表中的起始地址 + 二元组中的偏移地址 360 | 361 | ### 分页(Paging) 362 | 363 | #### 分页地址空间 364 | 365 | 划分物理内存至固定大小的帧(Frame) 366 | 367 | - 大小是2的幂, 512 / 4096 / 8192 368 | 369 | 划分逻辑地址空间至相同大小的页(Page) 370 | 371 | - 大小是2的幂, 512 / 4096 / 8192 372 | 373 | 建立方案 → 转换逻辑地址为物理地址(pages to frames) 374 | 375 | - 页表 376 | - MMU / TLB 377 | 378 | **帧(Frame)** 379 | 380 | 物理内存被分割为大小相等的帧. 一个内存物理地址是一个二元组(f, o) → (帧号, 帧内偏移) 381 | 382 | 帧号 : F位, 共有2^F个帧 383 | 384 | 帧内偏移 : S位, 每帧有2^S个字节 385 | 386 | 物理地址 = 2^S * f + o 387 | 388 | (例子 : 16-bit地址空间, 9-bit(512 byte) 大小的页帧 物理地址 = (3,6) 物理地址 = 2^9 * 3 + 6 = 1542) 389 | 390 | > 分页和分段的最大区别 : 这里的 S 是一个固定的数, 而分段中的长度限制不定 391 | 392 | **页(Page)** 393 | 394 | 一个程序的逻辑地址空间被划分为大小相等的页. 页内偏移的大小 = 帧内偏移的大小 页号大小 <> 帧号大小 395 | 396 | 一个逻辑地址是一个二元组(p, o) → (页号, 页内偏移) 397 | 398 | 页号 : P位, 共有2^P个页 399 | 400 | 页内偏移 : S位, 每页有2^S个字节 401 | 402 | 虚拟地址 = 2^S * p + o 403 | 404 | #### 页寻址方案 405 | 406 | 操作系统维护一张页表, 页表保存了逻辑地址——物理地址之间的映射关系 407 | 408 | 存储 : (页号, 帧号) 409 | 410 | - 逻辑地址空间应当大于物理内存空间 411 | - 页映射到帧 412 | - 页是连续的虚拟内存 413 | - 帧是非连续的物理内存(有助于减少碎片的产生) 414 | - 不是所有的页都有对应的帧 415 | 416 | ### 页表(Page Table) 417 | 418 | #### 页表概述 419 | 420 | 每一个运行的程序都有一个页表 421 | 422 | - 属于程序运行状态, 会动态变化 423 | - PTBR : 页表基址寄存器 424 | 425 | **转换流程** 426 | 427 | CPU根据程序的page的页号的若干位, 计算出索引值index, 在页表中搜索这个index, 得到的是帧号, 帧号和原本的offset组成物理地址. 428 | 429 | 页表中还有一些特殊标志位 430 | 431 | - dirty bit, 432 | - resident bit, (0 : 对应的物理页帧在内存中不存在 ; 1 : 存在) 433 | - clock / reference bit 434 | 435 | **转换实例** 436 | 437 | 16位地址的系统 438 | 439 | - 32KB的物理内存 440 | - 每页的 1024 byte 441 | 442 | 逻辑地址空间 : (4, 0) ... (3, 1023) 443 | 444 | 页表 : 445 | 446 | Flags | Frame nums 447 | 448 | 1 0 1 0 0 0 0 0 → 内存访问异常(可能要杀死程序) 449 | 450 | 0 1 1 0 0 1 0 0 → 页帧是4 偏移是 1023 → 物理地址 (4, 1023) 451 | 452 | #### 分页机制的性能问题 453 | 454 | 访问一个内存单元需要2次内存访问 455 | 456 | - 一次用于获取页表项 457 | - 一次用于访问数据 458 | 459 | 页表可能非常大 460 | 461 | - 64位机器如果每页1024字节, 那么一个页表的大小会是多少？(2^64 / 2^10 = 2^54 存放不下) 462 | - 每一个运行的程序都需要有一个页表 463 | 464 | 如何处理？ 465 | 466 | - 缓存(Caching) 467 | - 间接(Indirection)访问 468 | 469 | #### 转换后备缓冲区(TLB) 470 | 471 | 缓解时间问题 472 | 473 | Translation Look-aside Buffer(TLB) 是一个缓冲区. CPU中有快表TLB(可以将经常访问的页表存放在这边) 474 | 475 | 缓存近期访问的页帧转换表项 476 | 477 | - TLB使用关联内存实现, 具备快速访问性能 478 | - 如果TLB命中, 物理页号可以很快被获取 479 | - 如果TLB未命中, 对应的表项被更新到TLB中(x86的CPU由硬件实现, 其他的可能是由操作系统实现) 480 | 481 | #### 二级/多级页表 482 | 483 | 时间换空间 484 | 485 | 二级页表 486 | 487 | - 将页号分为两个部分, 页表分为两个, 一级页号对应一级页表, 二级页号对应二级页表. 488 | - 一级页号查表获得在二级页表的起始地址, 地址加上二级页号的值, 在二级页表中获得帧号 489 | - 节约了一定的空间, 在一级页表中如果resident bit = 0, 可以使得在二级页表中不存储相关index,而只有一张页表的话, 这一些index都需要保留 490 | 491 | 多级页表 492 | 493 | - 通过把页号分为k个部分, 来实现多级间接页表, 建立一棵页表"树" 494 | 495 | #### 反向页表 496 | 497 | 解决大地址空间问题 498 | 499 | 目的 : 根据帧号获得页号 500 | 501 | 反向页表只需要存在一张即可 502 | 503 | - 有大地址空间(64-bits), 前向映射页表变得繁琐. 比如 : 使用了5级页表 504 | - 不是让页表与逻辑地址空间的大小相对应, 而是当页表与物理地址空间的大小相对应. 逻辑地址空间增长速度快于物理地址空间 505 | 506 | ##### 基于页寄存器(Page Registers)的方案 507 | 508 | 存储 (帧号, 页号) 使得表大小与物理内存大小相关, 而与逻辑内存关联减小. 509 | 510 | 每一个帧和一个寄存器关联, 寄存器内容包括 : 511 | 512 | - resident bit : 此帧是否被占用 513 | - occupier : 对应的页号 p 514 | - protection bits : 保护位 515 | 516 | 实例 : 517 | 518 | - 物理内存大小是 : 4096 * 4096 = 4K * 4KB = 16 MB 519 | - 页面大小是 : 4096 bytes = 4 KB 520 | - 页帧数 : 4096 = 4 K 521 | - 页寄存器使用的空间(假设8 bytes / register) : 8 * 4096 = 32 Kbytes 522 | - 页寄存器带来的额外开销 : 32K / 16M = 0.2% 523 | - 虚拟内存大小 : 任意 524 | 525 | 优势 : 526 | 527 | - 转换表的大小相对于物理内存来说很小 528 | - 转换表的大小跟逻辑地址空间的大小无关 529 | 530 | 劣势 : 531 | 532 | - 需要的信息对调了, 即根据帧号可以找到页号 533 | - 如何转换回来? (如何根据页号找到帧号) 534 | - 在需要在反向页表中搜索想要的页号 535 | 536 | ##### 基于关联内存(associative memory)的方案 537 | 538 | 硬件设计复杂, 容量不大, 需要放置在CPU中 539 | 540 | - 如果帧数较少, 页寄存器可以被放置在关联内存中 541 | - 在关联内存中查找逻辑页号 542 | - 成功 : 帧号被提取 543 | - 失败 : 页错误异常 (page fault) 544 | - 限制因素: 545 | - 大量的关联内存非常昂贵(难以在单个时钟周期内完成 ; 耗电) 546 | 547 | ##### 基于哈希(hash)的方案 548 | 549 | 哈希函数 : h(PID, p) 从 PID 标号获得页号 550 | 551 | 在反向页表中通过哈希算法来搜索一个页对应的帧号 552 | 553 | - 对页号做哈希计算, 为了在帧表中获取对应的帧号 554 | - 页 i 被放置在表 f(i) 位置, 其中 f 是设定的哈希函数 555 | - 为了查找页 i , 执行下列操作 : 556 | - 计算哈希函数 f(i) 并且使用它作为页寄存器表的索引, 获取对应的页寄存器 557 | - 检查寄存器标签是否包含 i, 如果包含, 则代表成功, 否则失败 558 | 559 | 560 | 561 | # 第五章 562 | 563 | > 第五章的主要内容是：操作系统的虚拟内存管理技术 564 | 565 | ## 虚拟内存的起因 566 | 567 | 使用硬盘/磁盘使更多的程序在有限的内存中运行 568 | 569 | 理想的存储器 : 更大更快更便宜和非易失性的存储区 570 | 571 | ## 覆盖技术 572 | 573 | 如果是程序太大, 超出了内存的容量, 可以采用手动的概率(overlay)技术, 只把需要的指令和数据保存在内存当中 574 | 575 | 目的 : 是在较小的可用内存中运行较大的程序, 常用于多道程序系统, 与分区存储管理配合使用. 576 | 577 | 原理 : 578 | 579 | 把程序按照其自身逻辑结构, 划分为若干个功能上相互独立的程序模块, 那些不会同时执行的模块共享同一块内存区域, 按时间先后来运行. 580 | 581 | - 必要部分(常用功能)的代码和数据常驻内存; 582 | - 可选部分(不常用功能)在其他程序模块中实现, 平时存放在外存中, 在需要用到时才装入内存; 583 | - 不存在调用关系的模块不必同时装入到内存, 从而可以相互覆盖, 即这些模块共用一个分区. 584 | 585 | > 也就是说,程序松耦合的部分可以按需装入内存,不需要的时候放在外存中,多个不常用部分共用一个分区. 586 | 587 | 实例 : 588 | 589 | A(20k) ____B(50k) ____ D(30k) 590 | | ____ C(30k) ____ E(20k) 591 | |____ F(40k) 592 | 593 | 因此不需要将整个程序190k的数据全部放入内存中, 而是划分为 常驻区(20k) 覆盖区0(50k) 覆盖区1(40k) 压缩至了110k的内存空间使用 594 | 595 | 缺点 : 596 | 597 | - 由程序员来把一个大的程序划分为若干个小的功能模块, 并确定各个模块之间的覆盖关系, 费时费力, 增加了编程的复杂度; 598 | - 覆盖模块并从外存装入内存, 实际上是以时间延长来换取空间节省. 599 | 600 | ## 交换技术 601 | 602 | 如果是程序太多, 超过了内存的容量, 可以采用自动的交换(swapping)技术, 把暂时不能执行的程序送到外存中 603 | 604 | 目的 : 多道程序在内存时, 让正在运行的程序或需要运行的程序获得更多的内存资源 605 | 606 | 原理 : 607 | 608 | 可将暂时不能运行的程序送到外存, 从而获得空闲内存空间. 操作系统把一个进程的整个地址空间的内容保存到外存中(换出 swap out), 而将外存中的某个进程的地址空间读入到内存中(换入 swap in). 换入换出内容的大小为整个程序的地址空间. 609 | 610 | 存在问题 : 611 | 612 | - 交换时机的确定 : 何时需要发生交换? 只当内存空间不够或有不够的危险时换出; 613 | - 交换区的大小 : 必须足够大以存放所有用户进程的所有内存映像的拷贝, 必须能够对这些内存映像进行直接存取 614 | - 程序换入时的重定位 : 换出后再换入的内存位置一定要在原来的位置上嘛?(可能出现寻址问题) 最好采用动态地址映射的方法 615 | 616 | ## 覆盖技术和交换技术的对比 617 | 618 | 特点 : 619 | 620 | - 覆盖只能发生在那些相互之间没有调用关系的程序模块之间, 因此程序员必须给出程序内的各个模块之间的逻辑覆盖结构. 621 | - 交换技术是以在内存中的程序大小为单位进行的, 它不需要程序员给出各个模块之间的逻辑覆盖结构. 622 | - 换言之, 交换发生在内存中程序与管理程序或操作系统之间, 而覆盖则发生在运行程序的内部. 623 | 624 | 在内存不够用的情形下, 可以采用覆盖技术和交换技术, 但是 : 625 | 626 | - 覆盖技术 : 需要程序要自己把整个程序划分为若干个小的功能模块, 并确定各个模块之间的覆盖关系, 增加了程序员的负担. 627 | - 交换技术 : 以进程作为交换的单位, 需要把进程的整个地址空间都换入换出, 增加了处理器的开销. 628 | 629 | ## 虚拟内存管理技术 630 | 631 | 如果想要在有限容量的内存中, 以更小的页粒度为单位装入更多更大的程序, 可以采用自动的虚拟存储技术 632 | 633 | - 目标 634 | 635 | 像覆盖技术那样, 不是把程序的所有内容都放在内存中, 因而能够运行比当前的空闲内存空间还要大的程序. 但做的更好, 由操作系统自动来完成, 无需程序员的干涉. 636 | 637 | 像交换技术那样, 能够实现进程在内存与外存之间的交换, 因而获得更多的空闲内存空间. 但做的更好, 只对进程的部分内容在内存和外存之间进行交换. 638 | 639 | - 程序局部性原理 640 | 641 | 程序的局部性原理(principle of locality) : 指程序在执行过程中的一个较短时期, 所执行的指令地址和指令的操作数地址, 分别局限于一定的区域. 642 | 643 | - 时间局部性 : 一条指令的一次执行和下次执行, 一个数据的一次访问和下次访问都集中在一个较短时期内 ; 644 | - 空间局部性 : 当前指令和邻近的几条指令, 当前访问的数据和邻近的几个数据都集中在一个较小区域内. 645 | 646 | 程序的局部性原理表明, 从理论上来说, 虚拟存储技术是能够实现的. 而且在实现了以后应该是能够取得一个满意的效果. 647 | 648 | 实例 : 649 | 650 | ```cpp 651 | 题目描述 : 652 | 页面大小为4k, 分配给每个进程的物理页面是1. 653 | 在一个进程中, 定义了如下的二维数组 int A[1024][1024]. 该数组按行存放在内存, 每一行放在一个页面中. 654 | 考虑一下程序的编写方法对缺页率的影响? 655 | 656 | 程序编写方法1 : (发生了1024*1024次缺页中断) 657 | for(j = 0; j < 1024; j++) 658 | for(i = 0; i < 1024; i++) 659 | A[i][j] = 0; 660 | 661 | 程序编写方法2 : (发生了1024次缺页中断) 662 | for(i = 0; i < 1024; i++) 663 | for(j = 0; j < 1024; j++) 664 | A[i][j] = 0; 665 | ``` 666 | 667 | - 基本概念 668 | 669 | 可以在页式或段式内存管理的基础上实现 670 | 671 | - 在装入程序时, 不必将其全部装入内存, 而只需将当前需要执行的部分页面或段装入到内存中, 就可以让程序开始执行; 672 | - 在程序执行过程中, 如果需执行的指令或访问的数据尚未在内存中(称为缺页或缺段), 则由处理器通知操作系统将相应的页面或段调入到内存, 然后继续执行程序; 673 | - 另一方面, 操作系统将内存中暂时不使用的页面或段调出保存在外存上, 从而腾出更多空闲内存空间存放将要装入的程序以及将要调入的页面或段. 674 | 675 | - 基本特征 676 | 677 | - 大的用户空间 : 通过把物理内存和外存相结合, 提供给用户的虚拟内存空间通常大于实际的物理内存, 即实现了这两者的分离. 如32位的虚拟地址理论上可以访问4GB, 而可能计算机上仅有256M的物理内存, 但硬盘容量大于4GB. 678 | - 部分交换 : 与交换技术相比较, 虚拟存储的调入和调出是对部分虚拟地址空间进行的; 679 | - 不连续性 : 物理内存分配的不连续性, 虚拟地址空间使用的不连续性. 680 | 681 | - 虚拟页式内存管理 682 | 683 | 页式内存管理 684 | 685 | 页表 : 完成逻辑页到物理页帧的映射 686 | 687 | 根据页号去页表中寻找索引, 先查看 resident bit 是否为0, 0表示不存在, 1表示映射关系存在, 获得帧号加上原本的偏移, 获得了物理地址. 688 | 689 | 虚拟页式内存管理 690 | 691 | - 大部分虚拟存储系统都采用虚拟页式存储管理技术, 即在页式存储管理的基础上, 增加请求调页和页面置换功能. 692 | 693 | - 基本思路 694 | 695 | - 当一个用户程序要调入内存运行时, 不是将该程序的所有页面都装入内存, 而是只装入部分的页面, 就可启动程序运行. 696 | - 在运行的过程中, 如果发现要运行的程序或要访问的数据不再内存, 则向系统发出缺页的中断请求, 系统在处理这个中断时, 将外存中相应的页面调入内存, 使得该程序能够继续运行. 697 | 698 | - 页表表项 699 | 700 | 逻辑页号 | 访问位 | 修改位 | 保护位 | 驻留位 | 物理页帧号 701 | 702 | 驻留位 : 表示该页是在内存中还是在外存. 703 | 704 | 保护位 : 表示允许对该页做何种类型的访问, 如只读, 可读写, 可执行等 705 | 706 | 修改位 : 表示此页在内存中是否被修改过. 当系统回收该物理页面时, 根据此位来决定是否把它的内容写回外存 707 | 708 | 访问位 : 如果该页被访问过(包括读写操作), 则设置此位. 用于页面置换算法. 709 | 710 | - 缺页中断处理过程 : 711 | 712 | 1. 如果在内存中有空闲的物理页面, 则分配一物理页帧f, 然后转第4步; 否则转到第2步; 713 | 2. 采用某种页面置换算法, 选择一个将被替换的物理页帧f, 它所对应的逻辑页为q, 如果该页在内存期间被修改过, 则需要把它写回外存; 714 | 3. 对q所对应的页表项修改, 把驻留位置为0; 715 | 4. 将需要访问的页p装入到物理页面f当中; 716 | 5. 修改p所对应的页表项的内容, 把驻留位置为1, 把物理页帧号置为f; 717 | 6. 重新运行被中断是指令. 718 | 719 | > 在何处保存未被映射的页? 720 | > 721 | > - 能够简单地识别在二级存储器中的页 722 | > - 交换空间(磁盘或者文件) : 特殊格式, 用于存储未被映射的页面 723 | 724 | 后备存储(二级存储) : 725 | 726 | - 一个虚拟地址空间的页面可以被映射到一个文件(在二级存储中)的某个位置 727 | - 代码段 : 映射到可执行二进制文件 728 | - 动态加载的共享库程序段 : 映射到动态调用的库文件 729 | - 其他段 : 可能被映射到交换文件(swap file) 730 | 731 | - 虚拟内存性能 732 | 733 | 为了便于理解分页的开销, 使用有效存储器访问时间 effective memory access time (EAT) 734 | 735 | EAT = 访存时间 * 页表命中几率 + page fault处理时间 * page fault几率 736 | 737 | 实例 : 738 | 739 | 访存时间 : 10 ns 740 | 741 | 磁盘访问时间 : 5 ms 742 | 743 | 参数 p = page fault 几率 744 | 745 | 参数 q = dirty page 几率(对页面写操作) 746 | 747 | EAT = 10\*(1-p) + 5000000\*p\*(1+q) 748 | 749 | 750 | 751 | # 第六章 752 | 753 | > 第六章的主要内容是：操作系统的虚拟内存管理技术中的页面置换算法 754 | 755 | ## 功能与目标 756 | 757 | 功能 : 当缺页中断发生, 需要调入新的页面而内存已满时, 选择内存当中哪个物理页面被置换. 758 | 759 | 目标 : 尽可能地减少页面的换进换出次数(即缺页中断的次数). 具体来说, 把未来不再使用的或短期内较少使用的页面换出, 通常只能在局部性原理指导下依据过去的统计数据来进行预测. 760 | 761 | 页面锁定 : 用于描述必须常驻内存的操作系统的关键部分或时间关键的应用进程. 实现的方式是 : 在页表中添加锁定标记位(lock bit). 762 | 763 | ## 实验设置与评价方法 764 | 765 | 实例 : 766 | 767 | 记录一个进程对页访问的一个轨迹 768 | 769 | - 举例 : 虚拟地址跟踪(页号, 偏移)... 770 | - (3,0) (1,9) (4,1) (2,1) (5,3) (2,0) ... 771 | - 生成的页面轨迹 772 | - 3, 1, 4, 2, 5, 2, 1, ... 773 | 774 | 模拟一个页面置换的行为并且记录产生页缺失数的数量 775 | 776 | - 更少的缺失, 更好的性能 777 | 778 | ## 局部页面置换算法 779 | 780 | ### 最优页面置换算法 781 | 782 | 基本思路 : 当一个缺页中断发生时, 对于保存在内存当中的每一个逻辑页面, 计算在它的下一次访问之前, 还需等待多长时间, 从中选择等待时间最长的那个, 作为被置换的页面. 783 | 784 | 这是一种理想情况, 在实际系统中是无法实现的, 因为操作系统无法知道每一个页面要等待多长时间以后才会再次被访问. 785 | 786 | 可用作其他算法的性能评价的依据.(在一个模拟器上运行某个程序, 并记录每一次的页面访问情况, 在第二遍运行时即可使用最优算法) 787 | 788 | ### 先进先出算法 789 | 790 | 基本思路 : 选择在内存中驻留时间最长的页面淘汰. 具体来说, 系统维护着一个链表, 记录了所有位于内存当中的逻辑页面. 从链表的排列顺序来看, 链首页面的驻留时间最长, 链尾页面的驻留时间最短. 当发生一个缺页中断时, 把链首页面淘汰出去, 并把新的页面添加到链表的末尾. 791 | 792 | 性能较差, 调出的页面有可能是经常要访问的页面. 并且有 belady现象. FIFO算法很少单独使用. 793 | 794 | ### 最近最久未使用算法 795 | 796 | LRU(Least Recently Used) 797 | 798 | 基本思路 : 当一个缺页中断发生时, 选择最久未使用的那个页面, 并淘汰. 799 | 800 | 它是对最优页面置换算法的一个近似, 其依据是程序的局部性原理, 即在最近一小段时间(最近几条指令)内, 如果某些页面被频繁地访问, 那么再将来的一小段时间内, 他们还可能会再一次被频繁地访问. 反过来说, 如果过去某些页面长时间未被访问, 那么在将来它们还可能会长时间地得不到访问. 801 | 802 | LRU算法需要记录各个页面使用时间的先后顺序, 开销比较大. 803 | 804 | 两种可能的实现方法是 : 805 | 806 | - 系统维护一个页面链表, 最近刚刚使用过的页面作为首节点, 最久未使用的作为尾结点. 再一次访问内存时, 找出相应的页面, 把它从链表中摘下来, 再移动到链表首. 每次缺页中断发生时, 淘汰链表末尾的页面. 807 | - 设置一个活动页面栈, 当访问某页时, 将此页号压入栈顶, 然后, 考察栈内是否有与此页面相同的页号, 若有则抽出. 当需要淘汰一个页面时, 总是选择栈底的页面, 它就是最久未使用的. 808 | 809 | ### 时钟页面置换算法 810 | 811 | 基本思路 : 812 | 813 | 需要用到页表项的访问位, 当一个页面被装入内存时, 把该位初始化为0. 然后如果这个页面被访问, 则把该位置设为1; 814 | 815 | 把各个页面组织成环形链表(类似钟表面), 把指针指向最老的页面(最先进来); 816 | 817 | 当发生一个缺页中断时, 考察指针所指向的最老页面, 若它的访问位为0, 立即淘汰; 若访问位为0, 然后指针往下移动一格. 如此下去, 直到找到被淘汰的页面, 然后把指针移动到下一格. 818 | 819 | 流程 : 820 | 821 | 如果访问页在物理内存中, 访问位置1. 822 | 823 | 如果不在物理页, 从指针当前指向的物理页开始, 如果访问位0, 替换当前页, 指针指向下一个物理页; 如果访问位为1, 置零以后访问下一个物理页再进行判断. 如果所有物理页的访问位都被清零了, 又回到了第一次指针所指向的物理页进行替换. 824 | 825 | ### 二次机会算法 826 | 827 | 因为考虑到时钟页面置换算法, 有时候会把一些 dirty bit 为1(有过写操作)的页面进行置换, 这样的话, 代价会比较大. 因此, 可以结合访问位和脏位一起来决定应该置换哪一页. 828 | 829 | used dirty → used dirty 830 | 831 | 0 0 replace 832 | 833 | 0 1 0 0 834 | 835 | 1 0 0 0 836 | 837 | 1 1 0 1 838 | 839 | 相当于说, 替换的优先级, 没有读写也没写过, 那么直接走, 如果写过或者访问过, 那么给你一次机会, 如果又写过, 又访问过, 那么久给你两次机会. 840 | 841 | ### 最不常用算法 842 | 843 | Least Frequently used, LFU 844 | 845 | 基本思路 : 当一个缺页中断发生时, 选择访问次数最少的那个页面, 并淘汰. 846 | 847 | 实现方法 : 对每一个页面设置一个访问计数器, 每当一个页面被访问时, 该页面的访问计数器加1. 当发生缺页中断时, 淘汰计数值最小的那个页面. 848 | 849 | LRU和LFU的对比 : LRU考察的是多久未访问, 时间越短越好. 而LFU考察的是访问的次数和频度, 访问次数越多越好. 850 | 851 | ### Belady现象(科学家名字) 852 | 853 | 在采用FIFO算法时, 有时会出现分配的物理页面数增加, 缺页率反而提高的异常现象; 854 | 855 | 出现原因 : FIFO算法的置换特征与进程访问内存的动态特征是矛盾的, 与置换算法的目标是不一致的(即替换较少使用的页面), 因此, 被他置换出去的页面不一定是进程不会访问的. 856 | 857 | ### LRU / FIFO 和 Clock 的比较 858 | 859 | LRU和FIFO都是先进先出的思路, 只不过LRU是针对页面最近访问时间来进行排序, 所以需要在每一次页面访问的时候动态地调整各个页面之间的先后顺序(有一个页面的最近访问时间变了). 而FIFO是针对页面进入内存的时间来进行排序, 这个时间是固定不变的, 所以各个页面之间的先后顺序是固定的. 如果一个页面在进入内存后没有被访问, 那么它的最近访问时间就是它进入内存的时间. 换句话说, 如果内存当中的所有页面都未曾访问过, 那么LRU算法就退化为了FIFO算法. 860 | 861 | 例如 : 给进程分配3个物理页面, 逻辑页面的访问顺序是 : 1,2,3,4,5,6,1,2,3 ... 862 | 863 | ## 全局页面置换算法 864 | 865 | ### 工作集模型 866 | 867 | 前面介绍的各种页面置换算法, 都是基于一个前提, 即程序的局部性原理. 但是此原理是否成立? 868 | 869 | - 如果局部性原理不成立, 那么各种页面置换算法就没有说明分别, 也没有什么意义. 例如 : 假设进程对逻辑页面的访问顺序是1,2,3,4,5,6,6,7,8,9..., 即单调递增, 那么在物理页面数有限的前提下, 不管采用何种置换算法, 每次的页面访问都必然导致缺页中断. 870 | - 如果局部性原理是成立的, 那么如何来证明它的存在, 如何来对它进行定量地分析? 这就是工作集模型. 871 | 872 | ### 工作集 873 | 874 | 工作集 : 一个进程当前正在使用的逻辑页面集合. 875 | 876 | 可以使用一个二元函数 W(t, delta) 来表示 : 877 | 878 | t 是当前的执行时刻; 879 | 880 | delta 称为工作集窗口, 即一个定长的页面访问的时间窗口; 881 | 882 | W(t, delta) = 在当前时刻 t 之前的 delta 时间窗口当中的所有页面所组成的集合(随着 t 的变化, 该集合也在不断的变化) 883 | 884 | |W(t, delta)| 是工作集的大小, 即逻辑页的数量. 885 | 886 | 工作集大小的变化 : 进程开始执行后, 随着访问新页面逐步建立较稳定的工作集. 当内存访问的局部性区域的位置大致稳定时, 工作集大小也大致稳定; 局部性区域的位置改变时, 工作集快速扩张和收缩过渡到下一个稳定值. 887 | 888 | ### 常驻集 889 | 890 | 常驻集是指在当前时刻, 进程实际驻留在内存当中的页面集合. 891 | 892 | - 工作集是进程在运行过程中固有的性质, 而常驻集取决于系统分配给进程的物理页面数目, 以及所采用的页面置换算法; 893 | - 如果一个进程的整个工作集都在内存当中, 即常驻集 包含 工作集, 那么进程将很顺利地运行, 而不会造成太多的缺页中断(直到工作集发生剧烈变动, 从而过渡到另一个状态); 894 | - 当进程常驻集的大小达到某个数目之后, 再给它分配更多的物理页面, 缺页率也不会明显下降. 895 | 896 | ### 工作集页置换算法 897 | 898 | 当工作集窗口在滑动过程中, 如果页面不在集合中, 那么就会直接丢失这个不在窗口中页面, 而不会等待缺页中断再丢弃. 899 | 900 | ### 缺页率置换算法 901 | 902 | 可变分配策略 : 常驻集大小可变. 例如 : 每个进程在刚开始运行的时候, 先根据程序大小给它分配一定数目的物理页面, 然后在进程运行过程中, 再动态地调整常驻集的大小. 903 | 904 | - 可采用全局页面置换的方式, 当发生一个缺页中断时, 被置换的页面可以是在其他进程当中, 各个并发进程竞争地使用物理页面. 905 | - 优缺点 : 性能较好, 但增加了系统开销. 906 | - 具体实现 : 可以使用缺页率算法来动态调整常驻集的大小. 907 | 908 | 缺页率 : 表示 "缺页次数 / 内存访问次数" 909 | 910 | 影响因素 : 页面置换算法, 分配给进程的物理页面数目, 页面本身的大小, 程序的编写方法. 911 | 912 | ### 抖动问题 913 | 914 | - 如果分配给一个进程的物理页面太少, 不能包含整个的工作集, 即常驻集 属于 工作集, 那么进程将会造成很多的缺页中断, 需要频繁的在内存与外存之间替换页面, 从而使进程的运行速度变得很慢, 我们把这种状态称为 "抖动". 915 | - 产生抖动的原因 : 随着驻留内存的进程数目增加, 分配给每个进程的物理页面数不断就减小, 缺页率不断上升. 所以OS要选择一个适当的进程数目和进程需要的帧数, 以便在并发水平和缺页率之间达到一个平衡. 916 | 917 | 918 | 919 | # 第七章 920 | 921 | > 第七章的主要内容是：进程 922 | 923 | ## 进程(process)描述 924 | 925 | ### 进程定义 926 | 927 | 进程 : 一个具有一定独立功能的程序在一个数据集合上的一次动态执行过程. 928 | 929 | ### 进程的组成 930 | 931 | 进程包括 : 932 | 933 | - 程序的代码 934 | - 程序处理的数据 935 | - 程序计数器中的值, 指示下一条将运行的指令 936 | - 一组通用的寄存器的当前值, 堆, 栈 937 | - 一组系统资源(如打开的文件) 938 | 939 | 进程和程序的联系 : 940 | 941 | - 程序是产生进程的基础 942 | - 程序的每次运行构成不同的进程 943 | - 进程是程序功能的体现 944 | - 通过多次执行, 一个程序可以对应多个进程, 通过调用关系, 一个进程可包括多个程序. 945 | 946 | 进程和程序的区别 : 947 | 948 | - 进程是动态的, 程序是静态的 : 程序是有序代码的集合. 进程是程序的执行, 进程有核心态 / 用户态. 949 | - 进程是暂时的, 程序是永久的. 进程是一个状态变化的过程, 程序可以长久保存. 950 | - 进程和程序的组成不同 : 进程的组成包括程序, 数据和进程控制块(进程状态信息) 951 | 952 | ### 进程的特点 953 | 954 | **动态性** : 可动态地创建, 结果进程; 955 | 956 | **并发性** : 进程可以被独立调度并占用处理机运行; (并发:一段, 并行:一时刻) 957 | 958 | **独立性** : 不同进程的工作不相互影响;(页表是保障措施之一) 959 | 960 | **制约性** : 因访问共享数据, 资源或进程间同步而产生制约. 961 | 962 | > 抛出了一个问题 : 如果你要设计一个OS, 怎么样来实现其中的进程管理机制? 963 | 964 | ### 进程控制结构 965 | 966 | 描述进程的数据结构 : 进程控制块 (Process Control Block) 967 | 968 | 操作系统为每个进程都维护了一个PCB, 用来保存与该进程有关的各种状态信息. 969 | 970 | **进程控制块 :** 操作系统管理控制进程运行所用的信息集合. 971 | 972 | 进程的创建 : 为该进程生成一个PCB 973 | 974 | **进程的终止 :** 回收它的PCB 975 | 976 | **进程的组织管理 :** 通过对PCB的组织管理来实现 977 | 978 | (PCB具体包含什么信息? 如何组织的? 进程的状态转换?) 979 | 980 | **PCB有以下三大类信息 :** 981 | 982 | - 进程标志信息. 如本进程的标志, 本进程的产生者标志(父进程标志). 用户标志 983 | - 处理机状态信息保存区 : 保存进程的运行现场信息 : 984 | - 用户可见寄存器. 用户程序可以使用的数据, 地址等寄存器 985 | - 控制和状态寄存器. 如程序计数器(PC), 程序状态字(PSW) 986 | - 栈指针. 过程调用, 系统调用, 中断处理和返回时需要用到它 987 | - 进程控制信息 988 | - 调度和状态信息. 用于操作系统调度进程并占用处理机使用. 989 | - 进程间通信信息. 为支持进程间与通信相关的各种标志, 信号, 信件等, 这些信息都存在接收方的进程控制块中. 990 | - 存储管理信息. 包含有指向本进程映像存储空间的数据结构. 991 | - 进程所用资源. 说明由进程打开, 使用的系统资源. 如打开的文件等. 992 | - 有关数据结构的链接信息. 进程可以连接到一个进程队列中, 或连接到相关的其他进程的PCB. 993 | 994 | **进程的组织方式** 995 | 996 | 链表 : 同一状态的进程其PCB成一链表, 多个状态对应多个不同的链表.(各状态的进程形成不同的链表 : 就绪链表, 阻塞链表) 997 | 998 | 索引表 : 同一状态的进程归入一个index表(由index指向PCB), 多个状态对应多个不同的index表(各状态的进行形成不同的索引表 : 就绪索引表, 阻塞索引表) 999 | 1000 | ## 进程状态(state) 1001 | 1002 | ### 进程的生命期管理 1003 | 1004 | #### 进程创建 1005 | 1006 | 引起进程创建的3个主要事件 : 1007 | 1008 | - 系统初始化; 1009 | - 用户请求创建一个新进程; 1010 | - 正在运行的进程执行了创建进程的系统调用. 1011 | 1012 | #### 进程运行 1013 | 1014 | 内核选择一个就绪的进程, 让它占用处理机并执行 1015 | 1016 | (为何选择?如何选择?) 1017 | 1018 | #### 进程等待(阻塞) 1019 | 1020 | 在以下情况下, 进程等待(阻塞): 1021 | 1022 | 1. 请求并等待系统服务, 无法马上完成 1023 | 2. 启动某种操作, 无法马上完成 1024 | 3. 需要的数据没有到达 1025 | 1026 | 进程只能自己阻塞自己, 因为只有进程自身才能知道何时需要等待某种事件的发生. 1027 | 1028 | #### 进程唤醒 1029 | 1030 | 唤醒进程的原因 : 1031 | 1032 | 1. 被阻塞进程需要的资源可被满足 1033 | 2. 被阻塞进程等待的事件到达 1034 | 3. 将该进程的PCB插入到就绪队列 1035 | 1036 | 进程只能被别的进程或操作系统唤醒 1037 | 1038 | #### 进程结束 1039 | 1040 | 在以下四种情况下, 进程结束 : 1041 | 1042 | - 正常退出(自愿) 1043 | - 错误退出(自愿) 1044 | - 致命错误(强制性) 1045 | - 被其他进程杀死(强制性) 1046 | 1047 | ### 进程状态变化模型 1048 | 1049 | **进程的三种基本状态 :** 进程在生命结束前处于三种基本状态之一. 1050 | 1051 | 不同系统设置的进程状态数目不同. 1052 | 1053 | **三种基本状态** 1054 | 1055 | 1. 运行状态(Running) : 当一个进程正在处理机上运行时 1056 | 2. 就绪状态(Ready) : 一个进程获得了除处理机之外的一切所需资源, 一旦得到处理机即可运行 1057 | 3. 等待状态(阻塞状态 Blocked) : 一个进程正在等待某一时间而暂停运行时. 如等待某资源, 等待输入/输出完成. 1058 | 1059 | **进程其它的基本状态** 1060 | 1061 | 创建状态(New) : 一个进程正在被创建, 还没被转到就绪状态之前的状态 1062 | 1063 | 结束状态(Exit): 一个进程正在从系统中消失时的状态, 这是因为进程结束或由于其它原因所导致. 1064 | 1065 | **可能的状态变化如下 :** 1066 | 1067 | NULL → New : 一个新进程被产生出来执行一个程序 1068 | 1069 | New → Ready: 当进程创建完成并初始化后, 一切就绪准备运行时, 变为就绪状态 1070 | 1071 | Ready → Running : 处于就绪态的进程被进程调度程序选中后, 就分配到处理机上来运行 1072 | 1073 | Running → Exit : 当进程表示它已经完成或者因出错, 当前运行进程会由操作系统作结束处理 1074 | 1075 | Running → Ready : 处于运行状态的进程在其运行过程中, 由于分配它的处理机时间片用完而让出处理机 1076 | 1077 | Running → Blocked: 当进程请求某样东西且必须等待时 1078 | 1079 | Blocked → Ready : 当进程要等待某事件到来时, 它从阻塞状态变到就绪状态 1080 | 1081 | ### 进程挂起 1082 | 1083 | 进程挂起, 为了合理且充分地利用系统资源. 1084 | 1085 | 进程在挂起状态时, 意味着进程没有占用内存空间, 处在挂起状态的进程映像在磁盘上.(把进程放到磁盘上) 1086 | 1087 | **两种挂起状态** 1088 | 1089 | 1. 阻塞挂起状态 : 进程在外存并等待某事件的出现; 1090 | 2. 就绪挂起状态 : 进程在外存, 但只要进入内存, 即可运行. 1091 | 1092 | **与挂起相关的状态转换** 1093 | 1094 | **挂起 :** 把一个进程从内存转到外存, 可能有以下几种情况 : 1095 | 1096 | - 阻塞到阻塞挂起 : 没有进程处于就绪状态或就绪进程要求更多内存资源时, 会进行这种转换, 以提交新进程或运行时就绪进程. 1097 | - 就绪到就绪挂起 : 当有高优先级阻塞(系统认为会很快就绪的)进程和低优先级就绪进程时, 系统会选择挂起低优先级就绪进程. 1098 | - 运行到就绪挂起 : 对抢先式分时系统, 当有高优先级阻塞挂起进程因事件出现而进入就绪挂起时, 系统可能会把运行进程转导就绪挂起状态. 1099 | 1100 | **在外存时的状态转换 :** 1101 | 1102 | - 阻塞挂起到就绪挂起 : 当有阻塞挂起因相关事件出现时, 系统会把阻塞挂起进程转换为就绪挂起进程. 1103 | 1104 | **解挂, 激活 :** 把一个进程从外存转到内存; 可能有以下几种情况 : 1105 | 1106 | - 就绪挂起到就绪 : 没有就绪进程或挂起就绪进程优先级高于就绪进程时, 会进行这种转换. 1107 | - 阻塞挂起到阻塞 : 当一个进程释放足够内存时, 系统会把一个高优先级阻塞挂起(系统认为会很快出现所等待的事件)进程转换为阻塞进程. 1108 | 1109 | > 抛出一个问题 : OS怎么通过PCB和定义的进程状态来管理PCB, 帮助完成进程的调度过程? 1110 | 1111 | ### 状态队列 1112 | 1113 | - 由操作系统来维护一组队列, 用来表示系统当中所有进程的当前状态; 1114 | - 不同的状态分别用不同的队列来表示(就绪队列, 各种类型的阻塞队列); 1115 | - 每个进程的PCB都根据它的状态加入到相应的队列当中, 当一个进程的状态发生变化时, 它的PCB从一个状态中脱离出来, 加入到另外一个队列. 1116 | 1117 | ## 线程(thread) 1118 | 1119 | ### 为什么使用线程? 1120 | 1121 | 实例 : 编写一个MP3播放软件. 1122 | 1123 | 核心功能 : (1)从MP3音频文件中读取数据; (2)对数据进行解压缩; (3)把解压缩后的音频数据播放出来. 1124 | 1125 | ```cpp 1126 | //单进程方式 1127 | while(1){ 1128 | Read(); 1129 | Decompress(); 1130 | Play(); 1131 | } 1132 | //问题: 播放出来的声音能否连贯? 各个函数之间不是并发执行, 影响资源的使用效率. 1133 | ``` 1134 | 1135 | ```cpp 1136 | //多进程 1137 | //进程1 1138 | while(1){ 1139 | Read(); 1140 | } 1141 | //进程2 1142 | while(1){ 1143 | Decompress(); 1144 | } 1145 | //进程3 1146 | while(1){ 1147 | Play(); 1148 | } 1149 | //问题: 进程之间如何通信,共享数据?另外,维护进程的系统开销较大: 1150 | //创建进程时,分配资源,建立PCB;撤销进程时,回收资源,撤销PCB;进程切换时,保存当前进程的状态信息 1151 | ``` 1152 | 1153 | 因此需要提出一种新的实体, 满足以下特征: 1154 | 1155 | 1. 实体之间可以并发执行; 1156 | 2. 实体之间共享相同的地址空间. 1157 | 1158 | 这实体就是线程. 1159 | 1160 | ### 什么是线程 1161 | 1162 | 线程是进程当中的一条执行流程. 1163 | 1164 | 从两个方面重新理解进程: 1165 | 1166 | 1. 从资源组合的角度: 进程把一组相关的资源组合起来,构成了一个资源平台(环境),包括地址空间(代码段,数据段),打开的文件等各种资源; 1167 | 2. 从运行的角度: 代码在这个资源平台上的一条执行流程(线程). 1168 | 1169 | 线程 = 进程 - 共享资源 1170 | 1171 | ### 线程的优缺点 1172 | 1173 | 线程的优点: 1174 | 1175 | - 一个进程中可以同时存在多个线程; 1176 | - 各个线程之间可以并发地执行; 1177 | - 各个线程之间可以共享地址空间和文件等资源. 1178 | 1179 | 线程的缺点: 1180 | 1181 | - 一个线程崩溃, 会导致其所属进程的所有线程崩溃.(给它了"权限"就得有更高的"责任") 1182 | 1183 | - 线程所需的资源 1184 | 1185 | 不同的线程需要独立的寄存器和堆栈, 共享代码,数据和文件等. 1186 | 1187 | ### 线程和进程的比较 1188 | 1189 | - 进程是资源分配单位, 线程是CPU调度单位; 1190 | - 进程拥有一个完整的资源平台, 而线程只独享必不可少的资源, 如寄存器和栈; 1191 | - 线程同样具有就绪,阻塞和执行三种基本状态,同样具有状态之间的转换关系; 1192 | - 线程能减少并发执行的时间和空间开销: 1193 | - 线程的创建时间比进程短;(直接利用所属进程的一些状态信息) 1194 | - 线程的终止时间比进程短;(不需要考虑把这些状态信息给释放) 1195 | - 同一进程内的线程切换时间比进程短;(同一进程不同线程的切换不需要切换页表) 1196 | - 由于同一进程的各线程之间共享内存和文件资源, 可直接进行不通过内核的通信.(直接通过内存地址读写资源) 1197 | 1198 | ### 线程的实现 1199 | 1200 | 主要有三种线程的实现方式: 1201 | 1202 | - 用户线程 : 在用户空间实现; POSIX Pthreads, Mach C-threads, Solaris threads 1203 | - 内核线程 : 在内核中实现; Windows, Solaris, Linux 1204 | - 轻量级进程: 在内核中实现,支持用户线程; Solaris 1205 | 1206 | **用户线程** 1207 | 1208 | 操作系统只能看到进程, 看不到线程, 线程的TCB在线程库中实现; 1209 | 1210 | 在用户空间实现的线程机制, 它不依赖于操作系统的内核, 由一组用户级的线程库来完成线程的管理, 包括进程的创建,终止,同步和调度等. 1211 | 1212 | - 由于用户线程的维护由相应的进程来完成(通过线程库函数),不需要操作系统内核了解用户进程的存在,可用于不支持线程技术的多进程操作系统; 1213 | - 每个进程都需要它自己私有的线程控制块(TCB)列表,用来跟踪记录它的各个线程的状态信息(PC,栈指针,寄存器),TCB由线程库函数来维护; 1214 | - 用户线程的切换也是由线程库函数来完成,无需用户态/核心态切换,所以速度特别快; 1215 | - 允许每个进程拥有自定义的线程调度算法. 1216 | 1217 | 用户线程的缺点: 1218 | 1219 | - 阻塞性的系统调用如何实现?如果一个线程发起系统调用而阻塞,则整个进程在等待; 1220 | - 当一个线程开始运行时,除非它主动地交出CPU的使用权,否则它所在的进程当中的其他线程将无法运行; 1221 | - 由于时间片分配给进程,所以与其他进程比,在多线程执行时,每个线程得到的时间片较少,执行会较慢. 1222 | 1223 | **内核线程** 1224 | 1225 | 操作系统能够看到进程也可能看到线程,线程在内核中实现; 1226 | 1227 | 内核线程是在操作系统的内核当中实现的一种线程机制,由操作系统的内核来完成线程的创建,终止和管理. 1228 | 1229 | - 在支持内核线程的操作系统中,由内核来维护进程和线程的上下文信息(PCB和TCB); 1230 | - 线程的创建,终止和切换都是通过系统调用,内核函数的方式来进行,由内核来完成,因此系统开销较大; 1231 | - 在一个进程当中,如果某个内核线程发起系统调用而被阻塞,并不会影响其他内核线程的运行; 1232 | - 时间片分配给线程,多线程的进程获得更多CPU时间; 1233 | - Windows NT 和 Windows 2000/XP 支持内核线程. 1234 | 1235 | **轻量级进程** 1236 | 1237 | 它是内核支持的用户线程.一个进程可以有一个或多个轻量化进程,每个量级进程由一个单独的内核线程来支持.(Solaris,Linux) 1238 | 1239 | ## 上下文切换 1240 | 1241 | 停止当前运行进程(从运行状态变成其他状态),并且调度其他进程(转变为运行状态) 1242 | 1243 | - 必须在切换之前存储许多部分的进程上下文 1244 | - 必须能够在之后恢复他们,所以进程不能显示它曾经被暂停过 1245 | - 必须快速(上下文切换时非常频繁) 1246 | 1247 | 需要存储什么上下文? 1248 | 1249 | - 寄存器(PC,SP...),CPU状态等信息 1250 | - 一些时候可能会费时,所以我们应该尽可能避免 1251 | 1252 | 操作系统为活跃进程准备了进程控制块 1253 | 1254 | 操作系统将进程控制块放置在一个合适的队列中 1255 | 1256 | - 就绪队列 1257 | - 等待IO队列(每个设备的队列) 1258 | - 僵尸队列 1259 | 1260 | ## 进程控制 1261 | 1262 | ### 创建进程 1263 | 1264 | fork()的简单实现 1265 | 1266 | - 对子进程分配内存 1267 | - 复制父进程的内存和CPU寄存器到子进程 1268 | - 开销昂贵 1269 | 1270 | 在99%的情况下,我们在调用fork()之后调用exec() 1271 | 1272 | - 在fork()操作中内存复制是没有作用的 1273 | - 子进程将可能关闭打开的文件和连接 1274 | - 开销因此是最高的 1275 | - 为什么不能结合它们在一个调用中(OS/2, windows)? 1276 | 1277 | vfork() 1278 | 1279 | - 一个创建进程的系统调用,不需要创建一个同样的内存映像 1280 | - 一些时候称为轻量级fork() 1281 | - 子进程应该几乎立即调用exec() 1282 | - 现在不再使用如果我们使用 copy on write 技术 1283 | 1284 | ### 加载和执行进程 1285 | 1286 | 系统调用exec()加载程序取代当前运行的进程 1287 | 1288 | exec()调用允许一个进程"加载"一个不同的程序并且在main开始执行(事实上 _start) 1289 | 1290 | 它允许一个进程指定参数的数量(argc)和它字符串参数数组(argv) 1291 | 1292 | 如果调用成功(相同的进程,不同的程序) 1293 | 1294 | 代码,stack,heap重写 1295 | 1296 | ```cpp 1297 | int pid = fork(); //创建子进程 1298 | if(pid == 0) { //子进程 1299 | exec_status = exec("calc", argc, argv0,argv1,...); 1300 | printf("Why would I execute?"); 1301 | } else if(pid > 0) { //父进程 1302 | printf("Whose your daddy?"); 1303 | ... 1304 | child_status = wait(pid); 1305 | } 1306 | ``` 1307 | 1308 | ### 等待和终止进程 1309 | 1310 | wait()系统调用是被父进程用来等待子进程的结束 1311 | 1312 | - 一个子进程向父进程返回一个值,所以父进程必须接受这个值并处理 1313 | - wait()系统调用担任这个要求 1314 | - 它使父进程去睡眠来等待子进程的结束 1315 | - 当一个子进程调用exit()的时候,操作系统解锁父进程,并且将通过exit()传递得到的返回值作为wait调用的一个结果(连同子进程的pid一起)如果这里没有子进程存活,wait()立刻返回 1316 | - 当然,如果这里有为父进程的僵尸等待,wait()立即返回其中一个值(并且解除僵尸状态) 1317 | - 进程结束执行之后,它调用exit() 1318 | - 这个系统调用: 1319 | - 将这程序的"结果"作为一个参数 1320 | - 关闭所有打开的文件,连接等等 1321 | - 释放内存 1322 | - 释放大部分支持进程的操作系统结构 1323 | - 检查是否父进程是存活着的: 1324 | - 如果是的话,它保留结果的值直到父进程需要它;在这种情况里,进程没有真正死亡,但是它进入了僵尸状态 1325 | - 如果没有,它释放所有的数据结构,这个进程死亡 1326 | - 清理所有等待的僵尸进程 1327 | - 进程终止是最终的垃圾收集(资源回收) 1328 | 1329 | 1330 | 1331 | # 第八章 1332 | 1333 | > 第八章的主要内容是：调度算法(感觉清华这门课程前几章比较精彩,后续讲的有点混乱) 1334 | 1335 | ## 背景 1336 | 1337 | ### 上下文切换 1338 | 1339 | - 切换CPU的当前任务, 从一个进程/线程到另一个 1340 | - 保存当前进程/线程在PCB/TCB中的执行上下文(CPU状态) 1341 | - 读取下一个进程/线程的上下文 1342 | 1343 | ### CPU调度 1344 | 1345 | - 从就绪队列中挑选一个进程/线程作为CPU将要运行的下一个进程/线程 1346 | - 调度程序: 挑选进程/线程的内核函数(通过一些调度策略) 1347 | - 什么时候进行调度? 1348 | 1349 | ### 内核运行调度程序的条件(满足一条即可) 1350 | 1351 | - 一个进程从运行状态切换到等待状态 1352 | - 一个进程被终结 1353 | 1354 | ### 不可抢占 1355 | 1356 | - 调度程序必须等待事件结束 1357 | 1358 | ### 可以抢占 1359 | 1360 | - 调度程序在中断被相应后执行 1361 | - 当前的进程从运行切换到就绪, 或者一个进程从等待切换到就绪 1362 | - 当前运行的进程可以被换出 1363 | 1364 | ## 调度原则 1365 | 1366 | - 调度策略 1367 | 1368 | 人们通常都需要"更快"的服务 1369 | 1370 | 什么是更快? 1371 | 1372 | - 传输文件时的高带宽 1373 | - 玩游戏时的低延迟 1374 | - 这两个因素是独立的 1375 | 1376 | 和水管类比 1377 | 1378 | - 低延迟: 喝水的时候想要一打开水龙头水就流出来 1379 | - 高带宽: 给游泳池充水时希望从水龙头里同时流出大量的水,并且不介意是否存在延迟 1380 | 1381 | 我们的目标: 1382 | 1383 | - 减少响应时间: 及时处理用户的输出并且尽快将输出提供给用户 1384 | - 减少平均响应时间的波动: 在交互系统中,可预测性比高差异性低平均更重要 1385 | - 增加吞吐量: 减少开销(操作系统开销,上下文切换);系统资源的高效率用(CPU,IO设备) 1386 | - 减少等待时间: 减少每个进程的等待时间 1387 | 1388 | - 程序执行模型 1389 | 1390 | 执行模型 : 程序在CPU突发和IO中交替 1391 | 1392 | - 每个调度决定都是关于在下一个CPU突发时将哪个工作交给CPU 1393 | - 在时间分片机制下,线程可能在结束当前CPU突发前被迫放弃CPU 1394 | 1395 | - 评价指标 1396 | 1397 | CPU使用率: CPU处于忙状态所占时间的百分比 1398 | 1399 | 吞吐量: 在单位时间内完成的进程数量 1400 | 1401 | 周转时间: 一个进程从初始化到结束,包括所有等待时间所花费的时间 1402 | 1403 | 等待时间: 进程在就绪队列中的总时间 1404 | 1405 | 响应时间: 从一个请求被提交到产生第一次相应所花费的总时间 1406 | 1407 | 各指标在操作系统上的表现: 1408 | 1409 | 低延迟调度增加了交互式表现(如果移动了鼠标,但是屏幕中的光标却没动,我们可能会重启电脑) 1410 | 1411 | 操作系统需要保证低吞吐量不受影响(我想要结束长时间的编程,所以操作系统必须不时进行调度,即使存在许多交互任务) 1412 | 1413 | 吞吐量是操作系统的计算带宽 1414 | 1415 | 响应时间是操作系统的计算延迟 1416 | 1417 | - 公平的目标 1418 | 1419 | 举例: 1420 | 1421 | - 保证每个进程占用相同的CPU时间 1422 | - 这公平嘛?如果一个用户比其他用户运行更多的进程怎么办 1423 | 1424 | 举例: 1425 | 1426 | - 保证每个进程都等待相同的时间 1427 | 1428 | 公平通常会增加平均响应时间 1429 | 1430 | ## 调度算法 1431 | 1432 | - **FCFS(先来先服务)** 1433 | 1434 | First come, First Served 1435 | 1436 | 如果进程在执行中阻塞,队列中的下一个会得到CPU 1437 | 1438 | 优点: 简单 1439 | 1440 | 缺点: 1441 | 1442 | - 平均等待时间波动较大 1443 | - 花费时间少的任务可能排在花费时间长的任务后面 1444 | - 可能导致IO和CPU之间的重叠处理(CPU密集型进程会导致IO设备闲置时,IO密集型进程也在等待) 1445 | 1446 | - **SPN(SJF) SRT(短进程优先(短作业优先)短剩余时间优先)[最优平均等待时间]** 1447 | 1448 | Shortest Process Next(Shortest Job First) Shortest Remaining Time 1449 | 1450 | 选择预测的完成时间来将任务入队 1451 | 1452 | 可以是抢占的或者是不可抢占的 1453 | 1454 | 可能导致饥饿 1455 | 1456 | - 连续的短任务流会使场任务饥饿 1457 | - 短任务可用时的任何场任务的CPU时间都会增加平均等待时间 1458 | 1459 | 需要预测未来 1460 | 1461 | - 怎么预估下一个CPU突发的持续时间 1462 | - 简单的解决: 询问用户 1463 | - 如果用户欺骗就杀死进程 1464 | - 如果不知道怎么办? 1465 | 1466 | - **HRRN(最高响应比优先)** 1467 | 1468 | Highest Response Ratio Next 1469 | 1470 | - **Round Robin(轮循)** 1471 | 1472 | 使用时间切片和抢占来轮流执行任务 1473 | 1474 | 在叫做量子(或者时间切片)的离散单元中分配处理器 1475 | 1476 | 时间片结束时,切换到下一个准备好的进程 1477 | 1478 | 花销: 额外的上下文切换 1479 | 1480 | 时间量子太大: 1481 | 1482 | - 等待时间过长 1483 | - 极限情况退化成FCFS 1484 | 1485 | 时间量子太小: 1486 | 1487 | - 反应迅速 1488 | - 吞吐量由于大量的上下文切换开销受到影响 1489 | 1490 | 目标: 1491 | 1492 | - 选择一个合适的时间量子 1493 | - 经验规则: 维持上下文切换开销处于1%以内 1494 | 1495 | - **Multilevel Feedback Queues(多级反馈队列)** 1496 | 1497 | 优先级队列中的轮循 1498 | 1499 | 就绪队列被划分成独立的队列: 比如前台(交互),后台(批处理) 1500 | 1501 | 每个队列拥有自己的调度策略: 比如前台(RR),后台(FCFS) 1502 | 1503 | 调度必须在队列间进行: 1504 | 1505 | - 固定优先级: 先处理前台,然后处理后台;可能导致饥饿 1506 | - 时间切片: 每个队列都得到一个确定的能够调度其进程的CPU总时间;比如80%使用RR的前台,20%使用FCFS的后台 1507 | 1508 | 一个进程可以在不同的队列中移动 1509 | 1510 | 例如,n级优先级-优先级调度在所有级别中,RR在每个级别中 1511 | 1512 | - 时间量子大小随优先级级别增加而增加 1513 | - 如果任务在当前的时间量子中没有完成,则降到下一个优先级 1514 | 1515 | 优点: CPU密集型任务的优先级下降很快;IO密集型任务停留在高优先级 1516 | 1517 | - **Fair Share Scheduling(公平共享调度)** 1518 | 1519 | FSS控制用户对系统资源的访问 1520 | 1521 | - 一些用户组比其他用户组更重要 1522 | - 保证不重要的组无法垄断资源 1523 | - 未使用的资源按照每个组所分配的资源的比例来分配 1524 | - 没有达到资源使用率目标的组获得更高的优先级 1525 | 1526 | ## 评价方式 1527 | 1528 | 确定性建模: 确定一个工作量,然后计算每个算法的表现 1529 | 1530 | 队列模型: 用来处理随机工作负载的数学方法 1531 | 1532 | 实现/模拟: 建立一个允许算法运行实际数据的系统;最灵活,最具一般性 1533 | 1534 | ## 实时调度 1535 | 1536 | - 实时系统 1537 | 1538 | 定义: 正确性依赖于其时间和功能两方面的一个操作系统 1539 | 1540 | 性能指标: 时间约束的及时性;速度和平均性能相对不重要 1541 | 1542 | 主要特征: 时间约束的可预测性 1543 | 1544 | 分类: 1545 | 1546 | - 强实时系统: 需要在保证时间内完成重要的任务,必须完成 1547 | - 弱实时系统: 要求重要的进程的优先级更高,尽量完成,并非必须 1548 | 1549 | 任务(工作单元): 一次计算,一次文件读取,一次信息传递等 1550 | 1551 | 属性: 去的进展所需要的资源;定时参数. 1552 | 1553 | - 单调速率(RM) 1554 | 1555 | - 最佳静态优先级调度 1556 | - 通过周期安排优先级 1557 | - 周期越短优先级越高 1558 | - 执行周期最短的任务 1559 | 1560 | - 截止日期最早优先(EDF) 1561 | 1562 | - 最佳的动态优先级调度 1563 | - Deadline越早优先级越高 1564 | - 执行Deadline最早的任务 1565 | 1566 | ## 多处理器调度 1567 | 1568 | 多处理器的CPU调度更复杂: 1569 | 1570 | - 多个相同的单处理器组成一个多处理器 1571 | - 优点: 复杂共享 1572 | 1573 | 对称多处理器(SMP) 1574 | 1575 | - 每个处理器运行自己的调度程序 1576 | - 需要在调度程序中同步 1577 | 1578 | ## 优先级反转 1579 | 1580 | 可以发生在任务基于优先级的可抢占的调度机制中 1581 | 1582 | 当系统内的环境强制使高优先级任务等待低优先级任务时发生 1583 | 1584 | 1585 | 1586 | # 第九章 1587 | 1588 | > 第九章的主要内容是：同步 1589 | 1590 | ## 背景 1591 | 1592 | 第一章到第八章内容, 到目前为止 1593 | 1594 | - 多道程序设计: 现代操作系统的重要特性 1595 | - 并行很有用(为什么?) 提示: 多个并发实体: CPU IO 用户 等 1596 | - 进程,线程: 操作系统抽象出来用于支持多道程序设计 1597 | - CPU调度: 实现多道程序设计的机制 1598 | - 调度算法: 不同的策略 1599 | 1600 | 独立的线程: 1601 | 1602 | - 不和其他线程共享资源或状态 1603 | - 确定性: 输入状态决定结果 1604 | - 可重现: 能够重现起始条件, IO 1605 | - 调度顺序不重要 1606 | 1607 | 合作线程: 1608 | 1609 | - 在多个线程中共享状态 1610 | - 不确定性 1611 | - 不可重现 1612 | 1613 | 不确定性和不可重现意味着bug可能是间歇性发生的 1614 | 1615 | 进程,线程;计算机,设备需要合作 1616 | 1617 | 合作优点: 1618 | 1619 | 1. 共享资源 1620 | - 一台电脑,多个用户 1621 | - 一个银行存款余额,多台ATM机 1622 | - 嵌入式系统 1623 | 2. 加速 1624 | - IO操作和计算可以重叠 1625 | - 多处理器 1626 | 3. 模块化 1627 | - 将大程序分解成小程序 gcc会调用cpp,cc1,cc2,as,ld 1628 | - 使系统易于扩展 1629 | 1630 | 程序可以调用函数fork()来创建一个新的进程 1631 | 1632 | - 操作系统需要分配一个新的并且唯一的进程ID 1633 | - 因此在内核中,这个系统调用会运行 new_pid = next_pid++; 1634 | - 翻译成机器指令: 1635 | - Load next_pid Reg1 1636 | - STORE Reg1 new_pid 1637 | - INC Reg1 1638 | - STORE Reg1 next_pid 1639 | 1640 | 假设两个进程并发执行 1641 | 1642 | - 如果next_pid等于100, 那么其中一个进程得到的ID应该是100, 另一个进程的ID应该是101, next_pid应该增加到102 1643 | - 可能在INC前进行了上下文切换, 最终导致两个进程的pid都是100,而next_pid也是101 1644 | 1645 | 无论多个线程的指令序列怎样交替执行,程序都必须正常工作 1646 | 1647 | - 多线程程序具有不确定性和不可重现的特点 1648 | - 不经过专门设计,调试难度很高 1649 | 1650 | 不确定性要求并行程序的正确性 1651 | 1652 | - 先思考清楚问题,把程序的行为设计清楚 1653 | - 切忌给予着手编写代码,碰到问题再调试 1654 | 1655 | ## 一些概念 1656 | 1657 | 前面的现象称为Race Condition(竞态条件) 1658 | 1659 | 系统缺陷: 结果依赖于并发执行或者时间的顺序,时间 1660 | 1661 | - 不确定性 1662 | - 不可重现 1663 | 1664 | 怎么样避免竞态? 1665 | 1666 | Atomic Operator(原子操作) 1667 | 1668 | 原子操作是指一次不存在任何终端或者失败的执行 1669 | 1670 | - 该执行成功结束 1671 | - 或者根本没有执行 1672 | - 并且不应发生任何部分执行的状态 1673 | 1674 | 实际上操作往往不是原子的 1675 | 1676 | - 有些看上去是原子操作,实际上不是 1677 | - 连x++这样的简单语句,实际上是由三条指令构成的 1678 | - 有时候甚至连单条假期指令都不是原子的(Pipeline,super-scalar,out-of-order,pape fault) 1679 | 1680 | 临界区(Critical section)是指进程中的一段需要访问共享资源并且当另一个进程处于相应代码区域时便不会被执行的代码区域 1681 | 1682 | 互斥(Mutual exclusion)是指当一个 进程处于临界区并访问共享资源时,没有其他进程会处于临界区并且访问任何相同的共享资源 1683 | 1684 | 死锁(Dead lock)是指两个或以上进程,在相互等待完成特定任务,而最终没法将自身任务进行下去 1685 | 1686 | 饥饿(Starvation)是指一个可执行的进程,被调度器持续忽略,以至于虽然处于可执行状态却不被执行 1687 | 1688 | ## 临界区 1689 | 1690 | 互斥: 同一时间临界区中最多存在一个线程 1691 | 1692 | Progress: 如果一个线程想要进入临界区,那么它最终会成功 1693 | 1694 | 有限等待: 如果一个线程i处于入口区,那么在i的请求被接受之前,其他线程进入临界区的时间是有限制的 1695 | 1696 | 无忙等待(可选): 如果一个进程在等待进入临界区,那么在它可以进入之前会被挂起 1697 | 1698 | ## 方法1:禁用硬件中断 1699 | 1700 | 没有中断,没有上下文切换,因此没有并发 1701 | 1702 | - 硬件将中断处理延迟到中断被启用之后 1703 | - 大多数现代计算机体系结构都提供指令来完成 1704 | 1705 | 进入临界区 1706 | 1707 | - 禁用中断 1708 | 1709 | 离开临界区 1710 | 1711 | - 开启中断 1712 | 1713 | 一旦中断被禁用,线程就无法被停止 1714 | 1715 | - 整个系统都会为你停下来 1716 | - 可能导致其他线程处于饥饿状态 1717 | 1718 | 要是临界区可以任意长怎么办? 1719 | 1720 | - 无法限制响应中断所需的时间(可能存在硬件影响) 1721 | 1722 | 要小心使用,适合于较小的操作 1723 | 1724 | ## 方法2:基于软件的解决方案 1725 | 1726 | 满足进程Pi和Pj之间互斥的经典的基于软件的解决方法(1981年) 1727 | 1728 | 使用两个共享数据项 1729 | 1730 | - int turn; //指示该谁进入临界区 1731 | - bool flag[]; //指示进程是否准备好进入临界区 1732 | 1733 | 进入临界区: 1734 | 1735 | ```cpp 1736 | flag[i] = true; 1737 | turn = j; 1738 | while(flag[j] && turn == j); 1739 | ``` 1740 | 1741 | 退出临界区: 1742 | 1743 | ```cpp 1744 | flag[i] = false; 1745 | ``` 1746 | 1747 | 实例: 1748 | 1749 | ```cpp 1750 | do{ 1751 | flag[i] = true; 1752 | turn = j; 1753 | while(flag[j] && turn == j); 1754 | CRITICAL SECTION 1755 | flag[i] = false; 1756 | REMAINDER SECTION 1757 | }while(true); 1758 | ``` 1759 | 1760 | Bakery 算法(N个进程的临界区) 1761 | 1762 | - 进入临界区之前,进程接收一个数字 1763 | - 得到的数字最小的进入临界区 1764 | - 如果进程Pi和Pj收到相同的数字,那么如果iAcquire(); 1801 | new_pid = next_pid++; 1802 | lock_next_pid->Release(); 1803 | ``` 1804 | 1805 | 大多数现代体系结构都提供特殊的原子操作指令 1806 | 1807 | - 通过特殊的内存访问电路 1808 | - 针对单处理器和多处理器 1809 | 1810 | Test-and-Set 测试和置位 1811 | 1812 | - 从内存中读取值 1813 | - 测试该值是否为1(然后返回真或假) 1814 | - 内存值设置为1 1815 | 1816 | 交换 1817 | 1818 | - 交换内存中的两个值 1819 | 1820 | ```cpp 1821 | bool TestandSet(bool *target){ 1822 | bool rv = *target; 1823 | *target = true; 1824 | return rv; 1825 | } 1826 | 1827 | void Exchange(bool *a, bool *b){ 1828 | bool tmp = *a; 1829 | *a = *b; 1830 | *b = tmp; 1831 | } 1832 | ``` 1833 | 1834 | - 总结 1835 | 1836 | 锁是更高等级的编程抽象 1837 | 1838 | - 互斥可以使用锁来实现 1839 | - 通常需要一定等级的硬件支持 1840 | 1841 | 常用的三种实现方法 1842 | 1843 | - 禁用中断(仅限于单处理器) 1844 | - 软件方法(复杂) 1845 | - 原子操作指令(单处理器或多处理器均可) 1846 | 1847 | 可选的实现内容: 1848 | 1849 | - 有忙等待 1850 | - 无忙等待 1851 | 1852 | 1853 | 1854 | # 第十章 1855 | 1856 | > 第十章的主要内容是：信号量和管程 1857 | 1858 | ## 信号量 1859 | 1860 | 信号量的抽象数据类型 1861 | 1862 | - 一个整形(sem),具有两个原子操作 1863 | - P(): sem减一,如果sem<0,等待,否则继续 1864 | - V(): sem加一,如果sem≤0,唤醒一个等待的P 1865 | 1866 | 信号量是整数 1867 | 1868 | 信号量是被保护的变量 1869 | 1870 | - 初始化完成后,唯一改变一个信号量的值的办法是通过P()和V() 1871 | - 操作必须是原子 1872 | 1873 | P()能够阻塞,V()不会阻塞 1874 | 1875 | 我们假定信号量是公平的 1876 | 1877 | - 没有线程被阻塞在P()仍然堵塞如果V()被无限频繁调用(在同一个信号量) 1878 | - 在实践中,FIFO经常被使用 1879 | 1880 | 两个类型信号量 1881 | 1882 | - 二进制信号量: 可以是0或1 1883 | - 计数信号量: 可以取任何非负数 1884 | - 两者相互表现(给定一个可以实现另一个) 1885 | 1886 | 信号量可以用在2个方面 1887 | 1888 | - 互斥 1889 | - 条件同步(调度约束——一个线程等待另一个线程的事情发生) 1890 | 1891 | ## 信号量使用 1892 | 1893 | 1. 用二进制信号量实现的互斥 1894 | 1895 | ```cpp 1896 | mutex = new Semaphore(1); 1897 | 1898 | mutex->P(); 1899 | ... 1900 | mutex->V(); 1901 | ``` 1902 | 1903 | 2. 用二进制信号量实现的调度约束 1904 | 1905 | ```cpp 1906 | condition = new Semaphore(0); 1907 | 1908 | //Thread A 1909 | ... 1910 | condition->P(); //等待线程B某一些指令完成之后再继续运行,在此阻塞 1911 | ... 1912 | 1913 | //Thread B 1914 | ... 1915 | condition->V(); //信号量增加唤醒线程A 1916 | ... 1917 | ``` 1918 | 1919 | 3. 一个线程等待另一个线程处理事情 1920 | 1921 | 比如生产东西或消费东西(生产者消费者模式),互斥(锁机制)是不够的 1922 | 1923 | 有界缓冲区的生产者-消费者问题 1924 | 1925 | - 一个或者多个生产者产生数据将数据放在一个缓冲区里 1926 | - 单个消费者每次从缓冲区取出数据 1927 | - 在任何一个时间只有一个生产者或消费者可以访问该缓冲区 1928 | 1929 | 正确性要求 1930 | 1931 | - 在任何一个时间只能有一个线程操作缓冲区(互斥) 1932 | - 当缓冲区为空时,消费者必须等待生产者(调度,同步约束) 1933 | - 当缓存区满,生产者必须等待消费者(调度,同步约束) 1934 | 1935 | 每个约束用一个单独的信号量 1936 | 1937 | - 二进制信号量互斥 1938 | - 一般信号量 fullBuffers 1939 | - 一般信号了 emptyBuffers 1940 | 1941 | ```cpp 1942 | class BoundedBuffer{ 1943 | mutex = new Semaphore(1); 1944 | fullBuffers = new Semaphore(0); //说明缓冲区初始为空 1945 | emptyBuffers = new Semaphore(n); //同时可以有n个生产者来生产 1946 | }; 1947 | 1948 | BoundedBuffer::Deposit(c){ 1949 | emptyBuffers->P(); 1950 | mutex->P(); 1951 | Add c to the buffer; 1952 | mutex->V(); 1953 | fullBuffers->V(); 1954 | } 1955 | 1956 | BoundedBuffer::Remove(c){ 1957 | fullBuffers->P(); 1958 | mutex->P(); 1959 | Remove c from buffer; 1960 | mutex->V(); 1961 | emptyBuffers->V(); 1962 | } 1963 | ``` 1964 | 1965 | ## 信号量实现 1966 | 1967 | 使用硬件原语 1968 | 1969 | - 禁用中断 1970 | - 原子指令 1971 | 1972 | 类似锁 1973 | 1974 | - 禁用中断 1975 | 1976 | ```cpp 1977 | class Semaphore{ 1978 | int sem; 1979 | WaitQueue q; 1980 | }; 1981 | 1982 | Semaphore::P(){ 1983 | --sem; 1984 | if(sem < 0){ 1985 | Add this thread t to q; 1986 | block(p); 1987 | } 1988 | }; 1989 | 1990 | Semaphore::V(){ 1991 | ++sem; 1992 | if(sem <= 0){ 1993 | Remove a thread t from q; 1994 | wakeup(t); 1995 | } 1996 | } 1997 | ``` 1998 | 1999 | 信号量的双用途 2000 | 2001 | - 互斥和条件同步 2002 | - 但等待条件是独立的互斥 2003 | 2004 | 读,开发代码比较困难 2005 | 2006 | - 程序员必须非常精通信号量 2007 | 2008 | 容易出错 2009 | 2010 | - 使用的信号量已经被另一个线程占用 2011 | - 忘记释放信号量 2012 | 2013 | 不能够处理死锁问题 2014 | 2015 | ## 管程 2016 | 2017 | 目的: 分离互斥和条件同步的关注 2018 | 2019 | 什么是管程 2020 | 2021 | - 一个锁: 指定临界区 2022 | - 0或者多个条件变量: 等待,通知信号量用于管程并发访问共享数据 2023 | 2024 | 一般方法 2025 | 2026 | - 收集在对象,模块中的相关共享数据 2027 | - 定义方法来访问共享数据 2028 | 2029 | Lock 2030 | 2031 | - Lock::Acquire() 等待直到锁可用,然后抢占锁 2032 | - Lock::Release() 释放锁,唤醒等待者如果有 2033 | 2034 | Condition Variable 2035 | 2036 | - 允许等待状态进入临界区 2037 | - 允许处于等待(睡眠)的线程进入临界区 2038 | - 某个时刻原子释放锁进入睡眠 2039 | - Wait() operation 2040 | - 释放锁,睡眠,重新获得锁放回 2041 | - Signal() operation(or broadcast() operation) 2042 | - 唤醒等待者(或者所有等待者),如果有 2043 | 2044 | 实现 2045 | 2046 | - 需要维持每个条件队列 2047 | - 线程等待的条件等待signal() 2048 | 2049 | ```cpp 2050 | class Condition{ 2051 | int numWaiting = 0; 2052 | WaitQueue q; 2053 | }; 2054 | 2055 | Condition::Wait(lock){ 2056 | numWaiting++; 2057 | Add this thread t to q; 2058 | release(lock); 2059 | schedule(); //need mutex 2060 | require(lock); 2061 | } 2062 | 2063 | Condition::Signal(){ 2064 | if(numWaiting > 0){ 2065 | Remove a thread t from q; 2066 | wakeup(t); //need mutex 2067 | numWaiting--; 2068 | } 2069 | } 2070 | ``` 2071 | 2072 | 管程解决生产者-消费者问题 2073 | 2074 | ```cpp 2075 | class BoundedBuffer{ 2076 | Lock lock; 2077 | int count = 0; //buffer 为空 2078 | Condition notFull, notEmpty; 2079 | }; 2080 | 2081 | BoundedBuffer::Deposit(c){ 2082 | lock->Acquire(); //管程的定义:只有一个线程能够进入管程 2083 | while(count == n) 2084 | notFull.Wait(&lock); //释放前面的锁 2085 | Add c to the buffer; 2086 | count++; 2087 | notEmpty.Signal(); 2088 | lock->Release(); 2089 | } 2090 | 2091 | BoundedBuffer::Remove(c){ 2092 | lock->Acquire(); 2093 | while(count == 0) 2094 | notEmpty.Wait(&lock); 2095 | Remove c from buffer; 2096 | count--; 2097 | notFull.Signal(); 2098 | lock->Release(); 2099 | } 2100 | ``` 2101 | 2102 | 开发,调试并行程序很难 2103 | 2104 | - 非确定性的交叉指令 2105 | 2106 | 同步结构 2107 | 2108 | - 锁: 互斥 2109 | - 条件变量: 有条件的同步 2110 | - 其他原语: 信号量 2111 | 2112 | 怎么样有效地使用这些结构 2113 | 2114 | - 制定并遵循严格的程序设计风格,策略 2115 | 2116 | ## 经典同步问题 2117 | 2118 | 1. 读者-写者问题 2119 | 2120 | 动机: 共享数据的访问 2121 | 2122 | 两种类型的使用者: 读者(不修改数据) 写者(读取和修改数据) 2123 | 2124 | 问题的约束: 2125 | 2126 | - 允许同一时间有多个读者,但在任何时候只有一个写者 2127 | - 当没有写者时,读者才能访问数据 2128 | - 当没有读者和写者时,写者才能访问数据 2129 | - 在任何时候只能有一个线程可以操作共享变量 2130 | 2131 | 多个并发进程的数据集共享 2132 | 2133 | - 读者: 只读数据集;他们不执行任何更新 2134 | - 写者: 可以读取和写入 2135 | 2136 | 共享数据 2137 | 2138 | - 数据集 2139 | - 信号量CountMutex初始化为1 2140 | - 信号量WriteMutex初始化为1 2141 | - 整数Rcount初始化为0(当前读者个数) 2142 | 2143 | 读者优先设计 2144 | 2145 | 只要有一个读者处于活动状态, 后来的读者都会被接纳.如果读者源源不断的出现,那么写者使用处于阻塞状态. 2146 | 2147 | ```cpp 2148 | //信号量实现 2149 | //writer 2150 | sem_wait(WriteMutex); 2151 | write; 2152 | sem_post(WriteMutex); 2153 | 2154 | //reader 2155 | sem_wait(CountMutex); 2156 | if(Rcount == 0) 2157 | sem_wait(WriteMutex); //确保后续不会有写者进入 2158 | ++Rcount; 2159 | read; 2160 | --Rcount; 2161 | if(Rcount == 0) 2162 | sem_post(WriteMutex); //全部读者全部离开才能唤醒写者 2163 | sem_post(CountMutex); 2164 | ``` 2165 | 2166 | 写者优先设计 2167 | 2168 | 一旦写者就绪,那么写者会尽可能的执行写操作.如果写者源源不断的出现的话,那么读者就始终处于阻塞状态. 2169 | 2170 | ```cpp 2171 | //writer 2172 | Database::Write(){ 2173 | Wait until readers/writers; 2174 | write database; 2175 | check out - wake up waiting readers/writers; 2176 | } 2177 | //reader 2178 | Database::Read(){ 2179 | Wait until no writers; 2180 | read database; 2181 | check out - wake up waiting writers; 2182 | } 2183 | 2184 | //管程实现 2185 | AR = 0; // # of active readers 2186 | AW = 0; // # of active writers 2187 | WR = 0; // # of waiting readers 2188 | WW = 0; // # of waiting writers 2189 | Condition okToRead; 2190 | Condition okToWrite; 2191 | Lock lock; 2192 | //writer 2193 | Public Database::Write(){ 2194 | //Wait until no readers/writers; 2195 | StartWrite(); 2196 | write database; 2197 | //check out - wake up waiting readers/writers; 2198 | DoneWrite(); 2199 | } 2200 | 2201 | Private Database::StartWrite(){ 2202 | lock.Acquire(); 2203 | while((AW + AR) > 0){ 2204 | WW++; 2205 | okToWrite.wait(&lock); 2206 | WW--; 2207 | } 2208 | AW++; 2209 | lock.Release(); 2210 | } 2211 | 2212 | Private Database::DoneWrite(){ 2213 | lock.Acquire(); 2214 | AW--; 2215 | if(WW > 0){ 2216 | okToWrite.signal(); 2217 | } 2218 | else if(WR > 0){ 2219 | okToRead.broadcast(); //唤醒所有reader 2220 | } 2221 | lock.Release(); 2222 | } 2223 | 2224 | //reader 2225 | Public Database::Read(){ 2226 | //Wait until no writers; 2227 | StartRead(); 2228 | read database; 2229 | //check out - wake up waiting writers; 2230 | DoneRead(); 2231 | } 2232 | 2233 | Private Database::StartRead(){ 2234 | lock.Acquire(); 2235 | while(AW + WW > 0){ //关注等待的writer,体现出写者优先 2236 | WR++; 2237 | okToRead.wait(&lock); 2238 | WR--; 2239 | } 2240 | AR++; 2241 | lock.Release(); 2242 | } 2243 | 2244 | private Database::DoneRead(){ 2245 | lock.Acquire(); 2246 | AR--; 2247 | if(AR == 0 && WW > 0){ //只有读者全部没有了,才需要唤醒 2248 | okToWrite.signal(); 2249 | } 2250 | lock.Release(); 2251 | } 2252 | ``` 2253 | 2254 | 2. 哲学家就餐问题(学习自 [github.com/cyc2018](http://github.com/cyc2018)) 2255 | 2256 | 共享数据: 2257 | 2258 | - Bowl of rice(data set) 2259 | - Semaphone fork [5] initialized to 1 2260 | 2261 | ```cpp 2262 | #define N 5 2263 | #define LEFT (i + N - 1) % N // 左邻居 2264 | #define RIGHT (i + 1) % N // 右邻居 2265 | #define THINKING 0 2266 | #define HUNGRY 1 2267 | #define EATING 2 2268 | typedef int semaphore; 2269 | int state[N]; // 跟踪每个哲学家的状态 2270 | semaphore mutex = 1; // 临界区的互斥，临界区是 state 数组，对其修改需要互斥 2271 | semaphore s[N]; // 每个哲学家一个信号量 2272 | 2273 | void philosopher(int i) { 2274 | while(TRUE) { 2275 | think(i); 2276 | take_two(i); 2277 | eat(i); 2278 | put_two(i); 2279 | } 2280 | } 2281 | 2282 | void take_two(int i) { 2283 | down(&mutex); 2284 | state[i] = HUNGRY; 2285 | check(i); 2286 | up(&mutex); 2287 | down(&s[i]); // 只有收到通知之后才可以开始吃，否则会一直等下去 2288 | } 2289 | 2290 | void put_two(i) { 2291 | down(&mutex); 2292 | state[i] = THINKING; 2293 | check(LEFT); // 尝试通知左右邻居，自己吃完了，你们可以开始吃了 2294 | check(RIGHT); 2295 | up(&mutex); 2296 | } 2297 | 2298 | void eat(int i) { 2299 | down(&mutex); 2300 | state[i] = EATING; 2301 | up(&mutex); 2302 | } 2303 | 2304 | // 检查两个邻居是否都没有用餐，如果是的话，就 up(&s[i])，使得 down(&s[i]) 能够得到通知并继续执行 2305 | void check(i) { 2306 | if(state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] !=EATING) { 2307 | state[i] = EATING; 2308 | up(&s[i]); 2309 | } 2310 | } 2311 | ``` 2312 | 2313 | 2314 | 2315 | # 第十一章 2316 | 2317 | > 第十一章的主要内容是：死锁和进程通信 2318 | 2319 | ## 死锁问题 2320 | 2321 | 一组阻塞的进程持有一种资源等待获取另一个进程所占有的一个资源 2322 | 2323 | 示例: 2324 | 2325 | - 系统有2个磁带驱动器 2326 | - P1和P2各有一个,都需要另外一个 2327 | 2328 | ## 系统模型 2329 | 2330 | 资源类型R1,R2,..,Rm(CPU, memory space, IO devices) 2331 | 2332 | 每个资源类型Ri有Wi个实例. 2333 | 2334 | 每个进程使用资源如下: 2335 | 2336 | - require,get ← free resource 2337 | - use,hold ← requested,used resource 2338 | - release ← free resource 2339 | 2340 | 可重复使用的资源 2341 | 2342 | - 在一个时间只能有一个进程使用且不能被删除 2343 | - 进程获得资源,后来释放由其他进程重用 2344 | - 处理器,IO通道,主和副存储器,设备和数据结构,如文件,数据库和信号量 2345 | - 如果每个进程拥有一个资源并请求其他资源,死锁可能发生 2346 | 2347 | 使用资源 2348 | 2349 | - 创建和销毁 2350 | - 在IO缓存区的中断,信号,消息,信息 2351 | - 如果接收消息阻塞可能会发生死锁 2352 | - 可能少见的组合事件会引起死锁 2353 | 2354 | 资源分配图 2355 | 2356 | 一组顶点V和边E的集合 2357 | 2358 | - V有两种类型: 2359 | - P={P1,P2,...,Pn},集合包括系统中的所有进程 2360 | - R={R1,R2,...,Rm},集合包括系统中的所有资源类型 2361 | - requesting,claiming edge - directed edge Pi → Rj 2362 | - assignment,holding edge - directed edge Rj → Pi 2363 | 2364 | 基本情况 2365 | 2366 | 如果图中不包含循环: 2367 | 2368 | - 没有死锁 2369 | 2370 | 如果图中包含循环: 2371 | 2372 | - 如果每个资源类只有一个实例,那么死锁 2373 | - 如果每个资源类有几个实例,可能死锁 2374 | 2375 | ## 死锁特征 2376 | 2377 | 死锁出现一定会出现以下四个条件,但是出现以下四个条件不一定死锁: 2378 | 2379 | - 互斥: 在一个时间只能有一个进程使用资源 2380 | - 持有并等待: 进程保持至少一个资源正在等待获取其他进程持有的额外资源 2381 | - 无抢占: 一个资源只能被进程资源释放,进程已经完成了它的任务之后 2382 | - 循环等待: 存在等待进程集合{P0,P1,...,Pn},P0正在等待P1所占用的资源,P1正在等待P2占用的资源...Pn-1在等待Pn的资源,Pn正在等待P0所占用的资源 2383 | 2384 | ## 死锁处理方法 2385 | 2386 | 常见方法 2387 | 2388 | - 确保系统永远不会进入死锁状态 2389 | - 运行系统进入死锁状态,然后恢复. 2390 | - 忽略这个问题,假装系统中从来没有发生死锁,用于大多数操作系统,包括UNIX 2391 | 2392 | ### Deadlock Prevention 预防 2393 | 2394 | 限制申请方式 2395 | 2396 | - 互斥 - 共享资源不是必须的,必须占用非共享资源 2397 | - 占用并等待 - 必须保证当一个进程请求的资源,它不持有任何其他资源 2398 | - 需要进程请求并分配其所有资源,它开始执行之前或允许进程请求资源仅当进程没有资源 2399 | - 资源利用率低,可能发生饥饿 2400 | - 无抢占 - 2401 | - 如果进程占有某些资源,并请求其他不能被立即分配的资源,则释放当前正占有的资源 2402 | - 被抢占资源添加到资源列表中 2403 | - 只有当它能够获得旧的资源以及它请求新的资源,进程可以得到执行 2404 | - 循环等待 - 对所有资源类型进行排序,并要求每个进程按照资源的顺序进行申请 2405 | 2406 | ### Deadlock Avoidance 避免 2407 | 2408 | 需要系统具有一些额外的先验信息提供 2409 | 2410 | - 最简单和最有效的模式是要求每个进程声明它可能需要的每个类型资源的最大数目 2411 | - 资源的分配状态是通过限定提供与分配的资源数量,和进程的最大需求 2412 | - 死锁避免算法动态检查的资源分配状态,以确保永远不会有一个环形等待状态 2413 | - 当一个进程请求可用资源,系统必须判断立即分配是否能使系统处于安全状态 2414 | - 系统处于安全状态指: 针对所有进程,存在安全序列 2415 | - 序列是安全的: 针对每个Pi,Pi要求的资源能够由当前可用的资源+所有的Pj持有的资源来满足,其中j 第十二章的主要内容是：文件管理 2611 | 2612 | ## 基本概念 2613 | 2614 | ### 文件系统和文件 2615 | 2616 | 文件系统: 一种用于持久性存储的系统抽象 2617 | 2618 | - 在存储上: 组织,控制,导航,访问和检索数据 2619 | - 在大多数计算机系统包含文件系统 2620 | - 个人电脑,服务器,笔记本电脑 2621 | - ipod,tivo,机顶盒,手机,电脑 2622 | - google可能也是由一个文件系统构成的 2623 | 2624 | 文件: 文件系统中的一个单元的相关数据在操作系统中的抽象 2625 | 2626 | 文件系统的功能: 2627 | 2628 | - 分配文件磁盘空间 2629 | - 管理文件块(哪一块属于哪一个文件) 2630 | - 管理空闲空间(哪一块是空闲的) 2631 | - 分配算法(策略) 2632 | - 管理文件集合 2633 | - 定位文件及其内容 2634 | - 命名: 通过名字找到文件的接口 2635 | - 最常见: 分层文件系统 2636 | - 文件系统类型(组织文件的不同方式) 2637 | - 提供的便利及特征 2638 | - 保护: 分层来保护数据安全 2639 | - 可靠性,持久性: 保持文件的持久即使发生崩溃,媒体错误,攻击等 2640 | 2641 | 文件和块: 2642 | 2643 | 文件属性: 名称,类型,位置,大小,保护,创建者,创建时间,最久修改时间... 2644 | 2645 | 文件头: 在存储元数据中保存了每个文件的信息,保存文件的属性,跟踪哪一块存储块属于逻辑上文件结构的哪个偏移 2646 | 2647 | ### 文件描述符 2648 | 2649 | 文件使用模式: 2650 | 2651 | 使用程序必须在使用前先"打开"文件 2652 | 2653 | ```cpp 2654 | f = open(name, flag); 2655 | ... 2656 | ... = read(f, ...); 2657 | ... 2658 | close(f); 2659 | ``` 2660 | 2661 | 内核跟踪每个进程打开的文件: 2662 | 2663 | - 操作系统为每个进程维护一个打开文件表 2664 | - 一个打开文件描述符是这个表中的索引 2665 | 2666 | 需要元数据来管理打开文件: 2667 | 2668 | 文件指针: 指向最近的一次读写位置,每个打开了这个文件的进程都这个指针 2669 | 2670 | 文件打开计数: 记录文件打开的次数 - 当最后一个进程关闭了文件时,允许将其从打开文件表中移除 2671 | 2672 | 文件磁盘位置: 缓存数据访问信息 2673 | 2674 | 访问权限: 每个程序访问模式信息 2675 | 2676 | 用户视图: 持久的数据结构 2677 | 2678 | 系统访问接口: 2679 | 2680 | 字节的集合(UNIX) 2681 | 2682 | 系统不会关心你想存储在磁盘上的任何的数据结构 2683 | 2684 | 操作系统内部视角: 2685 | 2686 | 块的集合(块是逻辑转换单元,而扇区是物理转换单元) 2687 | 2688 | 块大小<> 扇区大小: 在UNIX中, 块的大小是 4KB 2689 | 2690 | 当用户说: 给我2-12字节空间时会发生什么? 2691 | 2692 | 获取字节所在的快 2693 | 2694 | 返回快内对应部分 2695 | 2696 | 如果要写2-12字节? 2697 | 2698 | 获取块 2699 | 2700 | 修改块内对应部分 2701 | 2702 | 写回块 2703 | 2704 | 在文件系统中的所有操作都是在整个块空间上进行的: `getc()` `putc()` 即使每次只访问1字节的数据,也会缓存目标数据4096字节(一个磁盘块) 2705 | 2706 | 用户怎么访问文件: 在系统层面需要知道用户的访问模式 2707 | 2708 | 顺序访问: 按字节依次读取(几乎所有的访问都是这种方式) 2709 | 2710 | 随机访问: 从中间读写(不常用,但是仍然重要,如: 虚拟内存支持文件,内存页存储在文件中;更加快速,不希望获取文件中间的内容的时候也必须先获取块内所有字节) 2711 | 2712 | 内容访问: 通过特征 2713 | 2714 | 文件内部结构: 2715 | 2716 | 无结构: 单词,比特的队列 2717 | 2718 | 简单记录结构: 列,固定长度,可变长度 2719 | 2720 | 复杂结构: 格式化的文档(word, PDF), 可执行文件, ... 2721 | 2722 | 多用户系统中的文件共享是很必要的 2723 | 2724 | 访问控制: 2725 | 2726 | 谁能够获得哪些文件的哪些访问权限 2727 | 2728 | 访问模式: 读,写,执行,删除,列举等 2729 | 2730 | 文件访问控制列表(ACL): 2731 | 2732 | <文件实体, 权限> 2733 | 2734 | UNIX模式: 2735 | 2736 | <用户|组|所有人,读|写|可执行> 2737 | 2738 | 用户ID识别用户,表明每个用户所允许的权限及保护模式 2739 | 2740 | 组ID允许用户组成组,并指定了组访问权限 2741 | 2742 | 指定多用户,客户如何同时访问共享文件: 2743 | 2744 | 和过程同步算法相似 2745 | 2746 | 因磁盘IO和网络延迟而设计简单 2747 | 2748 | UNIX文件系统(UFS)语义: 2749 | 2750 | 对打开文件的写入内容立即对其他打开同一文件的其他用户可见 2751 | 2752 | 共享文件指针允许多用户同时读取和写入文件 2753 | 2754 | 会话语义: 2755 | 2756 | 写入内容只有当文件关闭时可见 2757 | 2758 | 锁: 2759 | 2760 | 一些操作系统和文件系统提供该功能 2761 | 2762 | ### 目录 2763 | 2764 | 文件以目录的方式组织起来 2765 | 2766 | 目录是一类特殊的文件: 每个目录都包含了一张表 2767 | 2768 | 目录和文件的树形结构: 早期的文件系统是扁平的(只有一层目录) 2769 | 2770 | 层次名称空间: /spell/mail/prt/first /programs/p/list 2771 | 2772 | 典型操作: 2773 | 2774 | 搜索文件 2775 | 2776 | 创建文件 2777 | 2778 | 删除文件 2779 | 2780 | 枚举目录 2781 | 2782 | 重命名文件 2783 | 2784 | 在文件系统中遍历一个路径 2785 | 2786 | 操作系统应该只允许内核模式修改目录: 确保映射的完整性,应用程序能够读目录(ls) 2787 | 2788 | 文件名的线性列表,包含了指向数据块的指针: 编程简单,执行耗时 2789 | 2790 | Hash表 - hash数据结构的线性表: 减少目录搜索时间,碰撞,固定大小 2791 | 2792 | 名字解析: 逻辑名字转换成物理资源(如文件)的过程: 2793 | 2794 | 在文件系统中: 到实际文件的文件名(路径) 2795 | 2796 | 遍历文件目录直到找到目标文件 2797 | 2798 | 举例: 解析"/bin/ls": 2799 | 2800 | 读取root的文件头(在磁盘固定位置) 2801 | 2802 | 读取root的数据块: 搜索bin项 2803 | 2804 | 读取bin的文件头 2805 | 2806 | 读取bin的数据块: 搜索ls项 2807 | 2808 | 读取ls的文件头 2809 | 2810 | 当前工作目录: 2811 | 2812 | 每个进程都会指向一个文件目录用于解析文件名 2813 | 2814 | 允许用户指定相对路径来代替绝对路径 2815 | 2816 | 一个文件系统需要先挂载才能被访问 2817 | 2818 | 一个未挂载的文件系统被挂载在挂载点上 2819 | 2820 | ### 文件别名 2821 | 2822 | 两个或多个文件名关联同一个文件: 2823 | 2824 | 硬链接: 多个文件项指向一个文件 2825 | 2826 | 软链接: 以快捷方式指向其他文件 2827 | 2828 | 通过存储真实文件的逻辑名称来实现 2829 | 2830 | 如果删除一个有别名的文件会如何呢? : 这个别名将成为一个悬空指针 2831 | 2832 | Backpointers 方案: 2833 | 2834 | 每个文件有一个包含多个backpointers的列表,所以删除所有的Backpointers 2835 | 2836 | backpointers使用菊花链管理 2837 | 2838 | 添加一个间接层: 目录项数据结构 2839 | 2840 | 链接: 已存在文件的另外一个名字(指针) 2841 | 2842 | 链接处理: 跟随指针来定位文件 2843 | 2844 | 我们如何保证没有循环呢? 2845 | 2846 | 只允许到文件的链接, 不允许在子目录的链接 2847 | 2848 | 每增加一个新的链接都用循环检测算法确定是否合理 2849 | 2850 | 限制路径可遍历文件目录的数量 2851 | 2852 | ### 文件系统种类 2853 | 2854 | 磁盘文件系统: 文件存储在数据存储设备上,如磁盘; 例如: FAT,NTFS,ext2,3,ISO9660等 2855 | 2856 | 数据库文件系统: 文件根据其特征是可被寻址的; 例如: WinFS 2857 | 2858 | 日志文件系统: 记录文件系统的修改,事件; 例如: journaling file system 2859 | 2860 | 网络,分布式文件系统: 例如: NFS,SMB,AFS,GFS 2861 | 2862 | 特殊,虚拟文件系统 2863 | 2864 | ## 虚拟文件系统 2865 | 2866 | 分层结构: 2867 | 2868 | 顶层: 文件,文件系统API 2869 | 2870 | 上层: 虚拟(逻辑)文件系统 (将所有设备IO,网络IO全抽象成为文件,使得接口一致) 2871 | 2872 | 底层: 特定文件系统模块 2873 | 2874 | 目的: 对所有不同文件系统的抽象 2875 | 2876 | 功能: 2877 | 2878 | 提供相同的文件和文件系统接口 2879 | 2880 | 管理所有文件和文件系统关联的数据结构 2881 | 2882 | 高效查询例程,遍历文件系统 2883 | 2884 | 与特定文件系统模块的交互 2885 | 2886 | 数据结构: 2887 | 2888 | 卷[第四声]控制块(UNIX: "superblock") 2889 | 2890 | 每个文件系统一个 2891 | 2892 | 文件系统详细信息 2893 | 2894 | 块,块大小,空余块,计数,指针等 2895 | 2896 | 文件控制块(UNIX: "vnode" or "inode") 2897 | 2898 | 每个文件一个 2899 | 2900 | 文件详细信息 2901 | 2902 | 许可,拥有者,大小,数据库位置等 2903 | 2904 | 目录节点(Linux: "dentry") 2905 | 2906 | 每个目录项一个(目录和文件) 2907 | 2908 | 将目录项数据结构及树形布局编码成树形数据结构 2909 | 2910 | 指向文件控制块,父节点,项目列表等 2911 | 2912 | 其中: 卷控制块(每个文件系统一个),文件控制块(每个文件一个),目录节点(每个目录项一个) 2913 | 2914 | 持续存储在二级存储中: 在分配在存储设备中的数据块中 2915 | 2916 | 当需要时加载进内存: 2917 | 2918 | 卷控制块: 当文件系统挂载时进入内存 2919 | 2920 | 文件控制块: 当文件被访问时进入内存 2921 | 2922 | 目录节点: 在遍历一个文件路径时进入内存 2923 | 2924 | ## 数据块缓存 2925 | 2926 | 数据块按需读入内存: 2927 | 2928 | 提供 `read()` 操作 2929 | 2930 | 预读: 预先读取后面的数据块 2931 | 2932 | 数据块使用后被缓存: 2933 | 2934 | 假设数据将会再次被使用 2935 | 2936 | 写操作可能被缓存和延迟写入 2937 | 2938 | 两种数据块缓存方式: 2939 | 2940 | 普通缓冲区缓存 2941 | 2942 | 页缓存: 同一缓存数据块和内存页 2943 | 2944 | 分页要求: 当需要一个页时才将其载入内存 2945 | 2946 | 支持存储: 一个页(在虚拟地址空间中)可以被映射到一个本地文件中(在二级存储中) 2947 | 2948 | ## 打开文件的数据结构 2949 | 2950 | 打开文件描述: 2951 | 2952 | 每个被打开的文件一个 2953 | 2954 | 文件状态信息 2955 | 2956 | 目录项,当前文件指针,文件操作设置等 2957 | 2958 | 打开文件表: 2959 | 2960 | 一个进程一个 2961 | 2962 | 一个系统级的 2963 | 2964 | 每个卷控制块也会保存一个列表 2965 | 2966 | 所以如果有文件被打开将不能被卸载 2967 | 2968 | 一些操作系统和文件系统提供该功能 2969 | 2970 | 调节对文件的访问 2971 | 2972 | 强制和劝告: 2973 | 2974 | 强制 - 根据锁保持情况和需求拒绝访问 2975 | 2976 | 劝告 - 进程可以查找锁的状态来决定怎么做 2977 | 2978 | ## 文件分配 2979 | 2980 | 大多数文件都很小: 2981 | 2982 | 需要对小文件提供强力的支持 2983 | 2984 | 块空间不能太小 2985 | 2986 | 一些文件非常大: 2987 | 2988 | 必须支持大文件(64-bit 文件偏移) 2989 | 2990 | 大文件访问需要相当高效 2991 | 2992 | 如何为一个文件分配数据块 2993 | 2994 | 分配方式: 2995 | 2996 | 连续分配 2997 | 2998 | 链式分配 2999 | 3000 | 索引分配 3001 | 3002 | 指标: 3003 | 3004 | 高效: 如存储利用(外部碎片) 3005 | 3006 | 表现: 如访问速度 3007 | 3008 | 连续分配: 3009 | 3010 | 文件头指定起始块和长度 3011 | 3012 | 位置,分配策略: 最先匹配,最佳匹配,... 3013 | 3014 | 优势: 文件读取表现好;高效的顺序和随机访问 3015 | 3016 | 劣势: 碎片;文件增长问题 3017 | 3018 | 链式分配: 3019 | 3020 | 文件以数据块链表方式存储 3021 | 3022 | 文件头包含了到第一块和最后一块的指针 3023 | 3024 | 优势: 创建,增大,缩小很容易;没有碎片 3025 | 3026 | 劣势: 不可能进行真正的随机访问;可靠性 3027 | 3028 | 索引分配: 3029 | 3030 | 为每个文件创建一个名为索引数据块的非数据数据块(到文件数据块的指针列表) 3031 | 3032 | 文件头包含了索引数据块 3033 | 3034 | 优势: 创建,增大,缩小很容易;没有碎片;支持直接访问 3035 | 3036 | 劣势: 当文件很小时,存储索引的开销大;处理大文件难 3037 | 3038 | ## 空闲空间列表 3039 | 3040 | 跟踪在存储中的所有未分配的数据块 3041 | 3042 | 空闲空间列表存储在哪里? 3043 | 3044 | 空闲空间列表的最佳数据结构怎么样? 3045 | 3046 | 用位图代表空闲数据块列表: 11111101101110111 如果 i = 0表明数据块i是空闲的,反之是分配的 3047 | 3048 | 使用简单但是可能会是一个big vector: 3049 | 3050 | 160GB disk → 40M blocks → 5MB worth of bits 3051 | 3052 | 然而,如果空闲空间在磁盘中均匀分布,那么再找到"0"之前需要扫描 磁盘上数据块总数 / 空闲块的数目 3053 | 3054 | 需要保护: 3055 | 3056 | 指向空闲列表的指针 3057 | 3058 | 位图: 3059 | 3060 | 必须保存在磁盘上;在内存和磁盘拷贝可能有所不同;不允许block[i]在内存中的状态为bit[i]=1而在磁盘中bit[i]=0 3061 | 3062 | 解决: 3063 | 3064 | 在磁盘上设置bit[i] = 1; 分配block[i]; 在内存中设置bit[i] = 1 3065 | 3066 | ## 多磁盘管理 - RAID 3067 | 3068 | 通常磁盘通过分区来最大限度减小寻道时间: 3069 | 3070 | 一个分区是一个柱面的集合 3071 | 3072 | 每个分区都是逻辑上独立的磁盘 3073 | 3074 | 分区: 硬件磁盘的一种适合操作系统指定格式的划分 3075 | 3076 | 卷: 一个拥有一个文件系统实例的可访问的存储空间(通常常驻在磁盘的单个分区上) 3077 | 3078 | 使用多个并行磁盘来增加: 吞吐量(通过并行),可靠性和可用性(通过冗余) 3079 | 3080 | RAID - 冗余磁盘阵列: 各种磁盘管理技术;RAID levels: 不同RAID分类,如RAID-0,RAID-1,RAID-5 3081 | 3082 | 实现: 在操作系统内核: 存储,卷管理; RAID硬件控制器(IO) 3083 | 3084 | RAID-0 3085 | 3086 | 数据块分成多个子块, 存储在独立的磁盘中: 和内存交叉相似 3087 | 3088 | 通过更大的有效块大小来提供更大的磁盘带宽 3089 | 3090 | RAID-1 3091 | 3092 | 可靠性成倍增长 3093 | 3094 | 读取性能线性增加(向两个磁盘写入,从任何一个读取) 3095 | 3096 | RAID-4 3097 | 3098 | 数据块级磁带配有专用奇偶校验磁盘: 允许从任意一个故障磁盘中恢复 3099 | 3100 | 条带化和奇偶校验按byte-by-byte或者bit-by-bit: RAID-0,4,5: block-wise ;RAID-3: bit-wise 3101 | 3102 | RAID-5 3103 | 3104 | 每个条带快有一个奇偶校验块,允许有一个磁盘错误 3105 | 3106 | RAID-6 3107 | 3108 | 两个冗余块,有一种特殊的编码方式,允许两个磁盘错误 3109 | 3110 | ## 磁盘调度 3111 | 3112 | 读取或写入时,磁头必须被定位在期望的磁道,并从所期望的扇区开始 3113 | 3114 | 寻道时间: 定位到期望的磁道所花费的时间 3115 | 3116 | 旋转延迟: 从扇区的开始处到到达目的处花费的时间 3117 | 3118 | 平均旋转延迟时间 = 磁盘旋转一周时间的一半 3119 | 3120 | 寻道时间是性能上区别的原因 3121 | 3122 | 对单个磁盘,会有一个IO请求数目 3123 | 3124 | 如果请求是随机的,那么会表现很差 3125 | 3126 | FIFO: 3127 | 3128 | 按顺序处理请求 3129 | 3130 | 公平对待所有进程 3131 | 3132 | 在有很多进程的情况下,接近随机调度的性能 3133 | 3134 | 最短服务优先: 3135 | 3136 | 选择从磁臂当前位置需要移动最少的IO请求 3137 | 3138 | 总是选择最短寻道时间 3139 | 3140 | skan: 3141 | 3142 | 磁臂在一个方向上移动,满足所有为完成的请求,直到磁臂到达该方向上最后的磁道 3143 | 3144 | 调换方向 3145 | 3146 | c-skan: 3147 | 3148 | 限制了仅在一个方向上扫描 3149 | 3150 | 当最后一个磁道也被访问过了后,磁臂返回到磁盘的另外一端再次进行扫描 3151 | 3152 | c-loop(c-skan改进): 3153 | 3154 | 磁臂先到达该方向上最后一个请求处,然后立即反转 3155 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 清华大学-深入理解操作系统笔记 2 | ---- 3 | 4 | 5 | 2020.11.21 - 笔记部分完成 6 | 7 | 2022.05.23 - 答主已经硕士毕业并且考上了老家的教师编制，即将成为一名计算机教师，依然喜欢编程和计算机的知识。浏览学习本仓库的大抵是本科和硕士即将找工作的同学，同学们有什么想要交流的，学习的课程可以提交issues, 分享一些对找工作、提升编码技能有帮助的课程, 我们可以一起完成笔记一起进步 8 | 9 | 10 | 11 | 计划学习: 12 | 13 | 1. cpp 14 | 2. python 15 | 3. vue/react 16 | 4. 编译原理 17 | 5. 计算机网络 18 | 6. 等 19 | 20 | 2023.03.04 - 已经在中职院校工作了半年啦 21 | 现在认为，从计算机硕士毕业选择考教师编制还是挺香的，工资虽然不是很高，但是同事之间关系单纯，和学生教学也挺快乐，而且上的还是Python课，太快乐了。毕业的暑假去了一趟厦门，这个寒假去了一趟重庆，周末基本上都带着相机在外面玩耍，南浔、上海、杭州，去溜达、看展、打桌游。可能对于我来说，这才是更有生活，更有烟火气的选择吧。准备去大厂工作的小伙伴们也要坚定自己的选择，我看到我去腾讯的室友每个月买点什么自己喜欢的东西别提多心痒痒了。我如果去大厂工作，我可能会攒攒钱，买一台哈苏的X2D或者徕卡，但是我现在的工作，只能支持我买一台富士的xh2或者尼康的z5。不同的选择，但一样要热爱现在的生活。 22 | 感谢各位同学们的fork，去年5月份还壮志凌云地想继续学习以上的知识可能也要暂时搁浅了，但是时刻没有放弃继续学习，我再更深入地学习python，研究如何让学生学会python，这是我目前最重要的学习。 23 | 24 | ——《半年有感》 25 | -------------------------------------------------------------------------------- /docs/Charpter 1.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第一章 2 | 3 | > 第一章的主要内容是 : 操作系统的一些知识 4 | 5 | ## 操作系统是什么？ 6 | 7 | 用户角度：操作系统是一个控制软件 8 | 9 | * 管理应用程序 10 | * 为应用程序提供服务 11 | * 杀死应用程序 12 | 13 | 程序角度：操作系统是资源管理器 14 | 15 | * 管理外设、分配资源 16 | * 抽象 17 | * 将CPU抽象成进程 18 | * 将磁盘抽象成文件 19 | * 将内存抽象成地址空间 20 | 21 | ## 操作系统层次 22 | 23 | 位于硬件之上，应用程序之下。 24 | 25 | ## 操作系统的界面和内核 26 | 27 | Linux Windows Android 的界面属于外壳(Shell) ，而不是内核(kernel)。操作系统研究的是内核，处于Shell之下。 28 | 29 | ## 操作系统内部组件 30 | 31 | * CPU调度器 32 | * 物理内存管理 33 | * 虚拟内存管理 34 | * 文件系统管理 35 | * 中断处理与设备驱动 36 | 37 | ## 操作系统特征 38 | 39 | * 并发 40 | * 一段时间内运行多个进程（并行 : 一个时间点运行多个进程，一般要求有多个CPU) 41 | * 需要OS管理和调度 42 | * 共享 43 | * “同时”共享 44 | * 互斥共享 45 | * 虚拟 46 | * 让每一个用户觉得的有一个计算机专门为他服务 47 | * 异步 48 | * 程序是走走停停，而不是一直运行 49 | 50 | 51 | -------------------------------------------------------------------------------- /docs/Charpter 10.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第十章 2 | 3 | > 第十章的主要内容是：信号量和管程 4 | 5 | ## 信号量 6 | 7 | 信号量的抽象数据类型 8 | 9 | - 一个整形(sem),具有两个原子操作 10 | - P(): sem减一,如果sem<0,等待,否则继续 11 | - V(): sem加一,如果sem≤0,唤醒一个等待的P 12 | 13 | 信号量是整数 14 | 15 | 信号量是被保护的变量 16 | 17 | - 初始化完成后,唯一改变一个信号量的值的办法是通过P()和V() 18 | - 操作必须是原子 19 | 20 | P()能够阻塞,V()不会阻塞 21 | 22 | 我们假定信号量是公平的 23 | 24 | - 没有线程被阻塞在P()仍然堵塞如果V()被无限频繁调用(在同一个信号量) 25 | - 在实践中,FIFO经常被使用 26 | 27 | 两个类型信号量 28 | 29 | - 二进制信号量: 可以是0或1 30 | - 计数信号量: 可以取任何非负数 31 | - 两者相互表现(给定一个可以实现另一个) 32 | 33 | 信号量可以用在2个方面 34 | 35 | - 互斥 36 | - 条件同步(调度约束——一个线程等待另一个线程的事情发生) 37 | 38 | ## 信号量使用 39 | 40 | 1. 用二进制信号量实现的互斥 41 | 42 | ```cpp 43 | mutex = new Semaphore(1); 44 | 45 | mutex->P(); 46 | ... 47 | mutex->V(); 48 | ``` 49 | 50 | 2. 用二进制信号量实现的调度约束 51 | 52 | ```cpp 53 | condition = new Semaphore(0); 54 | 55 | //Thread A 56 | ... 57 | condition->P(); //等待线程B某一些指令完成之后再继续运行,在此阻塞 58 | ... 59 | 60 | //Thread B 61 | ... 62 | condition->V(); //信号量增加唤醒线程A 63 | ... 64 | ``` 65 | 66 | 3. 一个线程等待另一个线程处理事情 67 | 68 | 比如生产东西或消费东西(生产者消费者模式),互斥(锁机制)是不够的 69 | 70 | 有界缓冲区的生产者-消费者问题 71 | 72 | - 一个或者多个生产者产生数据将数据放在一个缓冲区里 73 | - 单个消费者每次从缓冲区取出数据 74 | - 在任何一个时间只有一个生产者或消费者可以访问该缓冲区 75 | 76 | 正确性要求 77 | 78 | - 在任何一个时间只能有一个线程操作缓冲区(互斥) 79 | - 当缓冲区为空时,消费者必须等待生产者(调度,同步约束) 80 | - 当缓存区满,生产者必须等待消费者(调度,同步约束) 81 | 82 | 每个约束用一个单独的信号量 83 | 84 | - 二进制信号量互斥 85 | - 一般信号量 fullBuffers 86 | - 一般信号了 emptyBuffers 87 | 88 | ```cpp 89 | class BoundedBuffer{ 90 | mutex = new Semaphore(1); 91 | fullBuffers = new Semaphore(0); //说明缓冲区初始为空 92 | emptyBuffers = new Semaphore(n); //同时可以有n个生产者来生产 93 | }; 94 | 95 | BoundedBuffer::Deposit(c){ 96 | emptyBuffers->P(); 97 | mutex->P(); 98 | Add c to the buffer; 99 | mutex->V(); 100 | fullBuffers->V(); 101 | } 102 | 103 | BoundedBuffer::Remove(c){ 104 | fullBuffers->P(); 105 | mutex->P(); 106 | Remove c from buffer; 107 | mutex->V(); 108 | emptyBuffers->V(); 109 | } 110 | ``` 111 | 112 | ## 信号量实现 113 | 114 | 使用硬件原语 115 | 116 | - 禁用中断 117 | - 原子指令 118 | 119 | 类似锁 120 | 121 | - 禁用中断 122 | 123 | ```cpp 124 | class Semaphore{ 125 | int sem; 126 | WaitQueue q; 127 | }; 128 | 129 | Semaphore::P(){ 130 | --sem; 131 | if(sem < 0){ 132 | Add this thread t to q; 133 | block(p); 134 | } 135 | }; 136 | 137 | Semaphore::V(){ 138 | ++sem; 139 | if(sem <= 0){ 140 | Remove a thread t from q; 141 | wakeup(t); 142 | } 143 | } 144 | ``` 145 | 146 | 信号量的双用途 147 | 148 | - 互斥和条件同步 149 | - 但等待条件是独立的互斥 150 | 151 | 读,开发代码比较困难 152 | 153 | - 程序员必须非常精通信号量 154 | 155 | 容易出错 156 | 157 | - 使用的信号量已经被另一个线程占用 158 | - 忘记释放信号量 159 | 160 | 不能够处理死锁问题 161 | 162 | ## 管程 163 | 164 | 目的: 分离互斥和条件同步的关注 165 | 166 | 什么是管程 167 | 168 | - 一个锁: 指定临界区 169 | - 0或者多个条件变量: 等待,通知信号量用于管程并发访问共享数据 170 | 171 | 一般方法 172 | 173 | - 收集在对象,模块中的相关共享数据 174 | - 定义方法来访问共享数据 175 | 176 | Lock 177 | 178 | - Lock::Acquire() 等待直到锁可用,然后抢占锁 179 | - Lock::Release() 释放锁,唤醒等待者如果有 180 | 181 | Condition Variable 182 | 183 | - 允许等待状态进入临界区 184 | - 允许处于等待(睡眠)的线程进入临界区 185 | - 某个时刻原子释放锁进入睡眠 186 | - Wait() operation 187 | - 释放锁,睡眠,重新获得锁放回 188 | - Signal() operation(or broadcast() operation) 189 | - 唤醒等待者(或者所有等待者),如果有 190 | 191 | 实现 192 | 193 | - 需要维持每个条件队列 194 | - 线程等待的条件等待signal() 195 | 196 | ```cpp 197 | class Condition{ 198 | int numWaiting = 0; 199 | WaitQueue q; 200 | }; 201 | 202 | Condition::Wait(lock){ 203 | numWaiting++; 204 | Add this thread t to q; 205 | release(lock); 206 | schedule(); //need mutex 207 | require(lock); 208 | } 209 | 210 | Condition::Signal(){ 211 | if(numWaiting > 0){ 212 | Remove a thread t from q; 213 | wakeup(t); //need mutex 214 | numWaiting--; 215 | } 216 | } 217 | ``` 218 | 219 | 管程解决生产者-消费者问题 220 | 221 | ```cpp 222 | class BoundedBuffer{ 223 | Lock lock; 224 | int count = 0; //buffer 为空 225 | Condition notFull, notEmpty; 226 | }; 227 | 228 | BoundedBuffer::Deposit(c){ 229 | lock->Acquire(); //管程的定义:只有一个线程能够进入管程 230 | while(count == n) 231 | notFull.Wait(&lock); //释放前面的锁 232 | Add c to the buffer; 233 | count++; 234 | notEmpty.Signal(); 235 | lock->Release(); 236 | } 237 | 238 | BoundedBuffer::Remove(c){ 239 | lock->Acquire(); 240 | while(count == 0) 241 | notEmpty.Wait(&lock); 242 | Remove c from buffer; 243 | count--; 244 | notFull.Signal(); 245 | lock->Release(); 246 | } 247 | ``` 248 | 249 | 开发,调试并行程序很难 250 | 251 | - 非确定性的交叉指令 252 | 253 | 同步结构 254 | 255 | - 锁: 互斥 256 | - 条件变量: 有条件的同步 257 | - 其他原语: 信号量 258 | 259 | 怎么样有效地使用这些结构 260 | 261 | - 制定并遵循严格的程序设计风格,策略 262 | 263 | ## 经典同步问题 264 | 265 | 1. 读者-写者问题 266 | 267 | 动机: 共享数据的访问 268 | 269 | 两种类型的使用者: 读者(不修改数据) 写者(读取和修改数据) 270 | 271 | 问题的约束: 272 | 273 | - 允许同一时间有多个读者,但在任何时候只有一个写者 274 | - 当没有写者时,读者才能访问数据 275 | - 当没有读者和写者时,写者才能访问数据 276 | - 在任何时候只能有一个线程可以操作共享变量 277 | 278 | 多个并发进程的数据集共享 279 | 280 | - 读者: 只读数据集;他们不执行任何更新 281 | - 写者: 可以读取和写入 282 | 283 | 共享数据 284 | 285 | - 数据集 286 | - 信号量CountMutex初始化为1 287 | - 信号量WriteMutex初始化为1 288 | - 整数Rcount初始化为0(当前读者个数) 289 | 290 | 读者优先设计 291 | 292 | 只要有一个读者处于活动状态, 后来的读者都会被接纳.如果读者源源不断的出现,那么写者使用处于阻塞状态. 293 | 294 | ```cpp 295 | //信号量实现 296 | //writer 297 | sem_wait(WriteMutex); 298 | write; 299 | sem_post(WriteMutex); 300 | 301 | //reader 302 | sem_wait(CountMutex); 303 | if(Rcount == 0) 304 | sem_wait(WriteMutex); //确保后续不会有写者进入 305 | ++Rcount; 306 | read; 307 | --Rcount; 308 | if(Rcount == 0) 309 | sem_post(WriteMutex); //全部读者全部离开才能唤醒写者 310 | sem_post(CountMutex); 311 | ``` 312 | 313 | 写者优先设计 314 | 315 | 一旦写者就绪,那么写者会尽可能的执行写操作.如果写者源源不断的出现的话,那么读者就始终处于阻塞状态. 316 | 317 | ```cpp 318 | //writer 319 | Database::Write(){ 320 | Wait until readers/writers; 321 | write database; 322 | check out - wake up waiting readers/writers; 323 | } 324 | //reader 325 | Database::Read(){ 326 | Wait until no writers; 327 | read database; 328 | check out - wake up waiting writers; 329 | } 330 | 331 | //管程实现 332 | AR = 0; // # of active readers 333 | AW = 0; // # of active writers 334 | WR = 0; // # of waiting readers 335 | WW = 0; // # of waiting writers 336 | Condition okToRead; 337 | Condition okToWrite; 338 | Lock lock; 339 | //writer 340 | Public Database::Write(){ 341 | //Wait until no readers/writers; 342 | StartWrite(); 343 | write database; 344 | //check out - wake up waiting readers/writers; 345 | DoneWrite(); 346 | } 347 | 348 | Private Database::StartWrite(){ 349 | lock.Acquire(); 350 | while((AW + AR) > 0){ 351 | WW++; 352 | okToWrite.wait(&lock); 353 | WW--; 354 | } 355 | AW++; 356 | lock.Release(); 357 | } 358 | 359 | Private Database::DoneWrite(){ 360 | lock.Acquire(); 361 | AW--; 362 | if(WW > 0){ 363 | okToWrite.signal(); 364 | } 365 | else if(WR > 0){ 366 | okToRead.broadcast(); //唤醒所有reader 367 | } 368 | lock.Release(); 369 | } 370 | 371 | //reader 372 | Public Database::Read(){ 373 | //Wait until no writers; 374 | StartRead(); 375 | read database; 376 | //check out - wake up waiting writers; 377 | DoneRead(); 378 | } 379 | 380 | Private Database::StartRead(){ 381 | lock.Acquire(); 382 | while(AW + WW > 0){ //关注等待的writer,体现出写者优先 383 | WR++; 384 | okToRead.wait(&lock); 385 | WR--; 386 | } 387 | AR++; 388 | lock.Release(); 389 | } 390 | 391 | private Database::DoneRead(){ 392 | lock.Acquire(); 393 | AR--; 394 | if(AR == 0 && WW > 0){ //只有读者全部没有了,才需要唤醒 395 | okToWrite.signal(); 396 | } 397 | lock.Release(); 398 | } 399 | ``` 400 | 401 | 2. 哲学家就餐问题(学习自 [github.com/cyc2018](http://github.com/cyc2018)) 402 | 403 | 共享数据: 404 | 405 | - Bowl of rice(data set) 406 | - Semaphone fork [5] initialized to 1 407 | 408 | ```cpp 409 | #define N 5 410 | #define LEFT (i + N - 1) % N // 左邻居 411 | #define RIGHT (i + 1) % N // 右邻居 412 | #define THINKING 0 413 | #define HUNGRY 1 414 | #define EATING 2 415 | typedef int semaphore; 416 | int state[N]; // 跟踪每个哲学家的状态 417 | semaphore mutex = 1; // 临界区的互斥，临界区是 state 数组，对其修改需要互斥 418 | semaphore s[N]; // 每个哲学家一个信号量 419 | 420 | void philosopher(int i) { 421 | while(TRUE) { 422 | think(i); 423 | take_two(i); 424 | eat(i); 425 | put_two(i); 426 | } 427 | } 428 | 429 | void take_two(int i) { 430 | down(&mutex); 431 | state[i] = HUNGRY; 432 | check(i); 433 | up(&mutex); 434 | down(&s[i]); // 只有收到通知之后才可以开始吃，否则会一直等下去 435 | } 436 | 437 | void put_two(i) { 438 | down(&mutex); 439 | state[i] = THINKING; 440 | check(LEFT); // 尝试通知左右邻居，自己吃完了，你们可以开始吃了 441 | check(RIGHT); 442 | up(&mutex); 443 | } 444 | 445 | void eat(int i) { 446 | down(&mutex); 447 | state[i] = EATING; 448 | up(&mutex); 449 | } 450 | 451 | // 检查两个邻居是否都没有用餐，如果是的话，就 up(&s[i])，使得 down(&s[i]) 能够得到通知并继续执行 452 | void check(i) { 453 | if(state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] !=EATING) { 454 | state[i] = EATING; 455 | up(&s[i]); 456 | } 457 | } 458 | ``` 459 | 460 | -------------------------------------------------------------------------------- /docs/Charpter 11.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第十一章 2 | 3 | > 第十一章的主要内容是：死锁和进程通信 4 | 5 | ## 死锁问题 6 | 7 | 一组阻塞的进程持有一种资源等待获取另一个进程所占有的一个资源 8 | 9 | 示例: 10 | 11 | - 系统有2个磁带驱动器 12 | - P1和P2各有一个,都需要另外一个 13 | 14 | ## 系统模型 15 | 16 | 资源类型R1,R2,..,Rm(CPU, memory space, IO devices) 17 | 18 | 每个资源类型Ri有Wi个实例. 19 | 20 | 每个进程使用资源如下: 21 | 22 | - require,get ← free resource 23 | - use,hold ← requested,used resource 24 | - release ← free resource 25 | 26 | 可重复使用的资源 27 | 28 | - 在一个时间只能有一个进程使用且不能被删除 29 | - 进程获得资源,后来释放由其他进程重用 30 | - 处理器,IO通道,主和副存储器,设备和数据结构,如文件,数据库和信号量 31 | - 如果每个进程拥有一个资源并请求其他资源,死锁可能发生 32 | 33 | 使用资源 34 | 35 | - 创建和销毁 36 | - 在IO缓存区的中断,信号,消息,信息 37 | - 如果接收消息阻塞可能会发生死锁 38 | - 可能少见的组合事件会引起死锁 39 | 40 | 资源分配图 41 | 42 | 一组顶点V和边E的集合 43 | 44 | - V有两种类型: 45 | - P={P1,P2,...,Pn},集合包括系统中的所有进程 46 | - R={R1,R2,...,Rm},集合包括系统中的所有资源类型 47 | - requesting,claiming edge - directed edge Pi → Rj 48 | - assignment,holding edge - directed edge Rj → Pi 49 | 50 | 基本情况 51 | 52 | 如果图中不包含循环: 53 | 54 | - 没有死锁 55 | 56 | 如果图中包含循环: 57 | 58 | - 如果每个资源类只有一个实例,那么死锁 59 | - 如果每个资源类有几个实例,可能死锁 60 | 61 | ## 死锁特征 62 | 63 | 死锁出现一定会出现以下四个条件,但是出现以下四个条件不一定死锁: 64 | 65 | - 互斥: 在一个时间只能有一个进程使用资源 66 | - 持有并等待: 进程保持至少一个资源正在等待获取其他进程持有的额外资源 67 | - 无抢占: 一个资源只能被进程资源释放,进程已经完成了它的任务之后 68 | - 循环等待: 存在等待进程集合{P0,P1,...,Pn},P0正在等待P1所占用的资源,P1正在等待P2占用的资源...Pn-1在等待Pn的资源,Pn正在等待P0所占用的资源 69 | 70 | ## 死锁处理方法 71 | 72 | 常见方法 73 | 74 | - 确保系统永远不会进入死锁状态 75 | - 运行系统进入死锁状态,然后恢复. 76 | - 忽略这个问题,假装系统中从来没有发生死锁,用于大多数操作系统,包括UNIX 77 | 78 | ### Deadlock Prevention 预防 79 | 80 | 限制申请方式 81 | 82 | - 互斥 - 共享资源不是必须的,必须占用非共享资源 83 | - 占用并等待 - 必须保证当一个进程请求的资源,它不持有任何其他资源 84 | - 需要进程请求并分配其所有资源,它开始执行之前或允许进程请求资源仅当进程没有资源 85 | - 资源利用率低,可能发生饥饿 86 | - 无抢占 - 87 | - 如果进程占有某些资源,并请求其他不能被立即分配的资源,则释放当前正占有的资源 88 | - 被抢占资源添加到资源列表中 89 | - 只有当它能够获得旧的资源以及它请求新的资源,进程可以得到执行 90 | - 循环等待 - 对所有资源类型进行排序,并要求每个进程按照资源的顺序进行申请 91 | 92 | ### Deadlock Avoidance 避免 93 | 94 | 需要系统具有一些额外的先验信息提供 95 | 96 | - 最简单和最有效的模式是要求每个进程声明它可能需要的每个类型资源的最大数目 97 | - 资源的分配状态是通过限定提供与分配的资源数量,和进程的最大需求 98 | - 死锁避免算法动态检查的资源分配状态,以确保永远不会有一个环形等待状态 99 | - 当一个进程请求可用资源,系统必须判断立即分配是否能使系统处于安全状态 100 | - 系统处于安全状态指: 针对所有进程,存在安全序列 101 | - 序列是安全的: 针对每个Pi,Pi要求的资源能够由当前可用的资源+所有的Pj持有的资源来满足,其中j 第十二章的主要内容是：文件管理 4 | 5 | ## 基本概念 6 | 7 | ### 文件系统和文件 8 | 9 | 文件系统: 一种用于持久性存储的系统抽象 10 | 11 | - 在存储上: 组织,控制,导航,访问和检索数据 12 | - 在大多数计算机系统包含文件系统 13 | - 个人电脑,服务器,笔记本电脑 14 | - ipod,tivo,机顶盒,手机,电脑 15 | - google可能也是由一个文件系统构成的 16 | 17 | 文件: 文件系统中的一个单元的相关数据在操作系统中的抽象 18 | 19 | 文件系统的功能: 20 | 21 | - 分配文件磁盘空间 22 | - 管理文件块(哪一块属于哪一个文件) 23 | - 管理空闲空间(哪一块是空闲的) 24 | - 分配算法(策略) 25 | - 管理文件集合 26 | - 定位文件及其内容 27 | - 命名: 通过名字找到文件的接口 28 | - 最常见: 分层文件系统 29 | - 文件系统类型(组织文件的不同方式) 30 | - 提供的便利及特征 31 | - 保护: 分层来保护数据安全 32 | - 可靠性,持久性: 保持文件的持久即使发生崩溃,媒体错误,攻击等 33 | 34 | 文件和块: 35 | 36 | 文件属性: 名称,类型,位置,大小,保护,创建者,创建时间,最久修改时间... 37 | 38 | 文件头: 在存储元数据中保存了每个文件的信息,保存文件的属性,跟踪哪一块存储块属于逻辑上文件结构的哪个偏移 39 | 40 | ### 文件描述符 41 | 42 | 文件使用模式: 43 | 44 | 使用程序必须在使用前先"打开"文件 45 | 46 | ```cpp 47 | f = open(name, flag); 48 | ... 49 | ... = read(f, ...); 50 | ... 51 | close(f); 52 | ``` 53 | 54 | 内核跟踪每个进程打开的文件: 55 | 56 | - 操作系统为每个进程维护一个打开文件表 57 | - 一个打开文件描述符是这个表中的索引 58 | 59 | 需要元数据来管理打开文件: 60 | 61 | 文件指针: 指向最近的一次读写位置,每个打开了这个文件的进程都这个指针 62 | 63 | 文件打开计数: 记录文件打开的次数 - 当最后一个进程关闭了文件时,允许将其从打开文件表中移除 64 | 65 | 文件磁盘位置: 缓存数据访问信息 66 | 67 | 访问权限: 每个程序访问模式信息 68 | 69 | 用户视图: 持久的数据结构 70 | 71 | 系统访问接口: 72 | 73 | 字节的集合(UNIX) 74 | 75 | 系统不会关心你想存储在磁盘上的任何的数据结构 76 | 77 | 操作系统内部视角: 78 | 79 | 块的集合(块是逻辑转换单元,而扇区是物理转换单元) 80 | 81 | 块大小<> 扇区大小: 在UNIX中, 块的大小是 4KB 82 | 83 | 当用户说: 给我2-12字节空间时会发生什么? 84 | 85 | 获取字节所在的快 86 | 87 | 返回快内对应部分 88 | 89 | 如果要写2-12字节? 90 | 91 | 获取块 92 | 93 | 修改块内对应部分 94 | 95 | 写回块 96 | 97 | 在文件系统中的所有操作都是在整个块空间上进行的: `getc()` `putc()` 即使每次只访问1字节的数据,也会缓存目标数据4096字节(一个磁盘块) 98 | 99 | 用户怎么访问文件: 在系统层面需要知道用户的访问模式 100 | 101 | 顺序访问: 按字节依次读取(几乎所有的访问都是这种方式) 102 | 103 | 随机访问: 从中间读写(不常用,但是仍然重要,如: 虚拟内存支持文件,内存页存储在文件中;更加快速,不希望获取文件中间的内容的时候也必须先获取块内所有字节) 104 | 105 | 内容访问: 通过特征 106 | 107 | 文件内部结构: 108 | 109 | 无结构: 单词,比特的队列 110 | 111 | 简单记录结构: 列,固定长度,可变长度 112 | 113 | 复杂结构: 格式化的文档(word, PDF), 可执行文件, ... 114 | 115 | 多用户系统中的文件共享是很必要的 116 | 117 | 访问控制: 118 | 119 | 谁能够获得哪些文件的哪些访问权限 120 | 121 | 访问模式: 读,写,执行,删除,列举等 122 | 123 | 文件访问控制列表(ACL): 124 | 125 | <文件实体, 权限> 126 | 127 | UNIX模式: 128 | 129 | <用户|组|所有人,读|写|可执行> 130 | 131 | 用户ID识别用户,表明每个用户所允许的权限及保护模式 132 | 133 | 组ID允许用户组成组,并指定了组访问权限 134 | 135 | 指定多用户,客户如何同时访问共享文件: 136 | 137 | 和过程同步算法相似 138 | 139 | 因磁盘IO和网络延迟而设计简单 140 | 141 | UNIX文件系统(UFS)语义: 142 | 143 | 对打开文件的写入内容立即对其他打开同一文件的其他用户可见 144 | 145 | 共享文件指针允许多用户同时读取和写入文件 146 | 147 | 会话语义: 148 | 149 | 写入内容只有当文件关闭时可见 150 | 151 | 锁: 152 | 153 | 一些操作系统和文件系统提供该功能 154 | 155 | ### 目录 156 | 157 | 文件以目录的方式组织起来 158 | 159 | 目录是一类特殊的文件: 每个目录都包含了一张表 160 | 161 | 目录和文件的树形结构: 早期的文件系统是扁平的(只有一层目录) 162 | 163 | 层次名称空间: /spell/mail/prt/first /programs/p/list 164 | 165 | 典型操作: 166 | 167 | 搜索文件 168 | 169 | 创建文件 170 | 171 | 删除文件 172 | 173 | 枚举目录 174 | 175 | 重命名文件 176 | 177 | 在文件系统中遍历一个路径 178 | 179 | 操作系统应该只允许内核模式修改目录: 确保映射的完整性,应用程序能够读目录(ls) 180 | 181 | 文件名的线性列表,包含了指向数据块的指针: 编程简单,执行耗时 182 | 183 | Hash表 - hash数据结构的线性表: 减少目录搜索时间,碰撞,固定大小 184 | 185 | 名字解析: 逻辑名字转换成物理资源(如文件)的过程: 186 | 187 | 在文件系统中: 到实际文件的文件名(路径) 188 | 189 | 遍历文件目录直到找到目标文件 190 | 191 | 举例: 解析"/bin/ls": 192 | 193 | 读取root的文件头(在磁盘固定位置) 194 | 195 | 读取root的数据块: 搜索bin项 196 | 197 | 读取bin的文件头 198 | 199 | 读取bin的数据块: 搜索ls项 200 | 201 | 读取ls的文件头 202 | 203 | 当前工作目录: 204 | 205 | 每个进程都会指向一个文件目录用于解析文件名 206 | 207 | 允许用户指定相对路径来代替绝对路径 208 | 209 | 一个文件系统需要先挂载才能被访问 210 | 211 | 一个未挂载的文件系统被挂载在挂载点上 212 | 213 | ### 文件别名 214 | 215 | 两个或多个文件名关联同一个文件: 216 | 217 | 硬链接: 多个文件项指向一个文件 218 | 219 | 软链接: 以快捷方式指向其他文件 220 | 221 | 通过存储真实文件的逻辑名称来实现 222 | 223 | 如果删除一个有别名的文件会如何呢? : 这个别名将成为一个悬空指针 224 | 225 | Backpointers 方案: 226 | 227 | 每个文件有一个包含多个backpointers的列表,所以删除所有的Backpointers 228 | 229 | backpointers使用菊花链管理 230 | 231 | 添加一个间接层: 目录项数据结构 232 | 233 | 链接: 已存在文件的另外一个名字(指针) 234 | 235 | 链接处理: 跟随指针来定位文件 236 | 237 | 我们如何保证没有循环呢? 238 | 239 | 只允许到文件的链接, 不允许在子目录的链接 240 | 241 | 每增加一个新的链接都用循环检测算法确定是否合理 242 | 243 | 限制路径可遍历文件目录的数量 244 | 245 | ### 文件系统种类 246 | 247 | 磁盘文件系统: 文件存储在数据存储设备上,如磁盘; 例如: FAT,NTFS,ext2,3,ISO9660等 248 | 249 | 数据库文件系统: 文件根据其特征是可被寻址的; 例如: WinFS 250 | 251 | 日志文件系统: 记录文件系统的修改,事件; 例如: journaling file system 252 | 253 | 网络,分布式文件系统: 例如: NFS,SMB,AFS,GFS 254 | 255 | 特殊,虚拟文件系统 256 | 257 | ## 虚拟文件系统 258 | 259 | 分层结构: 260 | 261 | 顶层: 文件,文件系统API 262 | 263 | 上层: 虚拟(逻辑)文件系统 (将所有设备IO,网络IO全抽象成为文件,使得接口一致) 264 | 265 | 底层: 特定文件系统模块 266 | 267 | 目的: 对所有不同文件系统的抽象 268 | 269 | 功能: 270 | 271 | 提供相同的文件和文件系统接口 272 | 273 | 管理所有文件和文件系统关联的数据结构 274 | 275 | 高效查询例程,遍历文件系统 276 | 277 | 与特定文件系统模块的交互 278 | 279 | 数据结构: 280 | 281 | 卷[第四声]控制块(UNIX: "superblock") 282 | 283 | 每个文件系统一个 284 | 285 | 文件系统详细信息 286 | 287 | 块,块大小,空余块,计数,指针等 288 | 289 | 文件控制块(UNIX: "vnode" or "inode") 290 | 291 | 每个文件一个 292 | 293 | 文件详细信息 294 | 295 | 许可,拥有者,大小,数据库位置等 296 | 297 | 目录节点(Linux: "dentry") 298 | 299 | 每个目录项一个(目录和文件) 300 | 301 | 将目录项数据结构及树形布局编码成树形数据结构 302 | 303 | 指向文件控制块,父节点,项目列表等 304 | 305 | 其中: 卷控制块(每个文件系统一个),文件控制块(每个文件一个),目录节点(每个目录项一个) 306 | 307 | 持续存储在二级存储中: 在分配在存储设备中的数据块中 308 | 309 | 当需要时加载进内存: 310 | 311 | 卷控制块: 当文件系统挂载时进入内存 312 | 313 | 文件控制块: 当文件被访问时进入内存 314 | 315 | 目录节点: 在遍历一个文件路径时进入内存 316 | 317 | ## 数据块缓存 318 | 319 | 数据块按需读入内存: 320 | 321 | 提供 `read()` 操作 322 | 323 | 预读: 预先读取后面的数据块 324 | 325 | 数据块使用后被缓存: 326 | 327 | 假设数据将会再次被使用 328 | 329 | 写操作可能被缓存和延迟写入 330 | 331 | 两种数据块缓存方式: 332 | 333 | 普通缓冲区缓存 334 | 335 | 页缓存: 同一缓存数据块和内存页 336 | 337 | 分页要求: 当需要一个页时才将其载入内存 338 | 339 | 支持存储: 一个页(在虚拟地址空间中)可以被映射到一个本地文件中(在二级存储中) 340 | 341 | ## 打开文件的数据结构 342 | 343 | 打开文件描述: 344 | 345 | 每个被打开的文件一个 346 | 347 | 文件状态信息 348 | 349 | 目录项,当前文件指针,文件操作设置等 350 | 351 | 打开文件表: 352 | 353 | 一个进程一个 354 | 355 | 一个系统级的 356 | 357 | 每个卷控制块也会保存一个列表 358 | 359 | 所以如果有文件被打开将不能被卸载 360 | 361 | 一些操作系统和文件系统提供该功能 362 | 363 | 调节对文件的访问 364 | 365 | 强制和劝告: 366 | 367 | 强制 - 根据锁保持情况和需求拒绝访问 368 | 369 | 劝告 - 进程可以查找锁的状态来决定怎么做 370 | 371 | ## 文件分配 372 | 373 | 大多数文件都很小: 374 | 375 | 需要对小文件提供强力的支持 376 | 377 | 块空间不能太小 378 | 379 | 一些文件非常大: 380 | 381 | 必须支持大文件(64-bit 文件偏移) 382 | 383 | 大文件访问需要相当高效 384 | 385 | 如何为一个文件分配数据块 386 | 387 | 分配方式: 388 | 389 | 连续分配 390 | 391 | 链式分配 392 | 393 | 索引分配 394 | 395 | 指标: 396 | 397 | 高效: 如存储利用(外部碎片) 398 | 399 | 表现: 如访问速度 400 | 401 | 连续分配: 402 | 403 | 文件头指定起始块和长度 404 | 405 | 位置,分配策略: 最先匹配,最佳匹配,... 406 | 407 | 优势: 文件读取表现好;高效的顺序和随机访问 408 | 409 | 劣势: 碎片;文件增长问题 410 | 411 | 链式分配: 412 | 413 | 文件以数据块链表方式存储 414 | 415 | 文件头包含了到第一块和最后一块的指针 416 | 417 | 优势: 创建,增大,缩小很容易;没有碎片 418 | 419 | 劣势: 不可能进行真正的随机访问;可靠性 420 | 421 | 索引分配: 422 | 423 | 为每个文件创建一个名为索引数据块的非数据数据块(到文件数据块的指针列表) 424 | 425 | 文件头包含了索引数据块 426 | 427 | 优势: 创建,增大,缩小很容易;没有碎片;支持直接访问 428 | 429 | 劣势: 当文件很小时,存储索引的开销大;处理大文件难 430 | 431 | ## 空闲空间列表 432 | 433 | 跟踪在存储中的所有未分配的数据块 434 | 435 | 空闲空间列表存储在哪里? 436 | 437 | 空闲空间列表的最佳数据结构怎么样? 438 | 439 | 用位图代表空闲数据块列表: 11111101101110111 如果 i = 0表明数据块i是空闲的,反之是分配的 440 | 441 | 使用简单但是可能会是一个big vector: 442 | 443 | 160GB disk → 40M blocks → 5MB worth of bits 444 | 445 | 然而,如果空闲空间在磁盘中均匀分布,那么再找到"0"之前需要扫描 磁盘上数据块总数 / 空闲块的数目 446 | 447 | 需要保护: 448 | 449 | 指向空闲列表的指针 450 | 451 | 位图: 452 | 453 | 必须保存在磁盘上;在内存和磁盘拷贝可能有所不同;不允许block[i]在内存中的状态为bit[i]=1而在磁盘中bit[i]=0 454 | 455 | 解决: 456 | 457 | 在磁盘上设置bit[i] = 1; 分配block[i]; 在内存中设置bit[i] = 1 458 | 459 | ## 多磁盘管理 - RAID 460 | 461 | 通常磁盘通过分区来最大限度减小寻道时间: 462 | 463 | 一个分区是一个柱面的集合 464 | 465 | 每个分区都是逻辑上独立的磁盘 466 | 467 | 分区: 硬件磁盘的一种适合操作系统指定格式的划分 468 | 469 | 卷: 一个拥有一个文件系统实例的可访问的存储空间(通常常驻在磁盘的单个分区上) 470 | 471 | 使用多个并行磁盘来增加: 吞吐量(通过并行),可靠性和可用性(通过冗余) 472 | 473 | RAID - 冗余磁盘阵列: 各种磁盘管理技术;RAID levels: 不同RAID分类,如RAID-0,RAID-1,RAID-5 474 | 475 | 实现: 在操作系统内核: 存储,卷管理; RAID硬件控制器(IO) 476 | 477 | RAID-0 478 | 479 | 数据块分成多个子块, 存储在独立的磁盘中: 和内存交叉相似 480 | 481 | 通过更大的有效块大小来提供更大的磁盘带宽 482 | 483 | RAID-1 484 | 485 | 可靠性成倍增长 486 | 487 | 读取性能线性增加(向两个磁盘写入,从任何一个读取) 488 | 489 | RAID-4 490 | 491 | 数据块级磁带配有专用奇偶校验磁盘: 允许从任意一个故障磁盘中恢复 492 | 493 | 条带化和奇偶校验按byte-by-byte或者bit-by-bit: RAID-0,4,5: block-wise ;RAID-3: bit-wise 494 | 495 | RAID-5 496 | 497 | 每个条带快有一个奇偶校验块,允许有一个磁盘错误 498 | 499 | RAID-6 500 | 501 | 两个冗余块,有一种特殊的编码方式,允许两个磁盘错误 502 | 503 | ## 磁盘调度 504 | 505 | 读取或写入时,磁头必须被定位在期望的磁道,并从所期望的扇区开始 506 | 507 | 寻道时间: 定位到期望的磁道所花费的时间 508 | 509 | 旋转延迟: 从扇区的开始处到到达目的处花费的时间 510 | 511 | 平均旋转延迟时间 = 磁盘旋转一周时间的一半 512 | 513 | 寻道时间是性能上区别的原因 514 | 515 | 对单个磁盘,会有一个IO请求数目 516 | 517 | 如果请求是随机的,那么会表现很差 518 | 519 | FIFO: 520 | 521 | 按顺序处理请求 522 | 523 | 公平对待所有进程 524 | 525 | 在有很多进程的情况下,接近随机调度的性能 526 | 527 | 最短服务优先: 528 | 529 | 选择从磁臂当前位置需要移动最少的IO请求 530 | 531 | 总是选择最短寻道时间 532 | 533 | skan: 534 | 535 | 磁臂在一个方向上移动,满足所有为完成的请求,直到磁臂到达该方向上最后的磁道 536 | 537 | 调换方向 538 | 539 | c-skan: 540 | 541 | 限制了仅在一个方向上扫描 542 | 543 | 当最后一个磁道也被访问过了后,磁臂返回到磁盘的另外一端再次进行扫描 544 | 545 | c-loop(c-skan改进): 546 | 547 | 磁臂先到达该方向上最后一个请求处,然后立即反转 548 | -------------------------------------------------------------------------------- /docs/Charpter 2.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第二章 2 | 3 | > 第二章的主要内容是 : 操作系统的异常/中断/系统调用 4 | 5 | ## 计算机探究计算机启动过程 6 | 7 | **作用解析** 8 | 9 | Disk : 存放OS和Bootloader 10 | 11 | BIOS : 基于I/O处理系统 12 | 13 | Bootloader : 加载OS，将OS放入内存 14 | 15 | **结构** 16 | 17 | Disk 18 | 19 | |___ OS 20 | 21 | |___ Bootloader 22 | 23 | **开机流程** 24 | 25 | 1. BIOS 26 | * 开机后，寻找显卡和执行BIOS (此时, `CS : IP = 0xF000 : 0xFFF0`, CS/IP 两个寄存器) 27 | * 将Bootloader从磁盘的引导扇区加载到0x7C00 (Bootloader一共占用512M字节的内存) 28 | * 跳转到 `CS : IP = 0x0000 : 0x7C00` 29 | 30 | 2. Bootloader 31 | * 将操作系统的代码和数据从硬盘加载到内存中 32 | * 跳转到操作系统的起始地址 33 | 34 | ## 中断、异常、系统调用 35 | 36 | ### 中断 37 | 38 | 中断来源于外设，来自不同的硬件设备的计时器和网络的中断。 39 | 40 | **中断流程** 41 | 42 | 硬件：设置中断标记（CPU初始化） 43 | 44 | 1. 将内部、外部事件设置中断标记 45 | 2. 中断事件的ID 46 | 47 | 软件 48 | 49 | 1. 保存当前处理状态（寄存器之类的一些数据） 50 | 2. 根据中断事件的ID跳转到中断服务程序，中断服务程序处理 51 | 3. 清楚中断标记 52 | 53 | ### 异常 54 | 55 | 异常来源于不良的应用程序，非法指令或者其他坏的处理状态（如：内存出错）。 56 | 57 | **异常处理流程** 58 | 59 | 1. 保存现场 60 | 2. 异常处理 61 | 1. 杀死了产生异常的程序 62 | 2. 重新执行异常指令 63 | 3. 恢复现场 64 | 65 | ### 系统调用 66 | 67 | 系统调用来源于应用程序，应用程序主动向操作系统发出服务请求。程序访问主要是通过高层次的API，而不是直接调用系统调用函数。 68 | 69 | **APIs** 70 | 71 | - Win32 API 用于Windows 72 | - POSIX API 用于 POSIX-based systems（包括UNIX，LINUX，Mac OS X） 73 | - Java API 用于JAVA虚拟机 74 | 75 | **特点** 76 | 77 | - 通常情况下，每个系统调用有对应的序号 78 | - 系统调用接口根据这些序号来维护表的索引 79 | - 系统调用接口调用内核态中预期的系统调用 80 | - 并返回系统调用的状态和其他任何返回值 81 | - 用户不需要知道系统调用是如何实现的 82 | - 只需要获取API和了解操作系统将什么作为返回结果 83 | - 操作系统接口的细节大部分都隐藏在API中 84 | 85 | **用户态**：操作系统运行中，CPU处于的特权级别，不能直接执行特权指令 86 | 87 | **内核态**：操作系统运行中，CPU处于的特权级别，可以执行任何一条指令 88 | 89 | **系统调用**：触发CPU从用户态到内核态的转换，切换程序和内核的堆栈，需要一定的开销 90 | 91 | **跨越操作系统边界的开销（值得的且必须的，保证了操作系统的安全性）** 92 | 93 | - 在执行时间上的开销超过程序调用 94 | - 开销： 95 | - 建立中断、异常、系统调用号与对应服务例程映射关系的初始化开销 96 | - 建立内核堆栈 97 | - 验证参数 98 | - 内核态映射到用户态的地址空间（更新页面映射权限） 99 | - 内核态独立地址空间（TLB） 100 | 101 | ### 区别 102 | 103 | | 类型 | 源头 | 处理时间 | 响应 | 104 | | -------- | ------------------------ | ---------- | -------------------- | 105 | | 中断 | 外设 | 异步 | 持续，对应用程序透明 | 106 | | 异常 | 应用程序意向不到的行为 | 同步 | 杀死或重新执行指令 | 107 | | 系统调用 | 应用程序请求系统提供服务 | 同步或异步 | 等待和持续 | 108 | 109 | > 异步：应用程序不知道什么时候会发生中断 110 | 111 | > 同步：执行到某一条指令一定会发生该事件 112 | 113 | ### 为什么应用程序不能直接访问硬件？ 114 | 115 | - 在计算机运行时，内核是被信任的第三方 116 | - 只有内核可以执行特权指令 117 | - 为了方便应用程序 118 | 119 | -------------------------------------------------------------------------------- /docs/Charpter 3.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第三章 2 | 3 | > 第三章的主要内容是：操作系统的物理内存管理 4 | 5 | ## 计算机体系结构 6 | 7 | 1. CPU 8 | 2. 内存 9 | 3. I/O 10 | 11 | ## 内存分层体系 12 | 13 | ### 内存分层体系 14 | 15 | 运行内存(主存) / 磁盘(虚拟内存). 主存是在运行程序时所需要保存的数据空间，而磁盘是用于持久化数据保存的数据空间. 16 | 17 | CPU可以访问的内存包括两大类 : 寄存器 / cache(L1缓存 / L2缓存) 18 | 19 | **层次** 20 | 21 | 微处理器(CPU访问) 22 | 23 | |___CPU寄存器 / L1缓存 24 | 25 | |___L2缓存 26 | 27 | 主存(程序访问) 28 | 29 | 磁盘(程序访问) 30 | 31 | > 从CPU寄存器到磁盘，读写速度不断降低，单位成本不断降低，大小不断增大。 32 | 33 | ### 内存管理目标 34 | 35 | * 抽象：逻辑地址空间 36 | 37 | * 保护：独立地址空间 38 | 39 | * 共享：访问相同内存 40 | 41 | * 虚拟：更多的地址空间 42 | 43 | ### 内存管理方法 44 | 45 | * 程序重定位 46 | * 分段 47 | * 分页 48 | * 虚拟内存 49 | * 按需分页虚拟内存 50 | 51 | > 实现高度依赖于硬件, 其中内存管理单元(MMU)负责处理CPU的内存访问请求 52 | 53 | ## 地址空间 54 | 55 | 地址空间的定义 56 | 57 | * 物理地址空间 —— 硬件支持的地址空间( address : [0, Max_sys] ) 58 | * 逻辑地址空间 —— 一个运行在程序所拥有的的内存范围( address : [0, Max_prog] ) 59 | 60 | ## 连续内存分配 61 | 62 | ### 内存碎片问题 63 | 64 | 内存碎片问题指的是空闲的内存无法被利用 65 | 66 | * 外部碎片 : 分配单元间的未使用内存 67 | * 内部碎片 : 分配单元内的未使用内存 68 | 69 | ### 分区的动态分配 70 | 71 | 分区的动态分配方式有以下三种 : 72 | 73 | 1. 第一匹配分配 : 在内存中找到第一个比需求大的空闲块, 分配给应用程序 74 | 2. 最优适配分配 : 在内存中找到最小的空闲块, 分配给应用程序 75 | 3. 最差适配分配 : 在内存中找到最大的空闲块, 分配给应用程序 76 | 77 | 分配方式的区别 78 | 79 | | 分配方式 | 第一匹配分配 | 最优适配分配 | 最差适配分配 | 80 | | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | 81 | | 分配方式实现需求 | 1. 按地址排序的空闲块列表
2. 分配需要寻找一个合适的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 1. 按尺寸排序的空闲块列表
2. 分配需要寻找一个合适的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 1. 按尺寸排序的空闲块列表
2. 分配最大的分区
3. 重分配需要检查是否可以合并相邻空闲分区 | 82 | | 优势 | 简单 / 易于产生更大空闲块 | 比较简单 / 大部分分配是小尺寸时高效 | 分配很快 / 大部分分配是中尺寸时高效 | 83 | | 劣势 | 产生外部碎片 / 不确定性 | 产生外部碎片 / 重分配慢 / 产生很多没用的微小碎片 | 产生外部碎片 / 重分配慢 / 易于破碎大的空闲块以致大分区无法被分配 | 84 | 85 | > 三种分配方式并无优劣之分，因为我们无法判断内存请求的大小 86 | 87 | ## 碎片整理方法 88 | 89 | 可以看到的是，三种分区动态分配的方式都会产生外部碎片，因此我们可以对碎片进行一定的整理来解决碎片问题。 90 | 91 | 1. 压缩式碎片整理 92 | * 重置程序以合并碎片 93 | * 要求所有程序是动态可重置的 94 | * 问题 : 95 | * 何时重置 ? (在程序处于等待状态时才可以重置) 96 | * 需要考虑内存拷贝的开销 97 | 98 | 2. 交换式碎片整理 99 | 100 | * 运行程序需要更多的内存时，抢占等待的程序并且回收它们的内存 101 | 102 | * 问题 : 103 | 104 | * 哪些程序应该被回收 ? 105 | 106 | * 情况 : 107 | 108 | 运行中 : P3 109 | 110 | 等待中 : P1 P2 P4 111 | 112 | 内存分布 -> 主存 : OS / P1 / P3 / P2 / P4 磁盘 : 空 113 | 114 | 当P3程序需要更大的内存时 -> 115 | 116 | 内存分布 -> 主存 : OS / P1 / P3 / P2 磁盘 : P4 117 | 118 | 119 | 120 | -------------------------------------------------------------------------------- /docs/Charpter 4.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第四章 2 | 3 | > 第四章的主要内容是：操作系统的非连续内存分配 4 | 5 | 第三章介绍的是连续内存管理, 即 : 操作系统加载到内存以及程序加载到内存中时, 分配一块连续的空闲(内存)块. 但是容易出现碎片问题, 这一章介绍的非连续内存分配可以有效的减少碎片的出现. 6 | 7 | ## 非连续内存分配的必要性 8 | 9 | ### 连续内存分配的缺点 10 | 11 | 1. 分配给一个程序的物理内存是连续的 12 | 2. 内存利用率低 13 | 3. 有外碎片 / 内碎片的问题 14 | 15 | ### 非连续内存分配的优点 16 | 17 | 1. 一个程序的物理地址空间是非连续的 18 | 19 | 2. 更好的内存利用和管理 20 | 21 | 3. 允许共享代码与数据(共享库等...) 22 | 23 | 4. 支持动态加载和动态链接 24 | 25 | ### 非连续内存分配的缺点 26 | 27 | 1. 建立虚拟地址和物理地址的转换难度大 28 | 29 | * 软件方案 30 | 31 | * 硬件方案(采用硬件方案) : 分段 / 分页 32 | 33 | ## 非连续内存分配 34 | 35 | ### 分段(Segmentation) 36 | 37 | **段 :** 在程序中会有来自不同文件的函数 ; 在程序执行时, 不同的数据也有不同的字段, 比如 : 堆 / 栈 / .bss / .data 等 38 | 39 | **分段 : **更好的分离和共享 40 | 41 | 程序的分段地址空间如下图所示 : 42 | 43 | 44 | 45 | **分段寻址方案** 46 | 47 | 逻辑地址空间连续，但是物理地址空间不连续，使用映射机制进行关联. 48 | 49 | 一个段 : 一个内存"块" 50 | 51 | 程序访问内存地址需要 : 一个二维的二元组(s, addr) → (段号, 地址) 52 | 53 | 操作系统维护一张段表, 存储(段号, 物理地址中的起始地址, 长度限制) 54 | 55 | 物理地址 : 段表中的起始地址 + 二元组中的偏移地址 56 | 57 | ### 分页(Paging) 58 | 59 | #### 分页地址空间 60 | 61 | 划分物理内存至固定大小的帧(Frame) 62 | 63 | - 大小是2的幂, 512 / 4096 / 8192 64 | 65 | 划分逻辑地址空间至相同大小的页(Page) 66 | 67 | - 大小是2的幂, 512 / 4096 / 8192 68 | 69 | 建立方案 → 转换逻辑地址为物理地址(pages to frames) 70 | 71 | - 页表 72 | - MMU / TLB 73 | 74 | **帧(Frame)** 75 | 76 | 物理内存被分割为大小相等的帧. 一个内存物理地址是一个二元组(f, o) → (帧号, 帧内偏移) 77 | 78 | 帧号 : F位, 共有2^F个帧 79 | 80 | 帧内偏移 : S位, 每帧有2^S个字节 81 | 82 | 物理地址 = 2^S * f + o 83 | 84 | (例子 : 16-bit地址空间, 9-bit(512 byte) 大小的页帧 物理地址 = (3,6) 物理地址 = 2^9 * 3 + 6 = 1542) 85 | 86 | > 分页和分段的最大区别 : 这里的 S 是一个固定的数, 而分段中的长度限制不定 87 | 88 | **页(Page)** 89 | 90 | 一个程序的逻辑地址空间被划分为大小相等的页. 页内偏移的大小 = 帧内偏移的大小 页号大小 <> 帧号大小 91 | 92 | 一个逻辑地址是一个二元组(p, o) → (页号, 页内偏移) 93 | 94 | 页号 : P位, 共有2^P个页 95 | 96 | 页内偏移 : S位, 每页有2^S个字节 97 | 98 | 虚拟地址 = 2^S * p + o 99 | 100 | #### 页寻址方案 101 | 102 | 操作系统维护一张页表, 页表保存了逻辑地址——物理地址之间的映射关系 103 | 104 | 存储 : (页号, 帧号) 105 | 106 | - 逻辑地址空间应当大于物理内存空间 107 | - 页映射到帧 108 | - 页是连续的虚拟内存 109 | - 帧是非连续的物理内存(有助于减少碎片的产生) 110 | - 不是所有的页都有对应的帧 111 | 112 | ### 页表(Page Table) 113 | 114 | #### 页表概述 115 | 116 | 每一个运行的程序都有一个页表 117 | 118 | - 属于程序运行状态, 会动态变化 119 | - PTBR : 页表基址寄存器 120 | 121 | **转换流程** 122 | 123 | CPU根据程序的page的页号的若干位, 计算出索引值index, 在页表中搜索这个index, 得到的是帧号, 帧号和原本的offset组成物理地址. 124 | 125 | 页表中还有一些特殊标志位 126 | 127 | - dirty bit, 128 | - resident bit, (0 : 对应的物理页帧在内存中不存在 ; 1 : 存在) 129 | - clock / reference bit 130 | 131 | **转换实例** 132 | 133 | 16位地址的系统 134 | 135 | - 32KB的物理内存 136 | - 每页的 1024 byte 137 | 138 | 逻辑地址空间 : (4, 0) ... (3, 1023) 139 | 140 | 页表 : 141 | 142 | Flags | Frame nums 143 | 144 | 1 0 1 0 0 0 0 0 → 内存访问异常(可能要杀死程序) 145 | 146 | 0 1 1 0 0 1 0 0 → 页帧是4 偏移是 1023 → 物理地址 (4, 1023) 147 | 148 | #### 分页机制的性能问题 149 | 150 | 访问一个内存单元需要2次内存访问 151 | 152 | - 一次用于获取页表项 153 | - 一次用于访问数据 154 | 155 | 页表可能非常大 156 | 157 | - 64位机器如果每页1024字节, 那么一个页表的大小会是多少？(2^64 / 2^10 = 2^54 存放不下) 158 | - 每一个运行的程序都需要有一个页表 159 | 160 | 如何处理？ 161 | 162 | - 缓存(Caching) 163 | - 间接(Indirection)访问 164 | 165 | #### 转换后备缓冲区(TLB) 166 | 167 | 缓解时间问题 168 | 169 | Translation Look-aside Buffer(TLB) 是一个缓冲区. CPU中有快表TLB(可以将经常访问的页表存放在这边) 170 | 171 | 缓存近期访问的页帧转换表项 172 | 173 | - TLB使用关联内存实现, 具备快速访问性能 174 | - 如果TLB命中, 物理页号可以很快被获取 175 | - 如果TLB未命中, 对应的表项被更新到TLB中(x86的CPU由硬件实现, 其他的可能是由操作系统实现) 176 | 177 | #### 二级/多级页表 178 | 179 | 时间换空间 180 | 181 | 二级页表 182 | 183 | - 将页号分为两个部分, 页表分为两个, 一级页号对应一级页表, 二级页号对应二级页表. 184 | - 一级页号查表获得在二级页表的起始地址, 地址加上二级页号的值, 在二级页表中获得帧号 185 | - 节约了一定的空间, 在一级页表中如果resident bit = 0, 可以使得在二级页表中不存储相关index,而只有一张页表的话, 这一些index都需要保留 186 | 187 | 多级页表 188 | 189 | - 通过把页号分为k个部分, 来实现多级间接页表, 建立一棵页表"树" 190 | 191 | #### 反向页表 192 | 193 | 解决大地址空间问题 194 | 195 | 目的 : 根据帧号获得页号 196 | 197 | 反向页表只需要存在一张即可 198 | 199 | - 有大地址空间(64-bits), 前向映射页表变得繁琐. 比如 : 使用了5级页表 200 | - 不是让页表与逻辑地址空间的大小相对应, 而是当页表与物理地址空间的大小相对应. 逻辑地址空间增长速度快于物理地址空间 201 | 202 | ##### 基于页寄存器(Page Registers)的方案 203 | 204 | 存储 (帧号, 页号) 使得表大小与物理内存大小相关, 而与逻辑内存关联减小. 205 | 206 | 每一个帧和一个寄存器关联, 寄存器内容包括 : 207 | 208 | - resident bit : 此帧是否被占用 209 | - occupier : 对应的页号 p 210 | - protection bits : 保护位 211 | 212 | 实例 : 213 | 214 | - 物理内存大小是 : 4096 * 4096 = 4K * 4KB = 16 MB 215 | - 页面大小是 : 4096 bytes = 4 KB 216 | - 页帧数 : 4096 = 4 K 217 | - 页寄存器使用的空间(假设8 bytes / register) : 8 * 4096 = 32 Kbytes 218 | - 页寄存器带来的额外开销 : 32K / 16M = 0.2% 219 | - 虚拟内存大小 : 任意 220 | 221 | 优势 : 222 | 223 | - 转换表的大小相对于物理内存来说很小 224 | - 转换表的大小跟逻辑地址空间的大小无关 225 | 226 | 劣势 : 227 | 228 | - 需要的信息对调了, 即根据帧号可以找到页号 229 | - 如何转换回来? (如何根据页号找到帧号) 230 | - 在需要在反向页表中搜索想要的页号 231 | 232 | ##### 基于关联内存(associative memory)的方案 233 | 234 | 硬件设计复杂, 容量不大, 需要放置在CPU中 235 | 236 | - 如果帧数较少, 页寄存器可以被放置在关联内存中 237 | - 在关联内存中查找逻辑页号 238 | - 成功 : 帧号被提取 239 | - 失败 : 页错误异常 (page fault) 240 | - 限制因素: 241 | - 大量的关联内存非常昂贵(难以在单个时钟周期内完成 ; 耗电) 242 | 243 | ##### 基于哈希(hash)的方案 244 | 245 | 哈希函数 : h(PID, p) 从 PID 标号获得页号 246 | 247 | 在反向页表中通过哈希算法来搜索一个页对应的帧号 248 | 249 | - 对页号做哈希计算, 为了在帧表中获取对应的帧号 250 | - 页 i 被放置在表 f(i) 位置, 其中 f 是设定的哈希函数 251 | - 为了查找页 i , 执行下列操作 : 252 | - 计算哈希函数 f(i) 并且使用它作为页寄存器表的索引, 获取对应的页寄存器 253 | - 检查寄存器标签是否包含 i, 如果包含, 则代表成功, 否则失败 254 | 255 | -------------------------------------------------------------------------------- /docs/Charpter 5.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第五章 2 | 3 | > 第五章的主要内容是：操作系统的虚拟内存管理技术 4 | 5 | ## 虚拟内存的起因 6 | 7 | 使用硬盘/磁盘使更多的程序在有限的内存中运行 8 | 9 | 理想的存储器 : 更大更快更便宜和非易失性的存储区 10 | 11 | ## 覆盖技术 12 | 13 | 如果是程序太大, 超出了内存的容量, 可以采用手动的概率(overlay)技术, 只把需要的指令和数据保存在内存当中 14 | 15 | 目的 : 是在较小的可用内存中运行较大的程序, 常用于多道程序系统, 与分区存储管理配合使用. 16 | 17 | 原理 : 18 | 19 | 把程序按照其自身逻辑结构, 划分为若干个功能上相互独立的程序模块, 那些不会同时执行的模块共享同一块内存区域, 按时间先后来运行. 20 | 21 | - 必要部分(常用功能)的代码和数据常驻内存; 22 | - 可选部分(不常用功能)在其他程序模块中实现, 平时存放在外存中, 在需要用到时才装入内存; 23 | - 不存在调用关系的模块不必同时装入到内存, 从而可以相互覆盖, 即这些模块共用一个分区. 24 | 25 | > 也就是说,程序松耦合的部分可以按需装入内存,不需要的时候放在外存中,多个不常用部分共用一个分区. 26 | 27 | 实例 : 28 | 29 | A(20k) ____B(50k) ____ D(30k) 30 | | ____ C(30k) ____ E(20k) 31 | |____ F(40k) 32 | 33 | 因此不需要将整个程序190k的数据全部放入内存中, 而是划分为 常驻区(20k) 覆盖区0(50k) 覆盖区1(40k) 压缩至了110k的内存空间使用 34 | 35 | 缺点 : 36 | 37 | - 由程序员来把一个大的程序划分为若干个小的功能模块, 并确定各个模块之间的覆盖关系, 费时费力, 增加了编程的复杂度; 38 | - 覆盖模块并从外存装入内存, 实际上是以时间延长来换取空间节省. 39 | 40 | ## 交换技术 41 | 42 | 如果是程序太多, 超过了内存的容量, 可以采用自动的交换(swapping)技术, 把暂时不能执行的程序送到外存中 43 | 44 | 目的 : 多道程序在内存时, 让正在运行的程序或需要运行的程序获得更多的内存资源 45 | 46 | 原理 : 47 | 48 | 可将暂时不能运行的程序送到外存, 从而获得空闲内存空间. 操作系统把一个进程的整个地址空间的内容保存到外存中(换出 swap out), 而将外存中的某个进程的地址空间读入到内存中(换入 swap in). 换入换出内容的大小为整个程序的地址空间. 49 | 50 | 存在问题 : 51 | 52 | - 交换时机的确定 : 何时需要发生交换? 只当内存空间不够或有不够的危险时换出; 53 | - 交换区的大小 : 必须足够大以存放所有用户进程的所有内存映像的拷贝, 必须能够对这些内存映像进行直接存取 54 | - 程序换入时的重定位 : 换出后再换入的内存位置一定要在原来的位置上嘛?(可能出现寻址问题) 最好采用动态地址映射的方法 55 | 56 | ## 覆盖技术和交换技术的对比 57 | 58 | 特点 : 59 | 60 | - 覆盖只能发生在那些相互之间没有调用关系的程序模块之间, 因此程序员必须给出程序内的各个模块之间的逻辑覆盖结构. 61 | - 交换技术是以在内存中的程序大小为单位进行的, 它不需要程序员给出各个模块之间的逻辑覆盖结构. 62 | - 换言之, 交换发生在内存中程序与管理程序或操作系统之间, 而覆盖则发生在运行程序的内部. 63 | 64 | 在内存不够用的情形下, 可以采用覆盖技术和交换技术, 但是 : 65 | 66 | - 覆盖技术 : 需要程序要自己把整个程序划分为若干个小的功能模块, 并确定各个模块之间的覆盖关系, 增加了程序员的负担. 67 | - 交换技术 : 以进程作为交换的单位, 需要把进程的整个地址空间都换入换出, 增加了处理器的开销. 68 | 69 | ## 虚拟内存管理技术 70 | 71 | 如果想要在有限容量的内存中, 以更小的页粒度为单位装入更多更大的程序, 可以采用自动的虚拟存储技术 72 | 73 | - 目标 74 | 75 | 像覆盖技术那样, 不是把程序的所有内容都放在内存中, 因而能够运行比当前的空闲内存空间还要大的程序. 但做的更好, 由操作系统自动来完成, 无需程序员的干涉. 76 | 77 | 像交换技术那样, 能够实现进程在内存与外存之间的交换, 因而获得更多的空闲内存空间. 但做的更好, 只对进程的部分内容在内存和外存之间进行交换. 78 | 79 | - 程序局部性原理 80 | 81 | 程序的局部性原理(principle of locality) : 指程序在执行过程中的一个较短时期, 所执行的指令地址和指令的操作数地址, 分别局限于一定的区域. 82 | 83 | - 时间局部性 : 一条指令的一次执行和下次执行, 一个数据的一次访问和下次访问都集中在一个较短时期内 ; 84 | - 空间局部性 : 当前指令和邻近的几条指令, 当前访问的数据和邻近的几个数据都集中在一个较小区域内. 85 | 86 | 程序的局部性原理表明, 从理论上来说, 虚拟存储技术是能够实现的. 而且在实现了以后应该是能够取得一个满意的效果. 87 | 88 | 实例 : 89 | 90 | ```cpp 91 | 题目描述 : 92 | 页面大小为4k, 分配给每个进程的物理页面是1. 93 | 在一个进程中, 定义了如下的二维数组 int A[1024][1024]. 该数组按行存放在内存, 每一行放在一个页面中. 94 | 考虑一下程序的编写方法对缺页率的影响? 95 | 96 | 程序编写方法1 : (发生了1024*1024次缺页中断) 97 | for(j = 0; j < 1024; j++) 98 | for(i = 0; i < 1024; i++) 99 | A[i][j] = 0; 100 | 101 | 程序编写方法2 : (发生了1024次缺页中断) 102 | for(i = 0; i < 1024; i++) 103 | for(j = 0; j < 1024; j++) 104 | A[i][j] = 0; 105 | ``` 106 | 107 | - 基本概念 108 | 109 | 可以在页式或段式内存管理的基础上实现 110 | 111 | - 在装入程序时, 不必将其全部装入内存, 而只需将当前需要执行的部分页面或段装入到内存中, 就可以让程序开始执行; 112 | - 在程序执行过程中, 如果需执行的指令或访问的数据尚未在内存中(称为缺页或缺段), 则由处理器通知操作系统将相应的页面或段调入到内存, 然后继续执行程序; 113 | - 另一方面, 操作系统将内存中暂时不使用的页面或段调出保存在外存上, 从而腾出更多空闲内存空间存放将要装入的程序以及将要调入的页面或段. 114 | 115 | - 基本特征 116 | 117 | - 大的用户空间 : 通过把物理内存和外存相结合, 提供给用户的虚拟内存空间通常大于实际的物理内存, 即实现了这两者的分离. 如32位的虚拟地址理论上可以访问4GB, 而可能计算机上仅有256M的物理内存, 但硬盘容量大于4GB. 118 | - 部分交换 : 与交换技术相比较, 虚拟存储的调入和调出是对部分虚拟地址空间进行的; 119 | - 不连续性 : 物理内存分配的不连续性, 虚拟地址空间使用的不连续性. 120 | 121 | - 虚拟页式内存管理 122 | 123 | 页式内存管理 124 | 125 | 页表 : 完成逻辑页到物理页帧的映射 126 | 127 | 根据页号去页表中寻找索引, 先查看 resident bit 是否为0, 0表示不存在, 1表示映射关系存在, 获得帧号加上原本的偏移, 获得了物理地址. 128 | 129 | 虚拟页式内存管理 130 | 131 | - 大部分虚拟存储系统都采用虚拟页式存储管理技术, 即在页式存储管理的基础上, 增加请求调页和页面置换功能. 132 | 133 | - 基本思路 134 | 135 | - 当一个用户程序要调入内存运行时, 不是将该程序的所有页面都装入内存, 而是只装入部分的页面, 就可启动程序运行. 136 | - 在运行的过程中, 如果发现要运行的程序或要访问的数据不再内存, 则向系统发出缺页的中断请求, 系统在处理这个中断时, 将外存中相应的页面调入内存, 使得该程序能够继续运行. 137 | 138 | - 页表表项 139 | 140 | 逻辑页号 | 访问位 | 修改位 | 保护位 | 驻留位 | 物理页帧号 141 | 142 | 驻留位 : 表示该页是在内存中还是在外存. 143 | 144 | 保护位 : 表示允许对该页做何种类型的访问, 如只读, 可读写, 可执行等 145 | 146 | 修改位 : 表示此页在内存中是否被修改过. 当系统回收该物理页面时, 根据此位来决定是否把它的内容写回外存 147 | 148 | 访问位 : 如果该页被访问过(包括读写操作), 则设置此位. 用于页面置换算法. 149 | 150 | - 缺页中断处理过程 : 151 | 152 | 1. 如果在内存中有空闲的物理页面, 则分配一物理页帧f, 然后转第4步; 否则转到第2步; 153 | 2. 采用某种页面置换算法, 选择一个将被替换的物理页帧f, 它所对应的逻辑页为q, 如果该页在内存期间被修改过, 则需要把它写回外存; 154 | 3. 对q所对应的页表项修改, 把驻留位置为0; 155 | 4. 将需要访问的页p装入到物理页面f当中; 156 | 5. 修改p所对应的页表项的内容, 把驻留位置为1, 把物理页帧号置为f; 157 | 6. 重新运行被中断是指令. 158 | 159 | > 在何处保存未被映射的页? 160 | > 161 | > - 能够简单地识别在二级存储器中的页 162 | > - 交换空间(磁盘或者文件) : 特殊格式, 用于存储未被映射的页面 163 | 164 | 后备存储(二级存储) : 165 | 166 | - 一个虚拟地址空间的页面可以被映射到一个文件(在二级存储中)的某个位置 167 | - 代码段 : 映射到可执行二进制文件 168 | - 动态加载的共享库程序段 : 映射到动态调用的库文件 169 | - 其他段 : 可能被映射到交换文件(swap file) 170 | 171 | - 虚拟内存性能 172 | 173 | 为了便于理解分页的开销, 使用有效存储器访问时间 effective memory access time (EAT) 174 | 175 | EAT = 访存时间 * 页表命中几率 + page fault处理时间 * page fault几率 176 | 177 | 实例 : 178 | 179 | 访存时间 : 10 ns 180 | 181 | 磁盘访问时间 : 5 ms 182 | 183 | 参数 p = page fault 几率 184 | 185 | 参数 q = dirty page 几率(对页面写操作) 186 | 187 | EAT = 10\*(1-p) + 5000000\*p\*(1+q) 188 | 189 | -------------------------------------------------------------------------------- /docs/Charpter 6.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第六章 2 | 3 | > 第六章的主要内容是：操作系统的虚拟内存管理技术中的页面置换算法 4 | 5 | ## 功能与目标 6 | 7 | 功能 : 当缺页中断发生, 需要调入新的页面而内存已满时, 选择内存当中哪个物理页面被置换. 8 | 9 | 目标 : 尽可能地减少页面的换进换出次数(即缺页中断的次数). 具体来说, 把未来不再使用的或短期内较少使用的页面换出, 通常只能在局部性原理指导下依据过去的统计数据来进行预测. 10 | 11 | 页面锁定 : 用于描述必须常驻内存的操作系统的关键部分或时间关键的应用进程. 实现的方式是 : 在页表中添加锁定标记位(lock bit). 12 | 13 | ## 实验设置与评价方法 14 | 15 | 实例 : 16 | 17 | 记录一个进程对页访问的一个轨迹 18 | 19 | - 举例 : 虚拟地址跟踪(页号, 偏移)... 20 | - (3,0) (1,9) (4,1) (2,1) (5,3) (2,0) ... 21 | - 生成的页面轨迹 22 | - 3, 1, 4, 2, 5, 2, 1, ... 23 | 24 | 模拟一个页面置换的行为并且记录产生页缺失数的数量 25 | 26 | - 更少的缺失, 更好的性能 27 | 28 | ## 局部页面置换算法 29 | 30 | ### 最优页面置换算法 31 | 32 | 基本思路 : 当一个缺页中断发生时, 对于保存在内存当中的每一个逻辑页面, 计算在它的下一次访问之前, 还需等待多长时间, 从中选择等待时间最长的那个, 作为被置换的页面. 33 | 34 | 这是一种理想情况, 在实际系统中是无法实现的, 因为操作系统无法知道每一个页面要等待多长时间以后才会再次被访问. 35 | 36 | 可用作其他算法的性能评价的依据.(在一个模拟器上运行某个程序, 并记录每一次的页面访问情况, 在第二遍运行时即可使用最优算法) 37 | 38 | ### 先进先出算法 39 | 40 | 基本思路 : 选择在内存中驻留时间最长的页面淘汰. 具体来说, 系统维护着一个链表, 记录了所有位于内存当中的逻辑页面. 从链表的排列顺序来看, 链首页面的驻留时间最长, 链尾页面的驻留时间最短. 当发生一个缺页中断时, 把链首页面淘汰出去, 并把新的页面添加到链表的末尾. 41 | 42 | 性能较差, 调出的页面有可能是经常要访问的页面. 并且有 belady现象. FIFO算法很少单独使用. 43 | 44 | ### 最近最久未使用算法 45 | 46 | LRU(Least Recently Used) 47 | 48 | 基本思路 : 当一个缺页中断发生时, 选择最久未使用的那个页面, 并淘汰. 49 | 50 | 它是对最优页面置换算法的一个近似, 其依据是程序的局部性原理, 即在最近一小段时间(最近几条指令)内, 如果某些页面被频繁地访问, 那么再将来的一小段时间内, 他们还可能会再一次被频繁地访问. 反过来说, 如果过去某些页面长时间未被访问, 那么在将来它们还可能会长时间地得不到访问. 51 | 52 | LRU算法需要记录各个页面使用时间的先后顺序, 开销比较大. 53 | 54 | 两种可能的实现方法是 : 55 | 56 | - 系统维护一个页面链表, 最近刚刚使用过的页面作为首节点, 最久未使用的作为尾结点. 再一次访问内存时, 找出相应的页面, 把它从链表中摘下来, 再移动到链表首. 每次缺页中断发生时, 淘汰链表末尾的页面. 57 | - 设置一个活动页面栈, 当访问某页时, 将此页号压入栈顶, 然后, 考察栈内是否有与此页面相同的页号, 若有则抽出. 当需要淘汰一个页面时, 总是选择栈底的页面, 它就是最久未使用的. 58 | 59 | ### 时钟页面置换算法 60 | 61 | 基本思路 : 62 | 63 | 需要用到页表项的访问位, 当一个页面被装入内存时, 把该位初始化为0. 然后如果这个页面被访问, 则把该位置设为1; 64 | 65 | 把各个页面组织成环形链表(类似钟表面), 把指针指向最老的页面(最先进来); 66 | 67 | 当发生一个缺页中断时, 考察指针所指向的最老页面, 若它的访问位为0, 立即淘汰; 若访问位为0, 然后指针往下移动一格. 如此下去, 直到找到被淘汰的页面, 然后把指针移动到下一格. 68 | 69 | 流程 : 70 | 71 | 如果访问页在物理内存中, 访问位置1. 72 | 73 | 如果不在物理页, 从指针当前指向的物理页开始, 如果访问位0, 替换当前页, 指针指向下一个物理页; 如果访问位为1, 置零以后访问下一个物理页再进行判断. 如果所有物理页的访问位都被清零了, 又回到了第一次指针所指向的物理页进行替换. 74 | 75 | ### 二次机会算法 76 | 77 | 因为考虑到时钟页面置换算法, 有时候会把一些 dirty bit 为1(有过写操作)的页面进行置换, 这样的话, 代价会比较大. 因此, 可以结合访问位和脏位一起来决定应该置换哪一页. 78 | 79 | used dirty → used dirty 80 | 81 | 0 0 replace 82 | 83 | 0 1 0 0 84 | 85 | 1 0 0 0 86 | 87 | 1 1 0 1 88 | 89 | 相当于说, 替换的优先级, 没有读写也没写过, 那么直接走, 如果写过或者访问过, 那么给你一次机会, 如果又写过, 又访问过, 那么久给你两次机会. 90 | 91 | ### 最不常用算法 92 | 93 | Least Frequently used, LFU 94 | 95 | 基本思路 : 当一个缺页中断发生时, 选择访问次数最少的那个页面, 并淘汰. 96 | 97 | 实现方法 : 对每一个页面设置一个访问计数器, 每当一个页面被访问时, 该页面的访问计数器加1. 当发生缺页中断时, 淘汰计数值最小的那个页面. 98 | 99 | LRU和LFU的对比 : LRU考察的是多久未访问, 时间越短越好. 而LFU考察的是访问的次数和频度, 访问次数越多越好. 100 | 101 | ### Belady现象(科学家名字) 102 | 103 | 在采用FIFO算法时, 有时会出现分配的物理页面数增加, 缺页率反而提高的异常现象; 104 | 105 | 出现原因 : FIFO算法的置换特征与进程访问内存的动态特征是矛盾的, 与置换算法的目标是不一致的(即替换较少使用的页面), 因此, 被他置换出去的页面不一定是进程不会访问的. 106 | 107 | ### LRU / FIFO 和 Clock 的比较 108 | 109 | LRU和FIFO都是先进先出的思路, 只不过LRU是针对页面最近访问时间来进行排序, 所以需要在每一次页面访问的时候动态地调整各个页面之间的先后顺序(有一个页面的最近访问时间变了). 而FIFO是针对页面进入内存的时间来进行排序, 这个时间是固定不变的, 所以各个页面之间的先后顺序是固定的. 如果一个页面在进入内存后没有被访问, 那么它的最近访问时间就是它进入内存的时间. 换句话说, 如果内存当中的所有页面都未曾访问过, 那么LRU算法就退化为了FIFO算法. 110 | 111 | 例如 : 给进程分配3个物理页面, 逻辑页面的访问顺序是 : 1,2,3,4,5,6,1,2,3 ... 112 | 113 | ## 全局页面置换算法 114 | 115 | ### 工作集模型 116 | 117 | 前面介绍的各种页面置换算法, 都是基于一个前提, 即程序的局部性原理. 但是此原理是否成立? 118 | 119 | - 如果局部性原理不成立, 那么各种页面置换算法就没有说明分别, 也没有什么意义. 例如 : 假设进程对逻辑页面的访问顺序是1,2,3,4,5,6,6,7,8,9..., 即单调递增, 那么在物理页面数有限的前提下, 不管采用何种置换算法, 每次的页面访问都必然导致缺页中断. 120 | - 如果局部性原理是成立的, 那么如何来证明它的存在, 如何来对它进行定量地分析? 这就是工作集模型. 121 | 122 | ### 工作集 123 | 124 | 工作集 : 一个进程当前正在使用的逻辑页面集合. 125 | 126 | 可以使用一个二元函数 W(t, delta) 来表示 : 127 | 128 | t 是当前的执行时刻; 129 | 130 | delta 称为工作集窗口, 即一个定长的页面访问的时间窗口; 131 | 132 | W(t, delta) = 在当前时刻 t 之前的 delta 时间窗口当中的所有页面所组成的集合(随着 t 的变化, 该集合也在不断的变化) 133 | 134 | |W(t, delta)| 是工作集的大小, 即逻辑页的数量. 135 | 136 | 工作集大小的变化 : 进程开始执行后, 随着访问新页面逐步建立较稳定的工作集. 当内存访问的局部性区域的位置大致稳定时, 工作集大小也大致稳定; 局部性区域的位置改变时, 工作集快速扩张和收缩过渡到下一个稳定值. 137 | 138 | ### 常驻集 139 | 140 | 常驻集是指在当前时刻, 进程实际驻留在内存当中的页面集合. 141 | 142 | - 工作集是进程在运行过程中固有的性质, 而常驻集取决于系统分配给进程的物理页面数目, 以及所采用的页面置换算法; 143 | - 如果一个进程的整个工作集都在内存当中, 即常驻集 包含 工作集, 那么进程将很顺利地运行, 而不会造成太多的缺页中断(直到工作集发生剧烈变动, 从而过渡到另一个状态); 144 | - 当进程常驻集的大小达到某个数目之后, 再给它分配更多的物理页面, 缺页率也不会明显下降. 145 | 146 | ### 工作集页置换算法 147 | 148 | 当工作集窗口在滑动过程中, 如果页面不在集合中, 那么就会直接丢失这个不在窗口中页面, 而不会等待缺页中断再丢弃. 149 | 150 | ### 缺页率置换算法 151 | 152 | 可变分配策略 : 常驻集大小可变. 例如 : 每个进程在刚开始运行的时候, 先根据程序大小给它分配一定数目的物理页面, 然后在进程运行过程中, 再动态地调整常驻集的大小. 153 | 154 | - 可采用全局页面置换的方式, 当发生一个缺页中断时, 被置换的页面可以是在其他进程当中, 各个并发进程竞争地使用物理页面. 155 | - 优缺点 : 性能较好, 但增加了系统开销. 156 | - 具体实现 : 可以使用缺页率算法来动态调整常驻集的大小. 157 | 158 | 缺页率 : 表示 "缺页次数 / 内存访问次数" 159 | 160 | 影响因素 : 页面置换算法, 分配给进程的物理页面数目, 页面本身的大小, 程序的编写方法. 161 | 162 | ### 抖动问题 163 | 164 | - 如果分配给一个进程的物理页面太少, 不能包含整个的工作集, 即常驻集 属于 工作集, 那么进程将会造成很多的缺页中断, 需要频繁的在内存与外存之间替换页面, 从而使进程的运行速度变得很慢, 我们把这种状态称为 "抖动". 165 | - 产生抖动的原因 : 随着驻留内存的进程数目增加, 分配给每个进程的物理页面数不断就减小, 缺页率不断上升. 所以OS要选择一个适当的进程数目和进程需要的帧数, 以便在并发水平和缺页率之间达到一个平衡. 166 | -------------------------------------------------------------------------------- /docs/Charpter 7.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第七章 2 | 3 | > 第七章的主要内容是：进程 4 | 5 | ## 进程(process)描述 6 | 7 | ### 进程定义 8 | 9 | 进程 : 一个具有一定独立功能的程序在一个数据集合上的一次动态执行过程. 10 | 11 | ### 进程的组成 12 | 13 | 进程包括 : 14 | 15 | - 程序的代码 16 | - 程序处理的数据 17 | - 程序计数器中的值, 指示下一条将运行的指令 18 | - 一组通用的寄存器的当前值, 堆, 栈 19 | - 一组系统资源(如打开的文件) 20 | 21 | 进程和程序的联系 : 22 | 23 | - 程序是产生进程的基础 24 | - 程序的每次运行构成不同的进程 25 | - 进程是程序功能的体现 26 | - 通过多次执行, 一个程序可以对应多个进程, 通过调用关系, 一个进程可包括多个程序. 27 | 28 | 进程和程序的区别 : 29 | 30 | - 进程是动态的, 程序是静态的 : 程序是有序代码的集合. 进程是程序的执行, 进程有核心态 / 用户态. 31 | - 进程是暂时的, 程序是永久的. 进程是一个状态变化的过程, 程序可以长久保存. 32 | - 进程和程序的组成不同 : 进程的组成包括程序, 数据和进程控制块(进程状态信息) 33 | 34 | ### 进程的特点 35 | 36 | **动态性** : 可动态地创建, 结果进程; 37 | 38 | **并发性** : 进程可以被独立调度并占用处理机运行; (并发:一段, 并行:一时刻) 39 | 40 | **独立性** : 不同进程的工作不相互影响;(页表是保障措施之一) 41 | 42 | **制约性** : 因访问共享数据, 资源或进程间同步而产生制约. 43 | 44 | > 抛出了一个问题 : 如果你要设计一个OS, 怎么样来实现其中的进程管理机制? 45 | > 46 | 47 | ### 进程控制结构 48 | 49 | 描述进程的数据结构 : 进程控制块 (Process Control Block) 50 | 51 | 操作系统为每个进程都维护了一个PCB, 用来保存与该进程有关的各种状态信息. 52 | 53 | **进程控制块 :** 操作系统管理控制进程运行所用的信息集合. 54 | 55 | 进程的创建 : 为该进程生成一个PCB 56 | 57 | **进程的终止 :** 回收它的PCB 58 | 59 | **进程的组织管理 :** 通过对PCB的组织管理来实现 60 | 61 | (PCB具体包含什么信息? 如何组织的? 进程的状态转换?) 62 | 63 | **PCB有以下三大类信息 :** 64 | 65 | - 进程标志信息. 如本进程的标志, 本进程的产生者标志(父进程标志). 用户标志 66 | - 处理机状态信息保存区 : 保存进程的运行现场信息 : 67 | - 用户可见寄存器. 用户程序可以使用的数据, 地址等寄存器 68 | - 控制和状态寄存器. 如程序计数器(PC), 程序状态字(PSW) 69 | - 栈指针. 过程调用, 系统调用, 中断处理和返回时需要用到它 70 | - 进程控制信息 71 | - 调度和状态信息. 用于操作系统调度进程并占用处理机使用. 72 | - 进程间通信信息. 为支持进程间与通信相关的各种标志, 信号, 信件等, 这些信息都存在接收方的进程控制块中. 73 | - 存储管理信息. 包含有指向本进程映像存储空间的数据结构. 74 | - 进程所用资源. 说明由进程打开, 使用的系统资源. 如打开的文件等. 75 | - 有关数据结构的链接信息. 进程可以连接到一个进程队列中, 或连接到相关的其他进程的PCB. 76 | 77 | **进程的组织方式** 78 | 79 | 链表 : 同一状态的进程其PCB成一链表, 多个状态对应多个不同的链表.(各状态的进程形成不同的链表 : 就绪链表, 阻塞链表) 80 | 81 | 索引表 : 同一状态的进程归入一个index表(由index指向PCB), 多个状态对应多个不同的index表(各状态的进行形成不同的索引表 : 就绪索引表, 阻塞索引表) 82 | 83 | ## 进程状态(state) 84 | 85 | ### 进程的生命期管理 86 | 87 | #### 进程创建 88 | 89 | 引起进程创建的3个主要事件 : 90 | 91 | - 系统初始化; 92 | - 用户请求创建一个新进程; 93 | - 正在运行的进程执行了创建进程的系统调用. 94 | 95 | #### 进程运行 96 | 97 | 内核选择一个就绪的进程, 让它占用处理机并执行 98 | 99 | (为何选择?如何选择?) 100 | 101 | #### 进程等待(阻塞) 102 | 103 | 在以下情况下, 进程等待(阻塞): 104 | 105 | 1. 请求并等待系统服务, 无法马上完成 106 | 2. 启动某种操作, 无法马上完成 107 | 3. 需要的数据没有到达 108 | 109 | 进程只能自己阻塞自己, 因为只有进程自身才能知道何时需要等待某种事件的发生. 110 | 111 | #### 进程唤醒 112 | 113 | 唤醒进程的原因 : 114 | 115 | 1. 被阻塞进程需要的资源可被满足 116 | 2. 被阻塞进程等待的事件到达 117 | 3. 将该进程的PCB插入到就绪队列 118 | 119 | 进程只能被别的进程或操作系统唤醒 120 | 121 | #### 进程结束 122 | 123 | 在以下四种情况下, 进程结束 : 124 | 125 | - 正常退出(自愿) 126 | - 错误退出(自愿) 127 | - 致命错误(强制性) 128 | - 被其他进程杀死(强制性) 129 | 130 | ### 进程状态变化模型 131 | 132 | **进程的三种基本状态 :** 进程在生命结束前处于三种基本状态之一. 133 | 134 | 不同系统设置的进程状态数目不同. 135 | 136 | **三种基本状态** 137 | 138 | 1. 运行状态(Running) : 当一个进程正在处理机上运行时 139 | 2. 就绪状态(Ready) : 一个进程获得了除处理机之外的一切所需资源, 一旦得到处理机即可运行 140 | 3. 等待状态(阻塞状态 Blocked) : 一个进程正在等待某一时间而暂停运行时. 如等待某资源, 等待输入/输出完成. 141 | 142 | **进程其它的基本状态** 143 | 144 | 创建状态(New) : 一个进程正在被创建, 还没被转到就绪状态之前的状态 145 | 146 | 结束状态(Exit): 一个进程正在从系统中消失时的状态, 这是因为进程结束或由于其它原因所导致. 147 | 148 | **可能的状态变化如下 :** 149 | 150 | NULL → New : 一个新进程被产生出来执行一个程序 151 | 152 | New → Ready: 当进程创建完成并初始化后, 一切就绪准备运行时, 变为就绪状态 153 | 154 | Ready → Running : 处于就绪态的进程被进程调度程序选中后, 就分配到处理机上来运行 155 | 156 | Running → Exit : 当进程表示它已经完成或者因出错, 当前运行进程会由操作系统作结束处理 157 | 158 | Running → Ready : 处于运行状态的进程在其运行过程中, 由于分配它的处理机时间片用完而让出处理机 159 | 160 | Running → Blocked: 当进程请求某样东西且必须等待时 161 | 162 | Blocked → Ready : 当进程要等待某事件到来时, 它从阻塞状态变到就绪状态 163 | 164 | ### 进程挂起 165 | 166 | 进程挂起, 为了合理且充分地利用系统资源. 167 | 168 | 进程在挂起状态时, 意味着进程没有占用内存空间, 处在挂起状态的进程映像在磁盘上.(把进程放到磁盘上) 169 | 170 | **两种挂起状态** 171 | 172 | 1. 阻塞挂起状态 : 进程在外存并等待某事件的出现; 173 | 2. 就绪挂起状态 : 进程在外存, 但只要进入内存, 即可运行. 174 | 175 | **与挂起相关的状态转换** 176 | 177 | **挂起 :** 把一个进程从内存转到外存, 可能有以下几种情况 : 178 | 179 | - 阻塞到阻塞挂起 : 没有进程处于就绪状态或就绪进程要求更多内存资源时, 会进行这种转换, 以提交新进程或运行时就绪进程. 180 | - 就绪到就绪挂起 : 当有高优先级阻塞(系统认为会很快就绪的)进程和低优先级就绪进程时, 系统会选择挂起低优先级就绪进程. 181 | - 运行到就绪挂起 : 对抢先式分时系统, 当有高优先级阻塞挂起进程因事件出现而进入就绪挂起时, 系统可能会把运行进程转导就绪挂起状态. 182 | 183 | **在外存时的状态转换 :** 184 | 185 | - 阻塞挂起到就绪挂起 : 当有阻塞挂起因相关事件出现时, 系统会把阻塞挂起进程转换为就绪挂起进程. 186 | 187 | **解挂, 激活 :** 把一个进程从外存转到内存; 可能有以下几种情况 : 188 | 189 | - 就绪挂起到就绪 : 没有就绪进程或挂起就绪进程优先级高于就绪进程时, 会进行这种转换. 190 | - 阻塞挂起到阻塞 : 当一个进程释放足够内存时, 系统会把一个高优先级阻塞挂起(系统认为会很快出现所等待的事件)进程转换为阻塞进程. 191 | 192 | > 抛出一个问题 : OS怎么通过PCB和定义的进程状态来管理PCB, 帮助完成进程的调度过程? 193 | > 194 | 195 | ### 状态队列 196 | 197 | - 由操作系统来维护一组队列, 用来表示系统当中所有进程的当前状态; 198 | - 不同的状态分别用不同的队列来表示(就绪队列, 各种类型的阻塞队列); 199 | - 每个进程的PCB都根据它的状态加入到相应的队列当中, 当一个进程的状态发生变化时, 它的PCB从一个状态中脱离出来, 加入到另外一个队列. 200 | 201 | ## 线程(thread) 202 | 203 | ### 为什么使用线程? 204 | 205 | 实例 : 编写一个MP3播放软件. 206 | 207 | 核心功能 : (1)从MP3音频文件中读取数据; (2)对数据进行解压缩; (3)把解压缩后的音频数据播放出来. 208 | 209 | ```cpp 210 | //单进程方式 211 | while(1){ 212 | Read(); 213 | Decompress(); 214 | Play(); 215 | } 216 | //问题: 播放出来的声音能否连贯? 各个函数之间不是并发执行, 影响资源的使用效率. 217 | ``` 218 | 219 | ```cpp 220 | //多进程 221 | //进程1 222 | while(1){ 223 | Read(); 224 | } 225 | //进程2 226 | while(1){ 227 | Decompress(); 228 | } 229 | //进程3 230 | while(1){ 231 | Play(); 232 | } 233 | //问题: 进程之间如何通信,共享数据?另外,维护进程的系统开销较大: 234 | //创建进程时,分配资源,建立PCB;撤销进程时,回收资源,撤销PCB;进程切换时,保存当前进程的状态信息 235 | ``` 236 | 237 | 因此需要提出一种新的实体, 满足以下特征: 238 | 239 | 1. 实体之间可以并发执行; 240 | 2. 实体之间共享相同的地址空间. 241 | 242 | 这实体就是线程. 243 | 244 | ### 什么是线程 245 | 246 | 线程是进程当中的一条执行流程. 247 | 248 | 从两个方面重新理解进程: 249 | 250 | 1. 从资源组合的角度: 进程把一组相关的资源组合起来,构成了一个资源平台(环境),包括地址空间(代码段,数据段),打开的文件等各种资源; 251 | 2. 从运行的角度: 代码在这个资源平台上的一条执行流程(线程). 252 | 253 | 线程 = 进程 - 共享资源 254 | 255 | ### 线程的优缺点 256 | 257 | 线程的优点: 258 | 259 | - 一个进程中可以同时存在多个线程; 260 | - 各个线程之间可以并发地执行; 261 | - 各个线程之间可以共享地址空间和文件等资源. 262 | 263 | 线程的缺点: 264 | 265 | - 一个线程崩溃, 会导致其所属进程的所有线程崩溃.(给它了"权限"就得有更高的"责任") 266 | 267 | - 线程所需的资源 268 | 269 | 不同的线程需要独立的寄存器和堆栈, 共享代码,数据和文件等. 270 | 271 | ### 线程和进程的比较 272 | 273 | - 进程是资源分配单位, 线程是CPU调度单位; 274 | - 进程拥有一个完整的资源平台, 而线程只独享必不可少的资源, 如寄存器和栈; 275 | - 线程同样具有就绪,阻塞和执行三种基本状态,同样具有状态之间的转换关系; 276 | - 线程能减少并发执行的时间和空间开销: 277 | - 线程的创建时间比进程短;(直接利用所属进程的一些状态信息) 278 | - 线程的终止时间比进程短;(不需要考虑把这些状态信息给释放) 279 | - 同一进程内的线程切换时间比进程短;(同一进程不同线程的切换不需要切换页表) 280 | - 由于同一进程的各线程之间共享内存和文件资源, 可直接进行不通过内核的通信.(直接通过内存地址读写资源) 281 | 282 | ### 线程的实现 283 | 284 | 主要有三种线程的实现方式: 285 | 286 | - 用户线程 : 在用户空间实现; POSIX Pthreads, Mach C-threads, Solaris threads 287 | - 内核线程 : 在内核中实现; Windows, Solaris, Linux 288 | - 轻量级进程: 在内核中实现,支持用户线程; Solaris 289 | 290 | **用户线程** 291 | 292 | 操作系统只能看到进程, 看不到线程, 线程的TCB在线程库中实现; 293 | 294 | 在用户空间实现的线程机制, 它不依赖于操作系统的内核, 由一组用户级的线程库来完成线程的管理, 包括进程的创建,终止,同步和调度等. 295 | 296 | - 由于用户线程的维护由相应的进程来完成(通过线程库函数),不需要操作系统内核了解用户进程的存在,可用于不支持线程技术的多进程操作系统; 297 | - 每个进程都需要它自己私有的线程控制块(TCB)列表,用来跟踪记录它的各个线程的状态信息(PC,栈指针,寄存器),TCB由线程库函数来维护; 298 | - 用户线程的切换也是由线程库函数来完成,无需用户态/核心态切换,所以速度特别快; 299 | - 允许每个进程拥有自定义的线程调度算法. 300 | 301 | 用户线程的缺点: 302 | 303 | - 阻塞性的系统调用如何实现?如果一个线程发起系统调用而阻塞,则整个进程在等待; 304 | - 当一个线程开始运行时,除非它主动地交出CPU的使用权,否则它所在的进程当中的其他线程将无法运行; 305 | - 由于时间片分配给进程,所以与其他进程比,在多线程执行时,每个线程得到的时间片较少,执行会较慢. 306 | 307 | **内核线程** 308 | 309 | 操作系统能够看到进程也可能看到线程,线程在内核中实现; 310 | 311 | 内核线程是在操作系统的内核当中实现的一种线程机制,由操作系统的内核来完成线程的创建,终止和管理. 312 | 313 | - 在支持内核线程的操作系统中,由内核来维护进程和线程的上下文信息(PCB和TCB); 314 | - 线程的创建,终止和切换都是通过系统调用,内核函数的方式来进行,由内核来完成,因此系统开销较大; 315 | - 在一个进程当中,如果某个内核线程发起系统调用而被阻塞,并不会影响其他内核线程的运行; 316 | - 时间片分配给线程,多线程的进程获得更多CPU时间; 317 | - Windows NT 和 Windows 2000/XP 支持内核线程. 318 | 319 | **轻量级进程** 320 | 321 | 它是内核支持的用户线程.一个进程可以有一个或多个轻量化进程,每个量级进程由一个单独的内核线程来支持.(Solaris,Linux) 322 | 323 | ## 上下文切换 324 | 325 | 停止当前运行进程(从运行状态变成其他状态),并且调度其他进程(转变为运行状态) 326 | 327 | - 必须在切换之前存储许多部分的进程上下文 328 | - 必须能够在之后恢复他们,所以进程不能显示它曾经被暂停过 329 | - 必须快速(上下文切换时非常频繁) 330 | 331 | 需要存储什么上下文? 332 | 333 | - 寄存器(PC,SP...),CPU状态等信息 334 | - 一些时候可能会费时,所以我们应该尽可能避免 335 | 336 | 操作系统为活跃进程准备了进程控制块 337 | 338 | 操作系统将进程控制块放置在一个合适的队列中 339 | 340 | - 就绪队列 341 | - 等待IO队列(每个设备的队列) 342 | - 僵尸队列 343 | 344 | ## 进程控制 345 | 346 | ### 创建进程 347 | 348 | fork()的简单实现 349 | 350 | - 对子进程分配内存 351 | - 复制父进程的内存和CPU寄存器到子进程 352 | - 开销昂贵 353 | 354 | 在99%的情况下,我们在调用fork()之后调用exec() 355 | 356 | - 在fork()操作中内存复制是没有作用的 357 | - 子进程将可能关闭打开的文件和连接 358 | - 开销因此是最高的 359 | - 为什么不能结合它们在一个调用中(OS/2, windows)? 360 | 361 | vfork() 362 | 363 | - 一个创建进程的系统调用,不需要创建一个同样的内存映像 364 | - 一些时候称为轻量级fork() 365 | - 子进程应该几乎立即调用exec() 366 | - 现在不再使用如果我们使用 copy on write 技术 367 | 368 | ### 加载和执行进程 369 | 370 | 系统调用exec()加载程序取代当前运行的进程 371 | 372 | exec()调用允许一个进程"加载"一个不同的程序并且在main开始执行(事实上 _start) 373 | 374 | 它允许一个进程指定参数的数量(argc)和它字符串参数数组(argv) 375 | 376 | 如果调用成功(相同的进程,不同的程序) 377 | 378 | 代码,stack,heap重写 379 | 380 | ```cpp 381 | int pid = fork(); //创建子进程 382 | if(pid == 0) { //子进程 383 | exec_status = exec("calc", argc, argv0,argv1,...); 384 | printf("Why would I execute?"); 385 | } else if(pid > 0) { //父进程 386 | printf("Whose your daddy?"); 387 | ... 388 | child_status = wait(pid); 389 | } 390 | ``` 391 | 392 | ### 等待和终止进程 393 | 394 | wait()系统调用是被父进程用来等待子进程的结束 395 | 396 | - 一个子进程向父进程返回一个值,所以父进程必须接受这个值并处理 397 | - wait()系统调用担任这个要求 398 | - 它使父进程去睡眠来等待子进程的结束 399 | - 当一个子进程调用exit()的时候,操作系统解锁父进程,并且将通过exit()传递得到的返回值作为wait调用的一个结果(连同子进程的pid一起)如果这里没有子进程存活,wait()立刻返回 400 | - 当然,如果这里有为父进程的僵尸等待,wait()立即返回其中一个值(并且解除僵尸状态) 401 | - 进程结束执行之后,它调用exit() 402 | - 这个系统调用: 403 | - 将这程序的"结果"作为一个参数 404 | - 关闭所有打开的文件,连接等等 405 | - 释放内存 406 | - 释放大部分支持进程的操作系统结构 407 | - 检查是否父进程是存活着的: 408 | - 如果是的话,它保留结果的值直到父进程需要它;在这种情况里,进程没有真正死亡,但是它进入了僵尸状态 409 | - 如果没有,它释放所有的数据结构,这个进程死亡 410 | - 清理所有等待的僵尸进程 411 | - 进程终止是最终的垃圾收集(资源回收) 412 | -------------------------------------------------------------------------------- /docs/Charpter 8.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第八章 2 | 3 | > 第八章的主要内容是：调度算法(感觉清华这门课程前几章比较精彩,后续讲的有点混乱) 4 | 5 | ## 背景 6 | 7 | ### 上下文切换 8 | 9 | - 切换CPU的当前任务, 从一个进程/线程到另一个 10 | - 保存当前进程/线程在PCB/TCB中的执行上下文(CPU状态) 11 | - 读取下一个进程/线程的上下文 12 | 13 | ### CPU调度 14 | 15 | - 从就绪队列中挑选一个进程/线程作为CPU将要运行的下一个进程/线程 16 | - 调度程序: 挑选进程/线程的内核函数(通过一些调度策略) 17 | - 什么时候进行调度? 18 | 19 | ### 内核运行调度程序的条件(满足一条即可) 20 | 21 | - 一个进程从运行状态切换到等待状态 22 | - 一个进程被终结 23 | 24 | ### 不可抢占 25 | 26 | - 调度程序必须等待事件结束 27 | 28 | ### 可以抢占 29 | 30 | - 调度程序在中断被相应后执行 31 | - 当前的进程从运行切换到就绪, 或者一个进程从等待切换到就绪 32 | - 当前运行的进程可以被换出 33 | 34 | ## 调度原则 35 | 36 | - 调度策略 37 | 38 | 人们通常都需要"更快"的服务 39 | 40 | 什么是更快? 41 | 42 | - 传输文件时的高带宽 43 | - 玩游戏时的低延迟 44 | - 这两个因素是独立的 45 | 46 | 和水管类比 47 | 48 | - 低延迟: 喝水的时候想要一打开水龙头水就流出来 49 | - 高带宽: 给游泳池充水时希望从水龙头里同时流出大量的水,并且不介意是否存在延迟 50 | 51 | 我们的目标: 52 | 53 | - 减少响应时间: 及时处理用户的输出并且尽快将输出提供给用户 54 | - 减少平均响应时间的波动: 在交互系统中,可预测性比高差异性低平均更重要 55 | - 增加吞吐量: 减少开销(操作系统开销,上下文切换);系统资源的高效率用(CPU,IO设备) 56 | - 减少等待时间: 减少每个进程的等待时间 57 | 58 | - 程序执行模型 59 | 60 | 执行模型 : 程序在CPU突发和IO中交替 61 | 62 | - 每个调度决定都是关于在下一个CPU突发时将哪个工作交给CPU 63 | - 在时间分片机制下,线程可能在结束当前CPU突发前被迫放弃CPU 64 | 65 | - 评价指标 66 | 67 | CPU使用率: CPU处于忙状态所占时间的百分比 68 | 69 | 吞吐量: 在单位时间内完成的进程数量 70 | 71 | 周转时间: 一个进程从初始化到结束,包括所有等待时间所花费的时间 72 | 73 | 等待时间: 进程在就绪队列中的总时间 74 | 75 | 响应时间: 从一个请求被提交到产生第一次相应所花费的总时间 76 | 77 | 各指标在操作系统上的表现: 78 | 79 | 低延迟调度增加了交互式表现(如果移动了鼠标,但是屏幕中的光标却没动,我们可能会重启电脑) 80 | 81 | 操作系统需要保证低吞吐量不受影响(我想要结束长时间的编程,所以操作系统必须不时进行调度,即使存在许多交互任务) 82 | 83 | 吞吐量是操作系统的计算带宽 84 | 85 | 响应时间是操作系统的计算延迟 86 | 87 | - 公平的目标 88 | 89 | 举例: 90 | 91 | - 保证每个进程占用相同的CPU时间 92 | - 这公平嘛?如果一个用户比其他用户运行更多的进程怎么办 93 | 94 | 举例: 95 | 96 | - 保证每个进程都等待相同的时间 97 | 98 | 公平通常会增加平均响应时间 99 | 100 | ## 调度算法 101 | 102 | - **FCFS(先来先服务)** 103 | 104 | First come, First Served 105 | 106 | 如果进程在执行中阻塞,队列中的下一个会得到CPU 107 | 108 | 优点: 简单 109 | 110 | 缺点: 111 | 112 | - 平均等待时间波动较大 113 | - 花费时间少的任务可能排在花费时间长的任务后面 114 | - 可能导致IO和CPU之间的重叠处理(CPU密集型进程会导致IO设备闲置时,IO密集型进程也在等待) 115 | 116 | - **SPN(SJF) SRT(短进程优先(短作业优先)短剩余时间优先)[最优平均等待时间]** 117 | 118 | Shortest Process Next(Shortest Job First) Shortest Remaining Time 119 | 120 | 选择预测的完成时间来将任务入队 121 | 122 | 可以是抢占的或者是不可抢占的 123 | 124 | 可能导致饥饿 125 | 126 | - 连续的短任务流会使场任务饥饿 127 | - 短任务可用时的任何场任务的CPU时间都会增加平均等待时间 128 | 129 | 需要预测未来 130 | 131 | - 怎么预估下一个CPU突发的持续时间 132 | - 简单的解决: 询问用户 133 | - 如果用户欺骗就杀死进程 134 | - 如果不知道怎么办? 135 | 136 | - **HRRN(最高响应比优先)** 137 | 138 | Highest Response Ratio Next 139 | 140 | - **Round Robin(轮循)** 141 | 142 | 使用时间切片和抢占来轮流执行任务 143 | 144 | 在叫做量子(或者时间切片)的离散单元中分配处理器 145 | 146 | 时间片结束时,切换到下一个准备好的进程 147 | 148 | 花销: 额外的上下文切换 149 | 150 | 时间量子太大: 151 | 152 | - 等待时间过长 153 | - 极限情况退化成FCFS 154 | 155 | 时间量子太小: 156 | 157 | - 反应迅速 158 | - 吞吐量由于大量的上下文切换开销受到影响 159 | 160 | 目标: 161 | 162 | - 选择一个合适的时间量子 163 | - 经验规则: 维持上下文切换开销处于1%以内 164 | 165 | - **Multilevel Feedback Queues(多级反馈队列)** 166 | 167 | 优先级队列中的轮循 168 | 169 | 就绪队列被划分成独立的队列: 比如前台(交互),后台(批处理) 170 | 171 | 每个队列拥有自己的调度策略: 比如前台(RR),后台(FCFS) 172 | 173 | 调度必须在队列间进行: 174 | 175 | - 固定优先级: 先处理前台,然后处理后台;可能导致饥饿 176 | - 时间切片: 每个队列都得到一个确定的能够调度其进程的CPU总时间;比如80%使用RR的前台,20%使用FCFS的后台 177 | 178 | 一个进程可以在不同的队列中移动 179 | 180 | 例如,n级优先级-优先级调度在所有级别中,RR在每个级别中 181 | 182 | - 时间量子大小随优先级级别增加而增加 183 | - 如果任务在当前的时间量子中没有完成,则降到下一个优先级 184 | 185 | 优点: CPU密集型任务的优先级下降很快;IO密集型任务停留在高优先级 186 | 187 | - **Fair Share Scheduling(公平共享调度)** 188 | 189 | FSS控制用户对系统资源的访问 190 | 191 | - 一些用户组比其他用户组更重要 192 | - 保证不重要的组无法垄断资源 193 | - 未使用的资源按照每个组所分配的资源的比例来分配 194 | - 没有达到资源使用率目标的组获得更高的优先级 195 | 196 | ## 评价方式 197 | 198 | 确定性建模: 确定一个工作量,然后计算每个算法的表现 199 | 200 | 队列模型: 用来处理随机工作负载的数学方法 201 | 202 | 实现/模拟: 建立一个允许算法运行实际数据的系统;最灵活,最具一般性 203 | 204 | ## 实时调度 205 | 206 | - 实时系统 207 | 208 | 定义: 正确性依赖于其时间和功能两方面的一个操作系统 209 | 210 | 性能指标: 时间约束的及时性;速度和平均性能相对不重要 211 | 212 | 主要特征: 时间约束的可预测性 213 | 214 | 分类: 215 | 216 | - 强实时系统: 需要在保证时间内完成重要的任务,必须完成 217 | - 弱实时系统: 要求重要的进程的优先级更高,尽量完成,并非必须 218 | 219 | 任务(工作单元): 一次计算,一次文件读取,一次信息传递等 220 | 221 | 属性: 去的进展所需要的资源;定时参数. 222 | 223 | - 单调速率(RM) 224 | 225 | - 最佳静态优先级调度 226 | - 通过周期安排优先级 227 | - 周期越短优先级越高 228 | - 执行周期最短的任务 229 | 230 | - 截止日期最早优先(EDF) 231 | 232 | - 最佳的动态优先级调度 233 | - Deadline越早优先级越高 234 | - 执行Deadline最早的任务 235 | 236 | ## 多处理器调度 237 | 238 | 多处理器的CPU调度更复杂: 239 | 240 | - 多个相同的单处理器组成一个多处理器 241 | - 优点: 复杂共享 242 | 243 | 对称多处理器(SMP) 244 | 245 | - 每个处理器运行自己的调度程序 246 | - 需要在调度程序中同步 247 | 248 | ## 优先级反转 249 | 250 | 可以发生在任务基于优先级的可抢占的调度机制中 251 | 252 | 当系统内的环境强制使高优先级任务等待低优先级任务时发生 253 | 254 | 255 | -------------------------------------------------------------------------------- /docs/Charpter 9.md: -------------------------------------------------------------------------------- 1 | # 深入理解操作系统 第九章 2 | 3 | > 第九章的主要内容是：同步 4 | 5 | ## 背景 6 | 7 | 第一章到第八章内容, 到目前为止 8 | 9 | - 多道程序设计: 现代操作系统的重要特性 10 | - 并行很有用(为什么?) 提示: 多个并发实体: CPU IO 用户 等 11 | - 进程,线程: 操作系统抽象出来用于支持多道程序设计 12 | - CPU调度: 实现多道程序设计的机制 13 | - 调度算法: 不同的策略 14 | 15 | 独立的线程: 16 | 17 | - 不和其他线程共享资源或状态 18 | - 确定性: 输入状态决定结果 19 | - 可重现: 能够重现起始条件, IO 20 | - 调度顺序不重要 21 | 22 | 合作线程: 23 | 24 | - 在多个线程中共享状态 25 | - 不确定性 26 | - 不可重现 27 | 28 | 不确定性和不可重现意味着bug可能是间歇性发生的 29 | 30 | 进程,线程;计算机,设备需要合作 31 | 32 | 合作优点: 33 | 34 | 1. 共享资源 35 | - 一台电脑,多个用户 36 | - 一个银行存款余额,多台ATM机 37 | - 嵌入式系统 38 | 2. 加速 39 | - IO操作和计算可以重叠 40 | - 多处理器 41 | 3. 模块化 42 | - 将大程序分解成小程序 gcc会调用cpp,cc1,cc2,as,ld 43 | - 使系统易于扩展 44 | 45 | 程序可以调用函数fork()来创建一个新的进程 46 | 47 | - 操作系统需要分配一个新的并且唯一的进程ID 48 | - 因此在内核中,这个系统调用会运行 new_pid = next_pid++; 49 | - 翻译成机器指令: 50 | - Load next_pid Reg1 51 | - STORE Reg1 new_pid 52 | - INC Reg1 53 | - STORE Reg1 next_pid 54 | 55 | 假设两个进程并发执行 56 | 57 | - 如果next_pid等于100, 那么其中一个进程得到的ID应该是100, 另一个进程的ID应该是101, next_pid应该增加到102 58 | - 可能在INC前进行了上下文切换, 最终导致两个进程的pid都是100,而next_pid也是101 59 | 60 | 无论多个线程的指令序列怎样交替执行,程序都必须正常工作 61 | 62 | - 多线程程序具有不确定性和不可重现的特点 63 | - 不经过专门设计,调试难度很高 64 | 65 | 不确定性要求并行程序的正确性 66 | 67 | - 先思考清楚问题,把程序的行为设计清楚 68 | - 切忌给予着手编写代码,碰到问题再调试 69 | 70 | ## 一些概念 71 | 72 | 前面的现象称为Race Condition(竞态条件) 73 | 74 | 系统缺陷: 结果依赖于并发执行或者时间的顺序,时间 75 | 76 | - 不确定性 77 | - 不可重现 78 | 79 | 怎么样避免竞态? 80 | 81 | Atomic Operator(原子操作) 82 | 83 | 原子操作是指一次不存在任何终端或者失败的执行 84 | 85 | - 该执行成功结束 86 | - 或者根本没有执行 87 | - 并且不应发生任何部分执行的状态 88 | 89 | 实际上操作往往不是原子的 90 | 91 | - 有些看上去是原子操作,实际上不是 92 | - 连x++这样的简单语句,实际上是由三条指令构成的 93 | - 有时候甚至连单条假期指令都不是原子的(Pipeline,super-scalar,out-of-order,pape fault) 94 | 95 | 临界区(Critical section)是指进程中的一段需要访问共享资源并且当另一个进程处于相应代码区域时便不会被执行的代码区域 96 | 97 | 互斥(Mutual exclusion)是指当一个 进程处于临界区并访问共享资源时,没有其他进程会处于临界区并且访问任何相同的共享资源 98 | 99 | 死锁(Dead lock)是指两个或以上进程,在相互等待完成特定任务,而最终没法将自身任务进行下去 100 | 101 | 饥饿(Starvation)是指一个可执行的进程,被调度器持续忽略,以至于虽然处于可执行状态却不被执行 102 | 103 | ## 临界区 104 | 105 | 互斥: 同一时间临界区中最多存在一个线程 106 | 107 | Progress: 如果一个线程想要进入临界区,那么它最终会成功 108 | 109 | 有限等待: 如果一个线程i处于入口区,那么在i的请求被接受之前,其他线程进入临界区的时间是有限制的 110 | 111 | 无忙等待(可选): 如果一个进程在等待进入临界区,那么在它可以进入之前会被挂起 112 | 113 | ## 方法1:禁用硬件中断 114 | 115 | 没有中断,没有上下文切换,因此没有并发 116 | 117 | - 硬件将中断处理延迟到中断被启用之后 118 | - 大多数现代计算机体系结构都提供指令来完成 119 | 120 | 进入临界区 121 | 122 | - 禁用中断 123 | 124 | 离开临界区 125 | 126 | - 开启中断 127 | 128 | 一旦中断被禁用,线程就无法被停止 129 | 130 | - 整个系统都会为你停下来 131 | - 可能导致其他线程处于饥饿状态 132 | 133 | 要是临界区可以任意长怎么办? 134 | 135 | - 无法限制响应中断所需的时间(可能存在硬件影响) 136 | 137 | 要小心使用,适合于较小的操作 138 | 139 | ## 方法2:基于软件的解决方案 140 | 141 | 满足进程Pi和Pj之间互斥的经典的基于软件的解决方法(1981年) 142 | 143 | 使用两个共享数据项 144 | 145 | - int turn; //指示该谁进入临界区 146 | - bool flag[]; //指示进程是否准备好进入临界区 147 | 148 | 进入临界区: 149 | 150 | ```cpp 151 | flag[i] = true; 152 | turn = j; 153 | while(flag[j] && turn == j); 154 | ``` 155 | 156 | 退出临界区: 157 | 158 | ```cpp 159 | flag[i] = false; 160 | ``` 161 | 162 | 实例: 163 | 164 | ```cpp 165 | do{ 166 | flag[i] = true; 167 | turn = j; 168 | while(flag[j] && turn == j); 169 | CRITICAL SECTION 170 | flag[i] = false; 171 | REMAINDER SECTION 172 | }while(true); 173 | ``` 174 | 175 | Bakery 算法(N个进程的临界区) 176 | 177 | - 进入临界区之前,进程接收一个数字 178 | - 得到的数字最小的进入临界区 179 | - 如果进程Pi和Pj收到相同的数字,那么如果iAcquire(); 216 | new_pid = next_pid++; 217 | lock_next_pid->Release(); 218 | ``` 219 | 220 | 大多数现代体系结构都提供特殊的原子操作指令 221 | 222 | - 通过特殊的内存访问电路 223 | - 针对单处理器和多处理器 224 | 225 | Test-and-Set 测试和置位 226 | 227 | - 从内存中读取值 228 | - 测试该值是否为1(然后返回真或假) 229 | - 内存值设置为1 230 | 231 | 交换 232 | 233 | - 交换内存中的两个值 234 | 235 | ```cpp 236 | bool TestandSet(bool *target){ 237 | bool rv = *target; 238 | *target = true; 239 | return rv; 240 | } 241 | 242 | void Exchange(bool *a, bool *b){ 243 | bool tmp = *a; 244 | *a = *b; 245 | *b = tmp; 246 | } 247 | ``` 248 | 249 | - 总结 250 | 251 | 锁是更高等级的编程抽象 252 | 253 | - 互斥可以使用锁来实现 254 | - 通常需要一定等级的硬件支持 255 | 256 | 常用的三种实现方法 257 | 258 | - 禁用中断(仅限于单处理器) 259 | - 软件方法(复杂) 260 | - 原子操作指令(单处理器或多处理器均可) 261 | 262 | 可选的实现内容: 263 | 264 | - 有忙等待 265 | - 无忙等待 266 | 267 | --------------------------------------------------------------------------------