简介操作系统实验报告来自西安电子科技大学操作系统课程面向计算机专业学生、考研复习者及希望巩固进程与线程知识的开发者。报告完整收录六项实验覆盖进程创建、父进程等待子进程、线程共享全局数据、信号通信、匿名与命名管道、信号量同步等核心机制并配有可直接运行的C代码、运行截图、程序分析及实验心得方便对照Linux环境复现。资料包内含1个doc文档约377KB文档结构按实验顺序编排重点突出fork、pthread_create、sem_init等系统调用用法。已有1350人学习下载适合作为课程实验参考、考试复习提纲和Linux并发编程入门材料能帮助读者快速理解进程同步与进程间通信的实现思路。1. 信号通信为什么父进程的 while 循环能感知到子进程的“打扰”实验三里有个非常反直觉的现象父进程在注册完signal(SIGALRM, ouch)之后就一头扎进while(!alarm_fired)死循环里疯狂打印no signal然而当子进程通过kill(getppid(), SIGALRM)发来一个信号时这个死循环竟然自己跳出来了alarm_fired变成了 1。这看起来像是某种“魔法”循环条件明明没有主动去检查管道或文件也没有调用任何阻塞式 API凭什么一个外部事件能修改循环变量的值答案藏在信号处理的底层机制里——信号不是“轮询”出来的而是内核在进程被调度执行的某个瞬间强行把控制流掰到处理函数上处理完再掰回来。换句话说ouch函数并不是被“调用”的而是被“插入”到进程的用户态执行流中的。这篇文章就用这份操作系统实验报告里的六个实验作为骨架从信号讲起一路拆到fork()的内存语义、线程共享的本质、匿名管道的内核缓冲区以及信号量 P/V 操作在共享内存上的博弈把“为什么这么设计”和“代码到底怎么跑”连成一条线。2. 信号机制内核如何“打断”正在执行的进程又安全返回2.1 从 kill() 到 signal()异步事件在内核里的完整旅程先回到实验三的两行关键代码kill(getppid(), SIGALRM); // 子进程向父进程发送 SIGALRM signal(SIGALRM, ouch); // 父进程注册信号处理函数kill()的底层调用是sys_kill它做的事远比“发个消息”复杂。内核找到目标进程的task_struct进程描述符在其中的pending位图里把SIGALRM对应的位置置 1然后检查目标进程是否阻塞该信号。如果没阻塞内核会往该进程的调度实体上打一个TIF_SIGPENDING标记。注意到这里信号处理函数并没有执行父进程的 while 循环也没被中断。真正的中断发生在父进程被调度器选中、准备从内核态返回用户态的前夕。do_signal()会被调用内核检查TIF_SIGPENDING标记发现有待处理信号于是做一套精密的“栈上换脸”操作把用户态的寄存器上下文包括返回地址、栈指针压入用户栈然后构造一个伪造的返回地址指向ouch函数入口。当内核执行iret返回用户态时CPU 跳进的不是 while 循环的下一条指令而是ouch。这就是为什么alarm_fired会在“循环还在跑”的情况下被改掉——不是循环自己发现了信号而是执行流被内核临时征用了。2.2 为什么alarm_fired必须用 volatile 或 sig_atomic_t实验三的代码在 Linux 下通常能跑通但它有一个教科书级的隐患alarm_fired没有加volatile。在-O2编译优化下编译器可能把while(!alarm_fired)优化成if(!alarm_fired) while(1);——因为它分析不出alarm_fired会被信号处理函数修改就默认它永远不变于是把读取操作提升到了循环外。这就是所谓“信号处理函数的变量被优化吃掉”的经典翻车现场。正确做法是声明为volatile sig_atomic_t前者告诉编译器“这个变量可能被外部异步修改每次都要从内存重新读”后者保证读写是原子的不会读到半个值。常见的实现思路是用sigaction()取代signal()因为它能更精细地控制信号掩码和标志位但变量的volatile属性仍然是必须的。这个细节也是实验报告里没写、但实际运行gcc -O2时会踩的坑。2.3 信号与中断的关系一个是硬打断一个是软打断理解信号的一个关键心法是信号就是“用户态的中断”。硬件中断是 CPU 收到外设事件后强行跳转到内核的中断处理程序信号则是内核在进程从内核态返回用户态时强行跳转到用户态的处理函数。两者的共同点是“异步打断当前执行流”不同点是信号不会打断系统调用除非设置了SA_RESTART且调用可以被重启而是等系统调用返回后才处理。实验三的 while 循环不是系统调用所以信号处理看起来是即时响应的。但如果父进程阻塞在read()上SIGALRM 到来时内核会让read()返回-1并设置errno为EINTR然后才去执行ouch。处理完信号后read()不会自动恢复除非你用sigaction的SA_RESTART标志。这里就能看出signal()这个老接口的粗糙之处——它在不同 Unix 衍生系统上的语义不一致有的默认重启有的默认不重启。这就是为什么 Linux 手册页明确建议用sigaction()替换signal()。3. fork() 的地址空间魔法实验一里count变量为什么各自独立3.1 fork() 的返回值机制一次调用两次返回实验一的代码里有一行很容易被忽略的关键点pid_t fpid fork(); int count 0;fork()在父进程里返回子进程的 PID一个大于 0 的整数在子进程里返回 0。这意味着同一个fpid变量在父子进程里拥有不同的值程序因此走向不同的分支。但真正让新手困惑的问题是count这个变量在父进程里声明并初始化为 0子进程里为什么也有一份独立的值如果子进程里执行count父进程的count会变吗答案取决于 fork() 的内存语义。在 Linux 上fork()的实现是“写时复制”Copy-On-Write, COW。子进程刚创建出来时并没有真正复制父进程的物理内存页而是把父进程的页表项复制了一份并且把这些页标记为只读。此时父子进程共享同一片物理页面——但谁也不能写。一旦某一方尝试写入比如countCPU 触发缺页异常内核在异常处理里把这一页复制一份重新映射给写入方并恢复可写权限。这就是 COW 的完整过程不写不复制一写就复制。3.2 写时复制的内核实现缺页异常作为“惰性复制”的触发器COW 的关键数据结构是进程的mm_struct和页表。fork()在内核里走的是kernel_clone()→copy_mm()→dup_mmap()这条路径它会遍历父进程的虚拟内存区域VMA逐个复制到子进程的 VMA 链表上。物理页不复制但页表项要复制并且把 PTE 的写权限位清零、设置_PAGE_COW标记。这样一来父子进程的页表都指向同一批物理页但这些页不允许写。当某个进程尝试写入时CPU 触发 page fault异常向量表把控制权交给do_wp_page()。这个函数检查 PTE 的 COW 标记确认为写时复制页然后分配新页、拷贝旧页内容、更新 PTE 为可写最后返回用户态重新执行那条触发异常的指令。整个过程的奇妙之处在于指令本身没有失败只是被延迟执行了——先复制再继续。所以从应用层的视角看fork() 的子进程好像真的拥有了一份完整的独立地址空间拷贝。3.3 waitpid() 的本质父进程如何“知道”子进程结束了实验一里父进程调用waitpid(0, NULL, 0)阻塞等待子进程用exit(1)退出。这个等待机制的内核实现是子进程退出时do_exit()会发 SIGCHLD 给父进程但父进程即使不处理这个信号waitpid()也能读到子进程的退出状态。关键在内核的task_struct里维护了一个“僵尸子进程链表”waitpid()就是在遍历这个链表查找状态为EXIT_ZOMBIE的子进程。这里有个很重要的设计取舍子进程退出后并不会立刻消失而是变成僵尸进程——保留task_struct释放地址空间。为什么要保留因为父进程可能还没调用waitpid()父进程需要读取子进程的退出码比如实验里exit(1)的 1和资源使用统计。只有当父进程waitpid()成功返回后这个僵尸进程才被彻底回收。如果父进程不调用 waitpid 且不处理 SIGCHLD僵尸进程会一直挂在内存里这就是僵尸进程泄漏的根源。实验报告的代码里父进程确实调用了waitpid(0, NULL, 0)其中pid0表示等待与调用者同进程组的任意子进程statusNULL表示不关心退出状态options0表示阻塞等待。4. 线程与共享内存实验二里全局变量shdata为何不复制4.1 pthread_create 的底层路径从用户态到内核态的 CLONE 调用实验二的代码非常短但信息密度很高int shdata 0; void *creat(void *arg) { printf(shared data %d \n, shdata); shdata; return (void *)0; } pthread_t tid; int pth pthread_create(tid, NULL, creat, NULL);pthread_create是 glibc 提供的 POSIX 线程接口它的底层不是fork()而是clone()系统调用。两者的核心区别在于clone()允许通过标志位精细控制“哪些资源共享、哪些资源私有”。创建线程时传入的关键标志包括CLONE_VM共享地址空间、CLONE_FS共享文件系统信息、CLONE_FILES共享文件描述符表、CLONE_SIGHAND共享信号处理函数表。其中CLONE_VM是决定性的它让线程的mm_struct直接指向同一个地址空间而不是像fork()那样复制一份页表。所以线程里shdata能直接改动进程的全局变量根本原因不是“线程间通信方便”而是线程根本就没有独立的地址空间——它们和进程共享同一个页表、同一份物理内存。这与 fork() 的子进程形成鲜明对比子进程拥有独立的地址空间尽管 COW 在初期共享物理页但逻辑上是隔离的线程则从创建那一刻起就完全共享。4.2 为什么实验二需要 sleep(3)线程调度的随机性与竞态暴露实验二代码里有一行非常值得玩味sleep(3)。主线程创建新线程后睡 3 秒期间新线程执行shdata。程序似乎稳定输出shdata 1但这纯属运气——sleep(3)是主线程主动让出 CPU给新线程足够的时间窗口完成操作。如果去掉sleep(3)主线程可能先执行printf(shared data %d, shdata)此时新线程还没来得及执行shdata输出就会是 0然后才轮到新线程把值改成 1最终输出两个 0 和一个 1。这个现象背后是线程调度的本质内核的调度器以线程为基本单位分配 CPU 时间片但线程之间的执行顺序没有任何保证。pthread_create只是把新线程放进就绪队列不等于它立即运行。更隐蔽的是shdata在底层是三条指令读内存到寄存器、寄存器加 1、写回内存。在单核环境里这三条指令可能被时钟中断打断在多核环境里两个线程可能同时读shdata0、各自加 1、各自写回导致结果仍是 1 而不是 2。这就是数据竞争的经典场景——实验二能跑通只是因为sleep(3)碰巧掩盖了竞争而不是代码本身是正确的。4.3 进程与线程的内存隔离差异一份地址空间 vs 多份地址空间如果把实验一和实验二放在一起对比会发现一个清晰的层次结构进程每个进程有独立的mm_struct、页表、物理内存映射。fork()创建的子进程即使共享物理页COW也只是一瞬间的事从逻辑上二者是完全隔离的地址空间。线程所有线程共享同一个mm_struct、同一份页表。线程栈是私有的通常 8MB通过mmap分配但堆、全局变量、静态变量、文件描述符表全部共享。这个设计动机很直观线程的定位是“轻量级并发执行单元”创建线程的开销远小于创建进程因为不需要复制页表、不需要写时复制机制。代价是线程之间的隔离性极差——一个线程越界写坏堆内存整个进程直接崩。而进程之间哪怕一个崩溃了其他进程也不受影响。操作系统课里常说的“进程是资源分配的最小单位线程是调度的最小单位”在这里有了具体的落点地址空间是资源分配的核心调度器只认线程。5. 匿名管道与命名管道实验四和实验五的内核缓冲区模型5.1 pipe() 创建了什么不是文件而是内存中的环形缓冲区实验四的代码从pipe(fd)开始fd[0]是读端fd[1]是写端。这两个文件描述符背后不是一个磁盘文件而是内核内存里的一个环形缓冲区默认大小通常是 64KB/proc/sys/fs/pipe-max-size可调。管道的数据结构核心是struct pipe_inode_info它包含一个pipe_buffer数组每个 buffer 指向一页物理内存维护了offset、len等字段用于追踪读写位置。pipe()系统调用的实现路径是do_pipe2()→alloc_pipe_info()在内核中分配 inode挂在管道文件系统上、分配缓冲区、创建两个 file 结构一个只读、一个只写最终通过fd_install()把它们安装到进程的文件描述符表里。注意管道创建后并没有任何数据只有读写双方都打开时数据才能在缓冲区里流转。5.2 阻塞读写的本质当缓冲区空/满时进程进入不可中断睡眠实验四里子进程先close(fd[1])关闭写端然后read(fd[0], ...)阻塞等待父进程随后write(fd[1], str, ...)写入数据。这里最关键的行为是阻塞式 I/Oread()在管道缓冲区为空时会调用pipe_read()里的wait_event_interruptible()把当前进程放入管道等待队列并进入睡眠状态直到有数据写入才被唤醒。同样地write()在缓冲区满时也会阻塞——如果对方不读走数据写端会一直等待。这就是管道通信的“同步”本质它不只是一个数据搬运工具同时也是一个天然的同步机制。父进程在write()完成之前子进程的read()不会返回而父进程的write()在缓冲区有空间时立即返回不会等待子进程真正读完。实验五里子进程sleep(1)再写管道父进程此时已经阻塞在read()上——内核调度器会公平地让子进程运行所以即使父进程先到阻塞点子进程后写入数据也能被正确送达。5.3 命名管道 mkfifo让文件系统路径成为两个独立进程的“接头暗号”实验五使用了mkfifo(./fifo, 0666)与实验四的本质区别在于匿名管道没有文件名只能由pipe()创建它的进程及其子孙通过继承文件描述符来使用而命名管道是一个存在于文件系统中的特殊文件任何进程只要知道路径就能通过open()打开并参与通信。命名管道在磁盘上并不存储数据它只是一个锚点真实的数据通道仍然是内核内存中的管道缓冲区。mkfifo()创建的是管道文件系统的 inodeopen(./fifo, O_RDONLY)会返回一个连接到这个 inode 的读端文件描述符。关键细节是以只读方式open一个 FIFO 时内核会阻塞直到有一个写端也打开它除非指定O_NONBLOCK。这意味着实验五的父进程如果先open会被阻塞在open()调用里直到子进程以只写方式打开才返回。这种“打开即握手”的机制是 FIFO 能绕过“无血缘关系进程如何找到彼此”这一难题的核心设计。5.4 管道为何不适合双向通信半双工设计与死锁风险一份实验报告做下来很多人会下意识地认为管道可以双向传输数据。实际上匿名管道和命名管道都是半双工的——数据只能从写端流向读端不能是同一个 fd 既能读又能写。如果父子进程都用同一个管道尝试双向通信会出现经典的“管道死锁”父进程写数据后等待子进程回复子进程也想写数据后等待父进程回复两端都阻塞在write()上因为对方的管道缓冲区已满谁也读不了谁的数据。正确的方案是要么创建两个管道一个方向一个要么用socketpair()创建全双工通道。这个限制的根源在于管道的设计动机它本来就是为“一个方向的数据流”设计的内核只维护一个环形缓冲区和一组读写等待队列。想实现双向通信本质上是需要两个独立的数据通道和两套同步状态这超出了单个管道的设计边界。6. 避坑指南这份报告里最容易翻车的 5 个细节6.1signal()与sigaction()的语义差异导致信号丢失现象实验三在低负载时能收到 SIGALRM但系统繁忙时偶发收不到信号。原因signal()在旧版 Unix 语义下处理函数执行完毕后该信号的处置会被重置为默认行为。如果编程时使用传统signal()第一次信号处理完后第二次信号可能直接按默认处置执行导致进程退出。解决用sigaction()替代signal()显式指定sa_handler、sa_flags确保SA_RESTART和信号掩码可控。6.2fork()之后父子进程都执行了printf但输出顺序不可预测现象实验一的输出有时先打印父进程有时先打印子进程。原因fork()之后父子进程都处于就绪态调度器选择谁先运行是随机的与代码书写顺序无关。解决需要严格顺序时父进程必须用waitpid()阻塞等待或者用管道/信号量做显式同步。不能依赖 printf 的缓冲顺序来判断谁先执行stdout是行缓冲重定向到文件时还会变成全缓冲日志顺序更不可靠。6.3 管道读写端未关闭导致read()永远阻塞现象实验四中如果子进程不close(fd[1])父进程的read()会一直阻塞即使数据已经写完。原因read()返回 0 表示“对端写端已关闭”即 EOF而管道的写端仍然打开意味着内核不知道“不会再写入数据”只能继续等待。解决关闭不需要的管道端是管道编程的黄金法则。子进程要读就关写端父进程要写就关读端双向保留两端只会让阻塞无法解除。6.4 信号量实验里 PV 操作顺序错误导致生产者跳过缓冲区现象实验六最初运行时消费者取出了生产者还没生产的产品或打印了重复数据。原因代码中生产者先对emptyid执行 P 操作再对mutxid执行 P 操作两者顺序不能颠倒。如果先 P(mutxid) 再 P(emptyid)消费者可能同时持锁等待空缓冲区双方互相等待形成死锁。解决多信号量加锁时所有进程必须按同一顺序请求多个信号量实验里固定为emptyid → mutxid → 操作 → mutxid → fullid的 P/V 配对才能避免交叉等待。6.5mmap共享内存与信号量的生命周期管理现象实验六程序退出后再次运行时提示信号量已存在或共享内存冲突。原因semget(IPC_PRIVATE, ...)创建的信号量和mmap(MAP_SHARED|MAP_ANONYMOUS)创建的共享内存都不会在进程退出时自动销毁除非显式调用semctl(IPC_RMID)和munmap()shm_unlink()。IPC_PRIVATE 只是为了给新创建的信号量一个唯一的 key拥有者进程结束后内核对象仍然存在。解决在程序结尾显式清理信号量semctl(fullid, 0, IPC_RMID)、semctl(emptyid, 0, IPC_RMID)、semctl(mutxid, 0, IPC_RMID)并用munmap解除共享内存映射。否则多次运行会耗尽系统信号量资源。7. 从实验代码反推设计取舍为什么实验六要混用共享内存与 System V 信号量最后把实验六单独拎出来看一遍它的设计里藏着一个非常有意思的取舍数据区array、sum、get、set全部放在mmap共享内存里而同步工具fullid、emptyid、mutxid却用semget创建独立的 System V 信号量。为什么不同时用mmappthread_mutex或者干脆全部用 POSIX 信号量一个朴素的理解是实验要求明确写了“使用信号量”而 System V 信号量正是课程里 P/V 操作的经典载体。但更深的理由是——mmap负责的是“数据可见性”信号量负责的是“临界区互斥”这两个责任的边界必须清晰。如果把信号量也放进共享内存就需要自己去实现原子操作和等待队列这实际上是重新发明内核信号量的轮子。内核信号量的价值在于它是一个被进程调度器直接支持的睡眠原语——P 操作在信号量值为 0 时不是自旋等待而是把进程挂到等待队列并调度出去这比任何用户态自旋锁都省 CPU。同时mmap(MAP_SHARED|MAP_ANONYMOUS)在这里也不是随意选的它让父子进程和两个消费者进程共享同一份内存但fork()之后的地址空间是隔离的不映射共享内存就无法共享array和sum。如果改用文件 I/O 传递数据就需要处理文件偏移、缓存同步、锁竞争复杂度远超直接共享内存映射。另一个隐蔽的取舍是sem_flg SEM_UNDO。这个标志告诉内核如果进程在持有信号量时异常退出内核自动撤销它所做的信号量操作避免死锁。实验里生产者进程exit(0)前对mutxid执行了 V 操作消费者进程在break跳出循环时由SEM_UNDO保证不会因为提前结束而让emptyid或mutxid卡死。这个细节很多人会忽略但它实际上是对“异常路径”的最后一道保险——没有它一旦某个进程崩溃其他进程可能永远阻塞在 P 操作上。回看整份实验报告从fork()的写时复制、waitpid()的僵尸进程回收到pthread_create的CLONE_VM共享地址空间再到read()在管道缓冲区为空时的睡眠唤醒最后到semop的 P/V 原语和SEM_UNDO的异常撤销——每个实验本质上都是在操控内核里的几个核心数据结构task_struct、mm_struct、pipe_buffer、sem_array。操作系统课本上那些抽象概念在这里都变成了具体的系统调用参数、标志位和返回值。一个值得继续深挖的方向是如果把实验六的 System V 信号量换成 POSIX 无名信号量sem_initsem_waitsem_post并把它们也放在mmap共享内存区域里代码会怎么变两种方案的差异在哪里前者需要semget/semctl/semop三个函数配合后者只需sem_init后直接操作信号量指针——但 POSIX 信号量要求pshared参数为 1 才支持进程间共享而且它在内核里的实现是基于futex的与 System V 信号量基于自身调度器的等待队列有本质差异。这个对比值得亲手做一遍实验验证。我从那以后每次写进程间同步代码都会强制自己先画一张“资源归属图”——哪些数据放共享内存、哪些状态由信号量保护、异常退出时怎么释放画完再动手写代码。这份实验报告里没有这个步骤但我想你读完这篇拆解后应该会愿意自己补上这一步。希望帮到你。本文还有配套的精品资源点击获取