简介：本资源是西安电子科技大学操作系统课程配套的完整实验报告，面向计算机专业本科生及系统编程初学者，聚焦Linux环境下进程管理、线程同步与进程间通信等核心原理的实践验证。报告涵盖六大实验：从fork()创建父子进程与waitpid()协同等待，到pthread_create()实现线程共享数据；从信号（SIGALRM）异步通知，到匿名/命名管道数据传输，再到信号量（sem_wait/post）控制临界区访问，每部分均含实验目的、环境、完整C代码、运行分析与心得体会，具备强教学规范性与工程可复现性。资源为1个377KB的Word文档（.doc），结构清晰，含封面、六次实验详述、截图占位提示及手写体风格的心得总结，便于直接学习、课堂提交或二次教学参考。目前已有1351人学习下载，是理解OS底层机制与提升Linux系统编程能力的优质实操材料。
1. 进程不是“复制”，而是“分叉”：为什么 fork() 返回两次却只写一个 main()？
你有没有盯着fork()的返回值发过呆？
子进程里fork()返回 0，父进程里返回子 PID，同一个函数调用，同一行pid_t fpid = fork();，却在内存中“分裂”出两个执行流——没有if-else就根本跑不下去。这不是编译器魔法，也不是调度器黑箱，而是 Linux 内核为进程抽象付出的最精巧设计代价：fork() 不是创建新进程，而是对当前进程执行一次原子级的“写时复制分叉”（Copy-on-Write Fork）。
这份来自西安电子科技大学的操作系统实验报告，表面看是六组 C 语言代码练习，实则是一套完整的、可亲手验证的「进程机制解剖套件」。它不教你man 2 fork的参数列表，而是逼你亲手触发waitpid()的阻塞、观察pthread_create()后全局变量shdata的突变、在pipe()关闭读端后write()立刻 SIGPIPE、甚至让两个消费者进程因信号量初值错配而死锁——所有这些“翻车现场”，都是内核机制在用户态投下的清晰影子。
为什么必须搞懂这个底层逻辑？因为一旦你把fork()当成“新建进程”的黑匣子，就永远无法理解：
- 为什么
fork()后父子进程的printf("hello")可能乱序输出（缓冲区未刷新 + 竞态）； - 为什么
vfork()被标记为 obsolete（它跳过写时复制，直接共享地址空间，但要求子进程立即exec或_exit）； - 为什么实验六中
semctl(emptyid,0,SETVAL,arg)必须设为MAXSEM（空缓冲区数量），而fullid初值必须是 0（已生产产品数）——这根本不是编程习惯，而是对“资源状态建模”的强制约束。
这份报告的价值，正在于它用最朴素的gcc+glibc组合，把操作系统内核中那些被封装成 syscall wrapper 的机制，一层层剥开给你看：从进程地址空间的克隆策略，到信号处理函数注册的内核钩子，再到管道文件描述符在task_struct中的引用计数管理。它不提供“正确答案”，只提供可复现的故障现场——而真正的原理，就藏在你修复sleep(3)位置、调整semop()顺序、或给printf加fflush(stdout)的那一瞬间。
2. fork() + waitpid()：进程生命周期的原子契约与内核状态机
2.1 fork() 的本质：不是“创建”，而是“分叉”与“延迟复制”
fork()的语义常被误解为“创建子进程”，但它的内核实现远比这深刻。当你调用fork()，内核并不立即复制整个进程的物理内存页（代码段、数据段、堆、栈），而是执行以下三步原子操作：
- 分配新
task_struct：内核为子进程分配一个全新的进程控制块，初始化其状态为TASK_UNINTERRUPTIBLE； - 复制页表项（Page Table Entries）：将父进程的页表项逐项复制到子进程页表，但所有页表项的“写权限位”被清零，并设置“写时复制”（COW）标志；
- 设置子进程
mm_struct：让子进程的内存描述符mm_struct指向父进程的mm_struct，但标记为MMF_HAS_EXECUTABLE_MAPPING等共享属性。
这意味着：父子进程在fork()返回瞬间，共享同一套物理内存页，但任何一方尝试写入，都会触发 CPU 的页错误异常（Page Fault），由内核的 COW 处理函数do_wp_page()拦截，此时才真正分配新物理页并复制内容。
验证这一点只需修改实验一代码，在fork()后、printf前插入内存写入：
// 实验一代码片段改造 pid_t fpid = fork(); if (fpid < 0) { printf("error"); } else if (fpid == 0) { // 子进程：故意写入大量数据触发 COW char *buf = malloc(1024 * 1024); // 分配 1MB memset(buf, 0xFF, 1024 * 1024); // 强制写入 → 触发 COW 分配 printf("子进程：我是子进程,id=%d，开始读取文件：\n", getpid()); // ... 后续文件读取 }提示：若在子进程中
malloc后不memset，fork()的开销极小（微秒级）；一旦写入，耗时陡增（毫秒级），这就是 COW 的实证。
2.2 waitpid() 的阻塞逻辑：内核如何“挂起”父进程并等待子进程终止
waitpid()的行为看似简单：“父进程停在这儿，直到子进程结束”。但其内核实现是一个典型的状态机驱动等待：
父进程调用waitpid()时子进程状态 | 内核动作 |
|---|---|
| 子进程已终止（Zombie 状态） | 立即返回子 PID，清理子进程task_struct，释放其内核栈和mm_struct引用 |
| 子进程正在运行（Running/Interruptible） | 将父进程状态置为TASK_INTERRUPTIBLE，加入子进程的wait_queue_head_t等待队列，调用schedule()让出 CPU |
子进程已退出但尚未被wait（Zombie） | 同第一行，立即返回 |
关键点在于：子进程终止时，内核不会主动唤醒父进程，而是通过__wake_up_parent()函数，向父进程的等待队列发送唤醒信号。这个唤醒发生在子进程do_exit()的末尾，当它将自己的状态设为EXIT_ZOMBIE并调用wake_up_process(parent)时。
实验一中waitpid(0, NULL, 0)的0参数表示“等待任意子进程”，这正是利用了内核为每个进程维护的children链表。你可以通过/proc/<pid>/status查看该链表：
# 编译运行实验一程序，获取父进程 PID $ gcc exp1.c -o exp1 && ./exp1 & $ ps aux | grep exp1 # 找到父进程 PID，假设为 12345 $ cat /proc/12345/status | grep -A 5 "Children" # 输出类似：Children: 12346 # 子进程 PID2.3 进程协同的本质：不是“约定”，而是“状态依赖”
实验一要求“父进程等待子进程读取完文件后继续执行”，这常被理解为“父子约定好顺序”。但真相是：协同的根基是内核对进程状态的精确建模与原子转换。fork()创建子进程时，子进程初始状态为TASK_RUNNING；waitpid()将父进程置为TASK_INTERRUPTIBLE；子进程exit(1)时，内核将其状态转为EXIT_ZOMBIE并唤醒父进程；父进程被唤醒后，检查子进程状态，确认其已终止，才继续执行后续代码。
这种状态机驱动的协同，完全脱离用户代码逻辑。即使你删掉子进程中的printf，只要exit()被调用，父进程就必然被唤醒。这也是为什么实验一中waitpid()的返回值ret总是子进程 PID——它不是函数“计算”出来的，而是内核在唤醒时，将子进程 PID 填入waitpid()的返回寄存器中。
3. 线程共享与竞态：为什么 pthread_create() 后 shdata++ 的结果不可预测？
3.1 线程的内存视图：共享地址空间 ≠ 共享执行顺序
实验二中，shdata是一个全局变量，pthread_create()创建的线程能直接访问并修改它。这常被简化为“线程共享进程内存”，但更准确的说法是：线程共享进程的虚拟地址空间（Virtual Address Space），包括代码段、数据段、BSS 段、堆，但每个线程拥有独立的栈、寄存器上下文（pt_regs）、以及内核栈（thread_info）。
这意味着：shdata的虚拟地址（如0x601040）在父子线程中完全相同，它们通过同一套页表映射到物理内存。但问题在于——对shdata的读-改-写（shdata++）不是原子操作。
拆解shdata++的汇编（x86-64）：
movl shdata(%rip), %eax # 从内存加载 shdata 到 %eax addl $1, %eax # %eax += 1 movl %eax, shdata(%rip) # 将 %eax 写回 shdata若线程 A 执行到第 2 行（addl），此时被调度器切换，线程 B 也执行shdata++，则两者都从内存加载了旧值，各自加 1 后写回，最终shdata只增加 1 而非 2——这就是经典的竞态条件（Race Condition）。
3.2 sleep(3) 的真实作用：暴露而非解决竞态
实验二代码中，主线程sleep(3)后才打印shdata，这常被误认为“确保线程执行完”。但sleep()只是让主线程放弃 CPU 3 秒，并不保证子线程一定执行完毕。更危险的是：sleep()本身会引发线程调度，可能加剧竞态。
验证方法：移除sleep(3)，改为pthread_join(tid, NULL)：
// 替换原代码中的 sleep(3); pthread_join(tid, NULL); // 主线程阻塞，直到子线程终止 printf("creat thread success\n"); printf("shared data = %d \n", shdata);pthread_join()的内核实现与waitpid()类似，它让主线程等待子线程的exit状态，从而保证shdata的最终值一定是 1（单次++）。而sleep(3)只是“赌概率”，在高负载系统上极易失败。
3.3 线程安全的底层保障：不是语言特性，而是内存屏障与原子指令
要真正解决shdata++的竞态，需引入同步原语。最直接的是pthread_mutex_t：
#include <pthread.h> int shdata = 0; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; void *creat(void *arg) { pthread_mutex_lock(&mutex); printf("new pthread ….\n"); printf("shared data = %d \n", shdata); shdata++; printf("after operating :shared data = %d\n", shdata); pthread_mutex_unlock(&mutex); return NULL; } int main() { pthread_t tid; pthread_create(&tid, NULL, creat, NULL); pthread_join(tid, NULL); printf("shared data = %d \n", shdata); pthread_mutex_destroy(&mutex); return 0; }pthread_mutex_lock()的底层，最终会调用futex_wait()系统调用。futex（Fast Userspace muTEX）的核心思想是：在无竞争时，仅使用原子指令（如lock xchg）操作用户态变量；一旦检测到竞争，才陷入内核，由内核维护等待队列。这解释了为什么pthread_mutex比semaphore更轻量——它把“乐观锁”的哲学带进了线程同步。
4. 进程间通信的三种范式：信号、管道、命名管道的内核实现差异
4.1 信号：异步通知的“软中断”机制
实验三使用SIGALRM实现父子进程通信，但信号的本质不是“传递数据”，而是向目标进程发送一个异步事件通知，强制其中断当前执行，跳转到信号处理函数。
kill(getppid(), SIGALRM)的内核路径：
- 内核根据
getppid()获取父进程 PID，查找到其task_struct； - 在父进程的
signal_struct中，将SIGALRM对应的比特位置 1（sigpending）； - 若父进程当前处于可中断状态（
TASK_INTERRUPTIBLE），则调用signal_wake_up()将其唤醒； - 父进程下次进入内核态（如系统调用返回、时钟中断）时，内核检查
sigpending，发现SIGALRM已置位，于是保存当前上下文，跳转至ouch()函数。
关键限制：信号不携带有效载荷（payload）。SIGALRM只是告诉父进程“有事发生”，具体含义（如“子进程已就绪”）需由用户代码约定。这也是为什么实验三中alarm_fired必须是全局变量——信号处理函数只能通过共享变量传递上下文。
4.2 匿名管道：基于内核缓冲区的单向字节流
实验四的pipe(fd)创建了一个内核缓冲区（通常 64KB），fd[0]和fd[1]是指向同一struct pipe_inode_info的两个文件描述符。其核心机制是：
- 写端（
fd[1]）：调用write(fd[1], buf, len)时，内核将数据拷贝到管道缓冲区；若缓冲区满，write()阻塞（除非O_NONBLOCK）； - 读端（
fd[0]）：调用read(fd[0], buf, len)时，内核从缓冲区拷贝数据到用户空间；若缓冲区空，read()阻塞； - 关闭语义：当所有写端
fd被close()，read()会返回 0（EOF）；当所有读端fd被close()，write()会触发SIGPIPE。
实验四中sleep(3)放在子进程close(fd[1])之后，是为了确保父进程write()完成后再执行子进程read()。但更健壮的做法是：父进程write()后close(fd[1])，子进程read()返回 0 时才认为传输完成。
4.3 命名管道（FIFO）：文件系统接口的管道
实验五的mkfifo("./fifo", 0666)在文件系统中创建一个特殊文件（st_mode & S_IFIFO），其 inode 指向一个struct pipe_inode_info。与匿名管道不同，命名管道：
- 不依赖父子关系：任何进程只要知道路径，即可
open()它； - 打开即阻塞：
open(O_WRONLY)会阻塞，直到有进程以O_RDONLY打开同一 FIFO；反之亦然； - 支持多生产者/多消费者：多个进程可同时
open(O_WRONLY)写入，内核按 FIFO 顺序排队。
实验五中，子进程open("./fifo", O_WRONLY)会阻塞，直到父进程执行open("./fifo", O_RDONLY)。这解释了为何sleep(1)放在子进程open()之后——它确保父进程有足够时间先打开读端。
注意：
mkfifo()创建的 FIFO 文件必须由unlink()删除，否则会残留于文件系统。
5. 信号量与 PV 操作：生产者-消费者问题中的资源状态建模
5.1 信号量的物理意义：不是“锁”，而是“资源计数器”
实验六的semget(IPC_PRIVATE, 1, IPC_CREAT|0666)创建了三个信号量：
emptyid：空缓冲区数量，初值MAXSEM（5）；fullid：已填充缓冲区数量，初值0；mutxid：互斥信号量，初值1（允许一个进程进入临界区）。
semop()的sembuf结构体定义了原子操作：
struct sembuf { unsigned short sem_num; // 信号量数组索引（此处均为 0） short sem_op; // 操作值：-1（P操作，申请资源），+1（V操作，释放资源） short sem_flg; // 标志，如 SEM_UNDO（进程退出时自动恢复信号量值） };semop(emptyid, &P, 1)即emptyid -= 1，若结果< 0则阻塞；semop(fullid, &V, 1)即fullid += 1。
信号量的精髓在于：它把“资源可用性”显式建模为整数，而 PV 操作是对此整数的原子增减。这与互斥锁（Mutex）有本质区别：Mutex 只有 0/1 两种状态，而信号量可表示 N 个资源。
5.2 生产者-消费者的死锁场景：初值错配的灾难性后果
实验六代码中，若将emptyid初值误设为0（而非MAXSEM），则生产者首次执行semop(emptyid, &P, 1)时，emptyid从 0 减 1 得 -1，立即阻塞，且永远无法被唤醒（因为消费者需要fullid > 0才能执行semop(fullid, &P, 1)，而fullid初值为 0，永远无法增加）——死锁。
同理，若mutxid初值设为0，则所有进程在尝试进入临界区时均阻塞。
这揭示了信号量使用的铁律：初值必须严格对应资源的初始状态，且 PV 操作必须成对出现，覆盖所有执行路径。实验报告中“消费者取出生产者还未生产的产品”问题，根源正是某个semop()调用被遗漏或顺序颠倒。
5.3 共享内存的协同：mmap() 与信号量的绑定关系
实验六使用mmap(NULL, ..., MAP_SHARED|MAP_ANONYMOUS, -1, 0)创建共享内存，其关键参数：
MAP_SHARED：修改对其他进程可见；MAP_ANONYMOUS：不关联文件，内核直接分配匿名页。
但mmap()本身不提供同步，因此必须与信号量配合：array[]是共享数据，*set和*get是共享指针，而fullid/emptyid/mutxid是保护它们的同步原语。这种“数据 + 同步”的分离设计，正是现代并发编程的基石——数据结构负责存储，同步原语负责协调。
6. 避坑指南：西安电子科技大学操作系统实验中 5 个血泪踩坑记录
6.1 现象：实验一中waitpid()返回 -1，报错ECHILD
原因：父进程在调用waitpid()前，子进程已因未处理的信号（如SIGPIPE）提前终止，且父进程未设置SIGCHLD处理函数，导致子进程成为僵尸进程后被内核自动回收（init进程收养），父进程再waitpid()时找不到子进程。
解决：在fork()前，显式忽略SIGCHLD或设置处理函数；或确保子进程正常exit()，不因未捕获信号崩溃。
6.2 现象：实验二中shdata输出为 0，而非预期的 1
原因：pthread_create()后主线程未等待子线程结束，直接printf("shared data = %d \n", shdata)，此时子线程可能尚未执行shdata++，或已执行但写回未刷新到主内存（缓存一致性问题）。
解决：必须使用pthread_join()等待子线程终止；或对shdata使用volatile（仅治标）或原子操作（__atomic_add_fetch(&shdata, 1, __ATOMIC_SEQ_CST)）。
6.3 现象：实验三中父进程无限打印no signal，永不退出
原因：signal(SIGALRM, ouch)注册的处理函数ouch中，alarm_fired = 1是异步执行的，但主循环while(!alarm_fired)可能被编译器优化为while(1)（因alarm_fired非volatile，编译器认为其值不变）。
解决：声明static volatile int alarm_fired = 0;，强制每次循环都从内存读取。
6.4 现象：实验四中子进程read()返回 0，但父进程write()后未关闭写端
原因：read()返回 0 表示“读端检测到 EOF”，即所有写端已关闭。若父进程write()后未close(fd[1])，子进程read()将永远阻塞（等待更多数据）。
解决：父进程write()后必须close(fd[1])；子进程read()返回 0 时，应退出循环。
6.5 现象：实验六中两个消费者进程输出乱序，或*sum计算错误
原因：*sum += array[(*get)%MAXSEM]不是原子操作，两个消费者线程可能同时读取*sum、同时加值、同时写回，导致丢失一次累加。
解决：对*sum的访问必须受mutxid保护，即在semop(mutxid, &P, 1)后执行累加，semop(mutxid, &V, 1)前完成写回；或使用原子加法__atomic_add_fetch(sum, value, __ATOMIC_SEQ_CST)。
7. 设计取舍的思考：为什么实验报告坚持用传统 System V IPC，而非 POSIX 线程？
这份西安电子科技大学的操作系统实验报告，通篇使用fork()/waitpid()、pthread_create()、semget()/semop()、pipe()/mkfifo()等传统接口，而非更现代的clone()、pthread_mutex_t初始化宏、或sem_open()。这不是技术落后，而是教学设计的深思熟虑。
首先，System V IPC（semget,shmget）与 POSIX IPC（sem_open,shm_open）的核心差异在于生命周期管理：
- System V 信号量/共享内存由内核维护，即使创建进程退出，资源仍存在，需手动
ipcs -s/ipcs -m查看，ipcrm删除； - POSIX 信号量/共享内存绑定到文件系统路径（如
/mysem），遵循open()/close()语义，进程退出后若无人unlink()，资源持续存在。
实验报告选择 System V，正是为了让学生直面“资源泄漏”这一经典问题。当semctl(..., IPC_RMID)被遗忘，下次运行实验六时，semget()可能复用旧信号量，初值错乱，导致死锁——这种“玄学”故障，恰恰逼你去读man 7 sem_overview，理解 IPC key 的生成逻辑。
其次，fork()与vfork()的对比，是理解进程创建成本的黄金案例。vfork()要求子进程立即exec或_exit，否则父进程内存被污染。实验一若强行用vfork()替代fork()，且子进程在exec前printf，就会触发SIGSEGV——这比任何教科书都更深刻地告诉你：进程隔离的代价，就是内存复制的开销；而省略它，就要用严格的编程纪律来偿还。
最后，pipe()的 64KB 缓冲区大小，是内核对“交互延迟”与“内存占用”的权衡。你可以通过ulimit -p查看当前管道缓冲区大小（单位：512 字节块），修改它会影响实验四的阻塞行为。这提醒我们：所有看似“固定”的系统参数，背后都是工程师在吞吐量、延迟、内存、CPU 之间的反复取舍。
从那以后我每次调试进程同步问题，都强制走一遍strace -f -e trace=clone,fork,waitpid,semop,pipe,mmap，把系统调用序列和返回值打出来，像读电路图一样分析状态流转。因为真正的并发 bug，从来不在if里，而在waitpid()返回的那一刻，内核悄悄改变的task_struct->state里。
希望帮到你。
本文还有配套的精品资源，点击获取
