简介2023年河北工业大学操作系统实验报告围绕Windows XP环境下进程的创建、观测与终止展开系统记录了控制台应用程序和GUI应用程序的设计、编译、调试与结果分析过程。报告以PDF格式提供共1个文件大小约7.8MB内容包含实验目的、软硬件环境、Hello控制台程序、MessageBox GUI程序、进程句柄获取与进程优先权查询等关键知识点并讨论了使用Word等非标准编辑器保存为.cpp文件、命令提示符下CL.EXE编译、user32.lib链接等注意事项还给出了常见编译错误、链接错误和运行时逻辑错误的排查方向。这份报告适合操作系统课程学生参考可帮助理解进程对象、句柄与优先权类等核心概念掌握Visual C 6.0下的Windows编程流程以及利用GetCurrentProcess、GetPriorityClass等API函数进行进程管理的方法。目前已有64人学习下载适合正在完成同类实验或复习进程管理知识的高校学生借鉴。1. 一份操作系统实验报告 PDF 从哪里读起“2023年河北工业大学操作系统实验报告.pdf”这个文件名在备考季被反复搜索。它看起来像一份学期末提交的电子作业实际上是把整门《计算机操作系统》的验证性内容装进了一个 PDF 外壳进程创建、信号量同步、管程和协程调度、内存分配与页面置换、文件系统断链与修复。每个主题都自带代码和运行结果。对没上过这门课的人它是入门例子对上过课的人它是期末复习提纲对准备面试的人它是一套随手能拿来讲的操作系统实验案例。问题在于这类报告很少保持原始代码的完整形态大多经过 Word 排版、导出、又转存成 PDF 的二次加工。直接打开阅读器翻页很难获得比截图更多的东西。我的处理套路是先做 PDF 解析把文本、表格、截图分层拆开再把实验代码按经典写法重建到 Linux 环境里最后用标准测试数据验证报告里的结论。这样做完一份 PDF 才能真正变成可检索、可复现、可对账的学习资料。2. 操作系统实验报告里常见的同步与资源管理模型2.1 实验模块是怎么排的从进程到文件系统拿到报告后第一件事不是读代码而是先建立心理目录。一份完整的操作系统实验报告章节顺序往往和课程讲授顺序一致进程管理、线程同步、调度算法、内存管理、文件系统。这个顺序不是随便排的它是操作系统从“资源抽象”到“资源分配”再到“资源持久化”的递进关系。你手头这份 PDF 无论页数多少内容基本都围绕这几块展开。实验模块与验证点的对应关系可以用下面的表格快速过一遍实验模块核心 API / 数据结构验证手段报告中的高频输出进程控制fork、exec、waitps、top、waitpidPID 分配和回收顺序线程同步sem_t、pthread_mutex多线程并发计数缓冲区不重叠、不丢包管程与协程条件变量、用户态上下文调度日志协程状态机输出调度算法FCFS / SJF / RR平均等待时间和周转时间甘特图与时间表内存管理页表、LRU / FIFO / CLOCK缺页率缺页次数对比表文件系统inode、目录项、软硬链接ls、df、stat磁盘结构示意图这份表最大的用途是定位“这份 PDF 到底覆盖到哪一步”。如果某一实验只有一句“实验成功”和一张截图没有算法流程说明也没有运行时参数说明原始报告的质量不高你在后面还原代码时需要自己补全设计。相反如果某个实验在正文里给出了输入参数和输出表格哪怕代码被 PDF 切得七零八落也仍能靠表格数据反推算法行为。操作系统的实验逻辑归根结底是让两个并发主体在共享资源上不打架。进程实验处理 fork 出来的孤儿进程和僵尸进程线程实验处理中断时机不确定下的共享计数器内存实验处理页表缺失时淘汰哪一页。三者本质一致资源有限访问无序需要仲裁机制。所以看实验报告时先问自己“这个实验仲裁的是什么”再去看代码理解成本会低很多。2.2 管程与协程报告里最容易被跳过的一节“管程和协程”几乎总落在课程大纲的中后段也最容易被实验报告一笔带过。难点在于管程和协程是两个不同层面的概念但在同步实验里经常同时出现。管程是语言层面的同步原语它把互斥区和条件等待封装成一个对象调用者不需要知道底层信号量怎么挂、挂几个协程是用户态执行流没有内核调度参与靠一个调度器在两个栈之间主动切换。一份认真写的实验报告管程部分必须能看到两个结构一个是入口互斥另一个是条件变量的 wait 和 signal 配对。常见错误是只调用 wait 不调用 signal或者条件变量被唤醒后不重新检查 while 条件导致报告结论和输出日志对不上。协程实验一般要求实现一个用户态调度器用一个 runqueue 保存待执行上下文每个协程 yield 时把寄存器保存进自己的任务控制块然后恢复下一个协程的上下文。代码量能压到 200 行以内但切换点和栈分配必须手工维护。王道操作系统里对管程的描述是“把资源数据结构和针对它的操作集中封装”放到实验代码里实际要求就是临界区变量不要跨模块直接读写。谁修改、谁读取、谁先排队等待全部收进一个 monitor 结构体信号量的初始值就变得容易推导。反过来如果在报告里看到结构体外部还在直接改共享缓冲区下标那说明代码和理论没有真正对上这种实验报告只能当提纲看不能照抄。2.3 同步实验代码一份可对照的 C 版本经典的生产者-消费者实验是几乎所有操作系统课都会出现的必做项目。下面的 C 代码是最常见版本的最小实现注释把信号量的申请释放位置标了出来#include stdio.h #include pthread.h #include semaphore.h #include unistd.h #define CAP 5 sem_t mutex, empty, full; int buf[CAP]; int in 0, out 0; void *producer(void *arg) { for (int i 0; i 10; i) { sem_wait(empty); // 有空闲位置才继续 sem_wait(mutex); // 进入临界区 buf[in] i; in (in 1) % CAP; printf(produce: %d\n, i); sem_post(mutex); // 离开临界区 sem_post(full); // 通知消费者 usleep(500); } return NULL; } void *consumer(void *arg) { for (int i 0; i 10; i) { sem_wait(full); // 有数据才继续 sem_wait(mutex); int v buf[out]; out (out 1) % CAP; printf(consume: %d\n, v); sem_post(mutex); sem_post(empty); // 释放一个空闲位置 usleep(800); } return NULL; } int main() { sem_init(mutex, 0, 1); sem_init(empty, 0, CAP); sem_init(full, 0, 0); pthread_t pid, cid; pthread_create(pid, NULL, producer, NULL); pthread_create(cid, NULL, consumer, NULL); pthread_join(pid, NULL); pthread_join(cid, NULL); sem_destroy(mutex); sem_destroy(empty); sem_destroy(full); return 0; }这段代码里要特别记录三组参数mutex 初始值固定是 1empty 初值等于缓冲区长度 CAPfull 初值是 0。三个信号量的语义不能互换否则日志里会出现消费者抢跑或生产者永久阻塞。这里的执行顺序也不能调错生产者在压入数据前必须等 empty消费者在读取数据前必须等 full两个 wait 的先后一旦颠倒缓冲区满时会出现死锁。一段正确的同步实验其输出应该只有“produce: i”和“consume: v”成对出现且同一个值不会出现两次。由于 printf 本身不保证原子输出不同线程的打印行会交错这不能说明程序有 bug但同一个编号出现两次则说明 in 或 out 的更新逻辑出了问题。这就是报告里“运行结果”一节的核心判断标准。3. 用 PDF 解析还原实验报告的内容结构3.1 先做文件体检页数和工具选型处理一个中文名长、可能是合并版的 PDF第一步不是直接打开阅读器翻页而是在命令行里确认文件本身是什么状态。我先执行这个命令pdfinfo 2023年河北工业大学操作系统实验报告.pdfpdfinfo 来自 poppler-utils它会返回页数、页面尺寸、加密状态、Producer 等信息。看到 Pages 是 30 以上通常说明报告包含了多个实验的多页截图看到 Producer 是 Microsoft Word说明 PDF 有文字层可以走文本提取路线看到 Producer 是扫描仪品牌说明整份是图片必须 OCR 才能抽内容。这里的关键是校检文件内部的真实结构而不是看后缀名。文件体检之后再决定工具组合。同一个 PDF不同场景应该用不同工具。我常用的配合如下工具安装方式适用场景输出类型pdfinfosudo apt install poppler-utils查看页数、元数据、加密信息纯文本元数据pdftotextpoppler-utils快速抓取全文可检索的 .txtpdfplumberpip install pdfplumber表格、坐标、复杂版式行级文本和二维表格PyMuPDFpip install PyMuPDF提取嵌入图片和对象信息图片对象、页面截图pdftoppmpoppler-utils整页转高分辨率图片150/300dpi PNG如果 PDF 是通过 Windows 自带 Microsoft Print to PDF 打印生成的文字层通常完整但没有书签和目录。问题不大pdftotext 仍可取出全部文本只是原本的目录导航无法用需要靠 grep 定位章节。这种“有字没目录”的状态在实验报告类 PDF 里非常普遍。3.2 用 pdfplumber 把文本与表格分层拆出来实验报告里经常出现分栏或嵌套表格直接整段复制会乱。原因是复制操作把字符按阅读顺序输出而 PDF 中每个字符仍保留坐标表格必须调用表格识别接口单独提取不能靠肉眼做横向拼接。先做一次粗提取看全文结构和主要关键词位置pdftotext -layout 2023年河北工业大学操作系统实验报告.pdf report.txt wc -l report.txt grep -n 实验 report.txt | head -n 40-layout 参数会保留文本的相对位置比默认模式的随机换行稳定得多。grep 输出行号能快速知道“信号量”“页面置换”出现在第几页后面对照代码时不需要一页页翻。但 pdftotext 对表格的处理是靠空格对齐遇到边框线拆开的单元格外行信息经常错位所以表格还要单独提取。我一般用 pdfplumber 提取表格和文本import pdfplumber with pdfplumber.open(2023年河北工业大学操作系统实验报告.pdf) as pdf: print(pages:, len(pdf.pages)) for i, page in enumerate(pdf.pages): text page.extract_text() or if 缺页 in text or FIFO in text: print(f--- page {i1} contains target ---) tables page.extract_tables() for table in tables: for row in table[:5]: print(row)extract_tables 返回的是二维列表每个 cell 对应 PDF 表格中的一个单元格空白位置是 None。要核对的实验数据比如 FIFO 和 LRU 的缺页次数都能通过这段代码回收到结构变量里。如果某个表提取出来只有一列这说明原表被印刷成图片不是文本型表格后续需要走图片识别。pdfplumber 在遇到页面角落的细线时偶尔会误判边界如果表格数据明显少一行可以调 horizontal_strategy 和 vertical_strategy 参数但要优先确认原表是否跨页。3.3 把代码块和截图从 PDF 里拆出来实验报告里的源码块通常用等宽字体页面里带灰色底纹PDF 解析时会被当作文本块的一部分。如果不处理复制出来的代码会混进“print 结果”和“实验环境”注释和换行全部丢失。更可靠的办法是把代码区和图片区拆开分别提取。先做图片提取用 PyMuPDF 可以按页拿到嵌入对象import fitz doc fitz.open(2023年河北工业大学操作系统实验报告.pdf) for page_no in range(doc.page_count): page doc[page_no] for img in page.get_images(fullTrue): xref img[0] pix fitz.Pixmap(doc, xref) if pix.n 3: pix fitz.Pixmap(fitz.csRGB, pix) pix.save(fpage{page_no1}_img{xref}.png)xref 是 PDF 内部对象编号get_images 返回的元组里第一个元素就是它。这里把带透明通道的图统一转成 RGB避免保存出的 PNG 在某些查看器里背景变黑。一个常见的坑是图片本身嵌入过多次导致 PDF 文件体积大但页面数量少提取后出现大量重复图片。这时可以用图片 md5 去重只保留每种哈希值的第一张。代码块同样可以从文本对象里按字体名筛选。pdfplumber 的 chars 对象中带有 fontname 和 sizeMonospace、Consolas、Courier 等字体名通常对应源码区中文宋体和黑体则对应正文。按 fontname 分组后对等宽字体字符按行聚类可以还原出比整页文本干净得多的代码段。之后把这些代码段保存成 .c 文件就有了可以真正编译运行的实验原形。4. 从 PDF 到可复现实验生产者消费与页面置换4.1 搭建可复现实验的 Linux 运行环境打开实验报告先看“实验环境”那一行。有的写 Windows 加 IDE有的写 Ubuntu Linux。无论原报告用什么系统操作系统实验的经典题目都依赖 POSIX API放在 Linux 下跑最省事。我通常选 Ubuntu 20.04.6 LTS官方仓库带的 gcc、gdb、valgrind 版本足够应付课程实验且 sem_t、pthread 这类库不需要额外换源。如果机器上已经有别的发行版也没必要重装系统用容器隔离即可。最小环境准备包含编译器和调试工具sudo apt update sudo apt install build-essential gdb valgrind gcc -stdc11 -pthread -Wall -Werror -o pconsumer pconsumer.c ./pconsumer-pthread 参数必须保留否则链接阶段会报 pthread_create 未定义-Wall -Werror 能提前暴露 usleep 需要隐蔽函数声明的问题例如缺少_DEFAULT_SOURCE。valgrind 主要用来检查线程退出后是否还有未释放的信号量虽然课程实验不强制但它能发现报告里代码在退出时少写 sem_destroy 的隐患。4.2 用经典引用串验证 FIFO 和 LRU 缺页率页面置换实验的核心数据是缺页次数。实验报告的正文会给出一个引用串常见的是 [7,0,1,2,0,3,0,4,2,3,0,3,2,1,2,0,1,7,0,1]。先不急着和报告里的截图对答案用 Python 模拟算法把所有缺页时刻打印出来。这样既能看到结论也能看到换页过程。from collections import deque ref [7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1] def fifo(reference, cap): mem, q, faults [], deque(), 0 for p in reference: if p not in mem: faults 1 if len(mem) cap: mem.append(p) q.append(p) else: old q.popleft() mem.remove(old) mem.append(p) q.append(p) return faults def lru(reference, cap): mem, last_used, faults [], {}, 0 for t, p in enumerate(reference): if p in mem: last_used[p] t continue faults 1 if len(mem) cap: mem.append(p) else: evict min(mem, keylambda x: last_used.get(x, -1)) mem.remove(evict) mem.append(p) last_used[p] t return faults for cap in (3, 4): print(fframes{cap} FIFO{fifo(ref, cap)} LRU{lru(ref, cap)})FIFO 用双端队列保存进入顺序队首就是最早进入的页换出的时候从队首取LRU 则不维护进入顺序而是记录每一页最后一次被访问的时间淘汰时选时间戳最小的那一个。需要留意的是min 函数遇到两个相同时间戳时返回的结果不稳定但对缺页总数没有影响因为帧内不存在两页同时被访问的相同时刻last_used 的值在同一轮循环里一定是不同时间戳。用上面的引用串跑 3 个帧FIFO 应有 15 个缺页LRU 应有 12 个缺页。这两个数字是页面置换实验的标准参照可以直接写入你的报告对照表帧数算法缺页次数说明3FIFO15总是淘汰最早进入的页3LRU12淘汰最久未被访问的页4FIFO9帧数增加缺页数下降4LRU10LRU 在某些串里不比 FIFO 好4.3 把报告里的结论做成可对账的测试用例报告里贴出的截图只能证明“跑过一次”不能证明代码在所有输入上都正确。把参照数据转成断言后就可以每次改动代码时都跑一遍检查防止实验结论被无意破坏assert fifo(ref, 3) 15, FIFO 3帧缺页数不对 assert lru(ref, 3) 12, LRU 3帧缺页数不对 print(report data consistent with standard reference string)这样处理后报告里的数字从“展示性结论”变成了“可验证契约”。后续如果再调整淘汰逻辑比如混用 CLOCK 算法或加了降级表只要断言没过就说明新逻辑改变了基本缺页行为需要重新评估。这里还要单独处理 Belady 异常。FIFO 在帧数增加时缺页数有时不降反升典型序列 [1,2,3,4,1,2,5,1,2,3,4,5] 在 3 帧时缺页 9 次在 4 帧时缺页 10 次。如果你的报告恰好选择这组数据并显示帧数增加但缺页数增加这其实是正确行为不要试图把结果“修正”成帧数越大缺页越少那样只会暴露你根本没跑过代码。5. 验证实验报告从 md5 到 diff 回放的关键一公里5.1 先校验文件指纹再做任何解析网上流传的这份 PDF 可能有多个修订版文件名相同内容却不同。解析前先算 md5后面排错时才能确认操作的是不是同一份文件md5sum 2023年河北工业大学操作系统实验报告.pdf如果后续提取文本的顺序不对或者表格数据和别人截图对不上先拿 md5 确认再怀疑解析代码。另一个实用动作是计算每页图像的哈希列表这是定位“哪一页被重新编辑过”的最快方法pdftoppm -png -r 150 2023年河北工业大学操作系统实验报告.pdf page md5sum page-*.png page_hashes.txt这套方法与 PDF 编辑器无关。即使你没有原稿也能通过页间哈希差异捕捉到改动的痕迹。5.2 用 pdftotext 加 diff 对比两个版本当实验报告出现 v1、v2 两个版本需要确认改动集中在哪里时别一张张打开 PD F 对比。把两个版本的文本按版式提取后用 diff 定位pdftotext -layout 2023河北工业大学操作系统实验报告_v1.pdf v1.txt pdftotext -layout 2023河北工业大学操作系统实验报告_v2.pdf v2.txt diff -u v1.txt v2.txt | lessdiff 输出的 -124,6 124,8 直接告诉你改动位于第 124 行附近。再回到 pdftotext 生成的行号就能把改动映射到 PDF 页。如果 diff 里大量行变动但内容没有实质差异通常是字体映射差异导致的字符替换例如全角括号被替换成半角。这种干扰可以通过先做iconv -f UTF-8 -t UTF-8 -c或统一规范标点来降低。5.3 让解析结果与参考文献对齐整理到最后一步需要用教材校正报告里的概念表述。比如《操作系统概念》第10版中文版里把条件变量称为等待队列王道操作系统则强调信号量和互斥锁的调度语义两边术语有差异但实验代码的行为必须一致。这时判断标准不是哪本书更“权威”而是报告代码里 wait 和 signal 的信号量顺序是否真的保障了互斥。验证时可以把代码中每个sem_wait和sem_post都打上标签比如t0 sem_wait empty再把输出日志按时间排序就能看出信号量是否被重复 release。这一操作不需要分析工具一行cut加sort就能完成./pconsumer | cut -d: -f1 | sort | uniq -c再把输出日志和 PDF 里的截图对照确认缺页次数、等待时间、协程切换次数三个数字完全一致。这样下来每一份实验报告都能从纸面变成可以重跑的代码操作系统期末复习时你手里就是一个自带验证结果的实验集合而不是几十页难以检索的 PDF。本文还有配套的精品资源点击获取
操作系统实验报告PDF解析：从文档到可复现代码的完整实践
简介2023年河北工业大学操作系统实验报告围绕Windows XP环境下进程的创建、观测与终止展开系统记录了控制台应用程序和GUI应用程序的设计、编译、调试与结果分析过程。报告以PDF格式提供共1个文件大小约7.8MB内容包含实验目的、软硬件环境、Hello控制台程序、MessageBox GUI程序、进程句柄获取与进程优先权查询等关键知识点并讨论了使用Word等非标准编辑器保存为.cpp文件、命令提示符下CL.EXE编译、user32.lib链接等注意事项还给出了常见编译错误、链接错误和运行时逻辑错误的排查方向。这份报告适合操作系统课程学生参考可帮助理解进程对象、句柄与优先权类等核心概念掌握Visual C 6.0下的Windows编程流程以及利用GetCurrentProcess、GetPriorityClass等API函数进行进程管理的方法。目前已有64人学习下载适合正在完成同类实验或复习进程管理知识的高校学生借鉴。1. 一份操作系统实验报告 PDF 从哪里读起“2023年河北工业大学操作系统实验报告.pdf”这个文件名在备考季被反复搜索。它看起来像一份学期末提交的电子作业实际上是把整门《计算机操作系统》的验证性内容装进了一个 PDF 外壳进程创建、信号量同步、管程和协程调度、内存分配与页面置换、文件系统断链与修复。每个主题都自带代码和运行结果。对没上过这门课的人它是入门例子对上过课的人它是期末复习提纲对准备面试的人它是一套随手能拿来讲的操作系统实验案例。问题在于这类报告很少保持原始代码的完整形态大多经过 Word 排版、导出、又转存成 PDF 的二次加工。直接打开阅读器翻页很难获得比截图更多的东西。我的处理套路是先做 PDF 解析把文本、表格、截图分层拆开再把实验代码按经典写法重建到 Linux 环境里最后用标准测试数据验证报告里的结论。这样做完一份 PDF 才能真正变成可检索、可复现、可对账的学习资料。2. 操作系统实验报告里常见的同步与资源管理模型2.1 实验模块是怎么排的从进程到文件系统拿到报告后第一件事不是读代码而是先建立心理目录。一份完整的操作系统实验报告章节顺序往往和课程讲授顺序一致进程管理、线程同步、调度算法、内存管理、文件系统。这个顺序不是随便排的它是操作系统从“资源抽象”到“资源分配”再到“资源持久化”的递进关系。你手头这份 PDF 无论页数多少内容基本都围绕这几块展开。实验模块与验证点的对应关系可以用下面的表格快速过一遍实验模块核心 API / 数据结构验证手段报告中的高频输出进程控制fork、exec、waitps、top、waitpidPID 分配和回收顺序线程同步sem_t、pthread_mutex多线程并发计数缓冲区不重叠、不丢包管程与协程条件变量、用户态上下文调度日志协程状态机输出调度算法FCFS / SJF / RR平均等待时间和周转时间甘特图与时间表内存管理页表、LRU / FIFO / CLOCK缺页率缺页次数对比表文件系统inode、目录项、软硬链接ls、df、stat磁盘结构示意图这份表最大的用途是定位“这份 PDF 到底覆盖到哪一步”。如果某一实验只有一句“实验成功”和一张截图没有算法流程说明也没有运行时参数说明原始报告的质量不高你在后面还原代码时需要自己补全设计。相反如果某个实验在正文里给出了输入参数和输出表格哪怕代码被 PDF 切得七零八落也仍能靠表格数据反推算法行为。操作系统的实验逻辑归根结底是让两个并发主体在共享资源上不打架。进程实验处理 fork 出来的孤儿进程和僵尸进程线程实验处理中断时机不确定下的共享计数器内存实验处理页表缺失时淘汰哪一页。三者本质一致资源有限访问无序需要仲裁机制。所以看实验报告时先问自己“这个实验仲裁的是什么”再去看代码理解成本会低很多。2.2 管程与协程报告里最容易被跳过的一节“管程和协程”几乎总落在课程大纲的中后段也最容易被实验报告一笔带过。难点在于管程和协程是两个不同层面的概念但在同步实验里经常同时出现。管程是语言层面的同步原语它把互斥区和条件等待封装成一个对象调用者不需要知道底层信号量怎么挂、挂几个协程是用户态执行流没有内核调度参与靠一个调度器在两个栈之间主动切换。一份认真写的实验报告管程部分必须能看到两个结构一个是入口互斥另一个是条件变量的 wait 和 signal 配对。常见错误是只调用 wait 不调用 signal或者条件变量被唤醒后不重新检查 while 条件导致报告结论和输出日志对不上。协程实验一般要求实现一个用户态调度器用一个 runqueue 保存待执行上下文每个协程 yield 时把寄存器保存进自己的任务控制块然后恢复下一个协程的上下文。代码量能压到 200 行以内但切换点和栈分配必须手工维护。王道操作系统里对管程的描述是“把资源数据结构和针对它的操作集中封装”放到实验代码里实际要求就是临界区变量不要跨模块直接读写。谁修改、谁读取、谁先排队等待全部收进一个 monitor 结构体信号量的初始值就变得容易推导。反过来如果在报告里看到结构体外部还在直接改共享缓冲区下标那说明代码和理论没有真正对上这种实验报告只能当提纲看不能照抄。2.3 同步实验代码一份可对照的 C 版本经典的生产者-消费者实验是几乎所有操作系统课都会出现的必做项目。下面的 C 代码是最常见版本的最小实现注释把信号量的申请释放位置标了出来#include stdio.h #include pthread.h #include semaphore.h #include unistd.h #define CAP 5 sem_t mutex, empty, full; int buf[CAP]; int in 0, out 0; void *producer(void *arg) { for (int i 0; i 10; i) { sem_wait(empty); // 有空闲位置才继续 sem_wait(mutex); // 进入临界区 buf[in] i; in (in 1) % CAP; printf(produce: %d\n, i); sem_post(mutex); // 离开临界区 sem_post(full); // 通知消费者 usleep(500); } return NULL; } void *consumer(void *arg) { for (int i 0; i 10; i) { sem_wait(full); // 有数据才继续 sem_wait(mutex); int v buf[out]; out (out 1) % CAP; printf(consume: %d\n, v); sem_post(mutex); sem_post(empty); // 释放一个空闲位置 usleep(800); } return NULL; } int main() { sem_init(mutex, 0, 1); sem_init(empty, 0, CAP); sem_init(full, 0, 0); pthread_t pid, cid; pthread_create(pid, NULL, producer, NULL); pthread_create(cid, NULL, consumer, NULL); pthread_join(pid, NULL); pthread_join(cid, NULL); sem_destroy(mutex); sem_destroy(empty); sem_destroy(full); return 0; }这段代码里要特别记录三组参数mutex 初始值固定是 1empty 初值等于缓冲区长度 CAPfull 初值是 0。三个信号量的语义不能互换否则日志里会出现消费者抢跑或生产者永久阻塞。这里的执行顺序也不能调错生产者在压入数据前必须等 empty消费者在读取数据前必须等 full两个 wait 的先后一旦颠倒缓冲区满时会出现死锁。一段正确的同步实验其输出应该只有“produce: i”和“consume: v”成对出现且同一个值不会出现两次。由于 printf 本身不保证原子输出不同线程的打印行会交错这不能说明程序有 bug但同一个编号出现两次则说明 in 或 out 的更新逻辑出了问题。这就是报告里“运行结果”一节的核心判断标准。3. 用 PDF 解析还原实验报告的内容结构3.1 先做文件体检页数和工具选型处理一个中文名长、可能是合并版的 PDF第一步不是直接打开阅读器翻页而是在命令行里确认文件本身是什么状态。我先执行这个命令pdfinfo 2023年河北工业大学操作系统实验报告.pdfpdfinfo 来自 poppler-utils它会返回页数、页面尺寸、加密状态、Producer 等信息。看到 Pages 是 30 以上通常说明报告包含了多个实验的多页截图看到 Producer 是 Microsoft Word说明 PDF 有文字层可以走文本提取路线看到 Producer 是扫描仪品牌说明整份是图片必须 OCR 才能抽内容。这里的关键是校检文件内部的真实结构而不是看后缀名。文件体检之后再决定工具组合。同一个 PDF不同场景应该用不同工具。我常用的配合如下工具安装方式适用场景输出类型pdfinfosudo apt install poppler-utils查看页数、元数据、加密信息纯文本元数据pdftotextpoppler-utils快速抓取全文可检索的 .txtpdfplumberpip install pdfplumber表格、坐标、复杂版式行级文本和二维表格PyMuPDFpip install PyMuPDF提取嵌入图片和对象信息图片对象、页面截图pdftoppmpoppler-utils整页转高分辨率图片150/300dpi PNG如果 PDF 是通过 Windows 自带 Microsoft Print to PDF 打印生成的文字层通常完整但没有书签和目录。问题不大pdftotext 仍可取出全部文本只是原本的目录导航无法用需要靠 grep 定位章节。这种“有字没目录”的状态在实验报告类 PDF 里非常普遍。3.2 用 pdfplumber 把文本与表格分层拆出来实验报告里经常出现分栏或嵌套表格直接整段复制会乱。原因是复制操作把字符按阅读顺序输出而 PDF 中每个字符仍保留坐标表格必须调用表格识别接口单独提取不能靠肉眼做横向拼接。先做一次粗提取看全文结构和主要关键词位置pdftotext -layout 2023年河北工业大学操作系统实验报告.pdf report.txt wc -l report.txt grep -n 实验 report.txt | head -n 40-layout 参数会保留文本的相对位置比默认模式的随机换行稳定得多。grep 输出行号能快速知道“信号量”“页面置换”出现在第几页后面对照代码时不需要一页页翻。但 pdftotext 对表格的处理是靠空格对齐遇到边框线拆开的单元格外行信息经常错位所以表格还要单独提取。我一般用 pdfplumber 提取表格和文本import pdfplumber with pdfplumber.open(2023年河北工业大学操作系统实验报告.pdf) as pdf: print(pages:, len(pdf.pages)) for i, page in enumerate(pdf.pages): text page.extract_text() or if 缺页 in text or FIFO in text: print(f--- page {i1} contains target ---) tables page.extract_tables() for table in tables: for row in table[:5]: print(row)extract_tables 返回的是二维列表每个 cell 对应 PDF 表格中的一个单元格空白位置是 None。要核对的实验数据比如 FIFO 和 LRU 的缺页次数都能通过这段代码回收到结构变量里。如果某个表提取出来只有一列这说明原表被印刷成图片不是文本型表格后续需要走图片识别。pdfplumber 在遇到页面角落的细线时偶尔会误判边界如果表格数据明显少一行可以调 horizontal_strategy 和 vertical_strategy 参数但要优先确认原表是否跨页。3.3 把代码块和截图从 PDF 里拆出来实验报告里的源码块通常用等宽字体页面里带灰色底纹PDF 解析时会被当作文本块的一部分。如果不处理复制出来的代码会混进“print 结果”和“实验环境”注释和换行全部丢失。更可靠的办法是把代码区和图片区拆开分别提取。先做图片提取用 PyMuPDF 可以按页拿到嵌入对象import fitz doc fitz.open(2023年河北工业大学操作系统实验报告.pdf) for page_no in range(doc.page_count): page doc[page_no] for img in page.get_images(fullTrue): xref img[0] pix fitz.Pixmap(doc, xref) if pix.n 3: pix fitz.Pixmap(fitz.csRGB, pix) pix.save(fpage{page_no1}_img{xref}.png)xref 是 PDF 内部对象编号get_images 返回的元组里第一个元素就是它。这里把带透明通道的图统一转成 RGB避免保存出的 PNG 在某些查看器里背景变黑。一个常见的坑是图片本身嵌入过多次导致 PDF 文件体积大但页面数量少提取后出现大量重复图片。这时可以用图片 md5 去重只保留每种哈希值的第一张。代码块同样可以从文本对象里按字体名筛选。pdfplumber 的 chars 对象中带有 fontname 和 sizeMonospace、Consolas、Courier 等字体名通常对应源码区中文宋体和黑体则对应正文。按 fontname 分组后对等宽字体字符按行聚类可以还原出比整页文本干净得多的代码段。之后把这些代码段保存成 .c 文件就有了可以真正编译运行的实验原形。4. 从 PDF 到可复现实验生产者消费与页面置换4.1 搭建可复现实验的 Linux 运行环境打开实验报告先看“实验环境”那一行。有的写 Windows 加 IDE有的写 Ubuntu Linux。无论原报告用什么系统操作系统实验的经典题目都依赖 POSIX API放在 Linux 下跑最省事。我通常选 Ubuntu 20.04.6 LTS官方仓库带的 gcc、gdb、valgrind 版本足够应付课程实验且 sem_t、pthread 这类库不需要额外换源。如果机器上已经有别的发行版也没必要重装系统用容器隔离即可。最小环境准备包含编译器和调试工具sudo apt update sudo apt install build-essential gdb valgrind gcc -stdc11 -pthread -Wall -Werror -o pconsumer pconsumer.c ./pconsumer-pthread 参数必须保留否则链接阶段会报 pthread_create 未定义-Wall -Werror 能提前暴露 usleep 需要隐蔽函数声明的问题例如缺少_DEFAULT_SOURCE。valgrind 主要用来检查线程退出后是否还有未释放的信号量虽然课程实验不强制但它能发现报告里代码在退出时少写 sem_destroy 的隐患。4.2 用经典引用串验证 FIFO 和 LRU 缺页率页面置换实验的核心数据是缺页次数。实验报告的正文会给出一个引用串常见的是 [7,0,1,2,0,3,0,4,2,3,0,3,2,1,2,0,1,7,0,1]。先不急着和报告里的截图对答案用 Python 模拟算法把所有缺页时刻打印出来。这样既能看到结论也能看到换页过程。from collections import deque ref [7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1] def fifo(reference, cap): mem, q, faults [], deque(), 0 for p in reference: if p not in mem: faults 1 if len(mem) cap: mem.append(p) q.append(p) else: old q.popleft() mem.remove(old) mem.append(p) q.append(p) return faults def lru(reference, cap): mem, last_used, faults [], {}, 0 for t, p in enumerate(reference): if p in mem: last_used[p] t continue faults 1 if len(mem) cap: mem.append(p) else: evict min(mem, keylambda x: last_used.get(x, -1)) mem.remove(evict) mem.append(p) last_used[p] t return faults for cap in (3, 4): print(fframes{cap} FIFO{fifo(ref, cap)} LRU{lru(ref, cap)})FIFO 用双端队列保存进入顺序队首就是最早进入的页换出的时候从队首取LRU 则不维护进入顺序而是记录每一页最后一次被访问的时间淘汰时选时间戳最小的那一个。需要留意的是min 函数遇到两个相同时间戳时返回的结果不稳定但对缺页总数没有影响因为帧内不存在两页同时被访问的相同时刻last_used 的值在同一轮循环里一定是不同时间戳。用上面的引用串跑 3 个帧FIFO 应有 15 个缺页LRU 应有 12 个缺页。这两个数字是页面置换实验的标准参照可以直接写入你的报告对照表帧数算法缺页次数说明3FIFO15总是淘汰最早进入的页3LRU12淘汰最久未被访问的页4FIFO9帧数增加缺页数下降4LRU10LRU 在某些串里不比 FIFO 好4.3 把报告里的结论做成可对账的测试用例报告里贴出的截图只能证明“跑过一次”不能证明代码在所有输入上都正确。把参照数据转成断言后就可以每次改动代码时都跑一遍检查防止实验结论被无意破坏assert fifo(ref, 3) 15, FIFO 3帧缺页数不对 assert lru(ref, 3) 12, LRU 3帧缺页数不对 print(report data consistent with standard reference string)这样处理后报告里的数字从“展示性结论”变成了“可验证契约”。后续如果再调整淘汰逻辑比如混用 CLOCK 算法或加了降级表只要断言没过就说明新逻辑改变了基本缺页行为需要重新评估。这里还要单独处理 Belady 异常。FIFO 在帧数增加时缺页数有时不降反升典型序列 [1,2,3,4,1,2,5,1,2,3,4,5] 在 3 帧时缺页 9 次在 4 帧时缺页 10 次。如果你的报告恰好选择这组数据并显示帧数增加但缺页数增加这其实是正确行为不要试图把结果“修正”成帧数越大缺页越少那样只会暴露你根本没跑过代码。5. 验证实验报告从 md5 到 diff 回放的关键一公里5.1 先校验文件指纹再做任何解析网上流传的这份 PDF 可能有多个修订版文件名相同内容却不同。解析前先算 md5后面排错时才能确认操作的是不是同一份文件md5sum 2023年河北工业大学操作系统实验报告.pdf如果后续提取文本的顺序不对或者表格数据和别人截图对不上先拿 md5 确认再怀疑解析代码。另一个实用动作是计算每页图像的哈希列表这是定位“哪一页被重新编辑过”的最快方法pdftoppm -png -r 150 2023年河北工业大学操作系统实验报告.pdf page md5sum page-*.png page_hashes.txt这套方法与 PDF 编辑器无关。即使你没有原稿也能通过页间哈希差异捕捉到改动的痕迹。5.2 用 pdftotext 加 diff 对比两个版本当实验报告出现 v1、v2 两个版本需要确认改动集中在哪里时别一张张打开 PD F 对比。把两个版本的文本按版式提取后用 diff 定位pdftotext -layout 2023河北工业大学操作系统实验报告_v1.pdf v1.txt pdftotext -layout 2023河北工业大学操作系统实验报告_v2.pdf v2.txt diff -u v1.txt v2.txt | lessdiff 输出的 -124,6 124,8 直接告诉你改动位于第 124 行附近。再回到 pdftotext 生成的行号就能把改动映射到 PDF 页。如果 diff 里大量行变动但内容没有实质差异通常是字体映射差异导致的字符替换例如全角括号被替换成半角。这种干扰可以通过先做iconv -f UTF-8 -t UTF-8 -c或统一规范标点来降低。5.3 让解析结果与参考文献对齐整理到最后一步需要用教材校正报告里的概念表述。比如《操作系统概念》第10版中文版里把条件变量称为等待队列王道操作系统则强调信号量和互斥锁的调度语义两边术语有差异但实验代码的行为必须一致。这时判断标准不是哪本书更“权威”而是报告代码里 wait 和 signal 的信号量顺序是否真的保障了互斥。验证时可以把代码中每个sem_wait和sem_post都打上标签比如t0 sem_wait empty再把输出日志按时间排序就能看出信号量是否被重复 release。这一操作不需要分析工具一行cut加sort就能完成./pconsumer | cut -d: -f1 | sort | uniq -c再把输出日志和 PDF 里的截图对照确认缺页次数、等待时间、协程切换次数三个数字完全一致。这样下来每一份实验报告都能从纸面变成可以重跑的代码操作系统期末复习时你手里就是一个自带验证结果的实验集合而不是几十页难以检索的 PDF。本文还有配套的精品资源点击获取
