简介本资源是天津理工大学操作系统课程的实验一完整实现包面向计算机专业本科生及操作系统初学者聚焦进程调度核心机制的理解与编程实践。实验基于优先权调度算法要求构建PCB结构、实现就绪队列链表管理、动态更新进程优先级与剩余运行时间并可视化调度全过程有效支撑课堂理论向代码落地的转化。压缩包共2个文件593KB含C语言源码pcb.c实现全部调度逻辑可直接编译运行配套Word文档os实验报告.doc详述实验目的、设计思路、数据结构定义、关键代码说明及运行结果截图便于理解原理与撰写报告。已有792人学习下载内容精炼、结构清晰代码规范注释完整报告逻辑严谨特别适合课程实验复现、算法调试参考及期末复习巩固。1. 天津理工大学操作系统实验报告一从 PCB.c 入手搞懂进程控制块与 Linux 环境下的真实调度痕迹这不是一份“交完就扔”的实验报告——它是一份能让你在ps -eo pid,ppid,comm,state,pri,nice,%cpu,%mem,vsz,rss,tty,stime,time,cmd输出里一眼认出自己写的进程、理解fork()后父子进程内存为何“看似共享实则隔离”、甚至能手动 patch 一个简易 PCB 结构体并观察其在/proc/[pid]/stat中映射关系的实战入口。天津理工大学《操作系统》课程实验一核心载体是pcb.c文件它不跑在虚拟机里不依赖图形界面而是在你本地 Linux 终端敲gcc -o pcb pcb.c ./pcb后用strace -f ./pcb能清晰看到clone(),wait4(),sched_yield()的调用链用cat /proc/$(pidof pcb)/status | grep -E Tgid|PPid|State|Threads能直接验证你代码里定义的 PCB 字段是否被内核真正感知。适合刚学完进程概念、正卡在“课本说 PCB 是进程唯一标识可我连它长什么样都没见过”的同学也适合想甩开教材、用真实系统反推理论边界的进阶者。别被“实验报告”四个字劝退——这份材料的价值在于它把抽象的“进程控制块”从黑匣子变成可读、可改、可 trace 的 C 结构体且所有操作均基于标准 Linux 5.10 内核接口Ubuntu 22.04 / CentOS 8 / Debian 12 均可原生支持。2. 从pcb.c源码结构到 Linux 进程模型为什么这个文件必须包含struct task_struct的简化映射2.1pcb.c的典型骨架不是教科书伪码而是可编译的最小 PCB 实现天津理工大学实验一提供的pcb.c或学生自编版本通常包含以下核心模块自定义 PCB 结构体声明常见为struct pcb { int pid; int ppid; char state; int priority; int cpu_time; char name[16]; };全局 PCB 数组或链表管理如struct pcb pcb_table[MAX_PROC] {0};或struct pcb *head NULL;进程创建模拟函数int create_process(char *name, int priority)内部调用fork()并填充 PCB 字段进程状态切换逻辑void change_state(int pid, char new_state)修改pcb_table[i].state并可能触发kill(pid, SIGSTOP)主循环与调度示意while (running) { schedule(); sleep(1); }其中schedule()遍历 PCB 表选择下一个运行进程提示该文件不实现真正的内核级调度器而是用用户态逻辑模拟“就绪队列→运行态→阻塞态”的流转。它的价值在于强制你思考当fork()返回后父子进程各自的pid、ppid、state如何同步更新priority字段如何影响nice值这些字段在/proc/[pid]/stat中对应哪些数字位2.2 为什么必须对照 Linux 内核task_struct理解你的pcb.cLinux 内核中真实的进程描述符定义在include/linux/sched.h核心结构体struct task_struct超过 150 个字段仅task_struct本身但实验一的pcb.c只需关注其可被用户空间观测的子集pcb.c字段对应内核字段task_struct/proc/[pid]/stat位置用户空间验证命令pidpid第1列ps -o pid -p $(pidof pcb)ppidparent-pid第4列ps -o ppid -p $(pidof pcb)statestate数值第3列R/S/D/T/Zps -o stat -p $(pidof pcb)prioritystatic_prio经nice调整第19列priorityps -o pri -p $(pidof pcb)cpu_timeutime stimejiffies第1415列utime/stimeps -o time -p $(pidof pcb)关键点在于你的pcb.c中priority字段若直接赋值给nice需通过setpriority(PRIO_PROCESS, pid, nice_value)系统调用生效若仅存于用户态数组则仅用于模拟调度逻辑不会影响真实 CPU 时间片分配。这是实验一最易混淆的边界——区分“模拟调度”与“真实调度”。2.3 编译与调试环境准备避开claude.exe类错误的底层逻辑标题中出现的“程序claude.exe无法运行指定的可执行文件不是此操作系统平台的有效应用程序”本质是 Windows PE 格式二进制在 Linux 上执行失败。而pcb.c必须在 Linux 环境编译# 确认系统架构避免 x86_64 机器误装 arm64 工具链 uname -m # 应输出 x86_64 或 aarch64 # 安装基础编译工具Ubuntu/Debian sudo apt update sudo apt install -y build-essential procps strace # 编译时显式指定标准避免隐式 C11 导致 struct 初始化差异 gcc -stdc99 -Wall -Wextra -o pcb pcb.c # 验证可执行文件格式必须为 ELF非 PE/COFF file pcb # 输出应含 ELF 64-bit LSB pie executable, x86-64逻辑说明file命令检查二进制格式是第一道防线。若输出含PE32或MS-DOS executable说明你误用了 Windows 交叉编译器或下载了错误文件。-stdc99参数确保结构体初始化如struct pcb p {0};行为符合实验预期避免 C11 的隐式零初始化引发字段偏移错乱。3. 用strace和/proc接口验证 PCB 操作的真实性让每行代码都有系统调用回响3.1strace -f ./pcb捕获 fork/wait/sched_yield 的完整生命周期在pcb.c的create_process()函数中插入printf(Creating process %s\n, name);后编译运行strace -f -e traceclone,wait4,sched_yield,kill -o trace.log ./pcb你会看到类似输出[pid 12345] clone(child_stackNULL, flagsCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr0x7f8b1c0a2a10) 12346 [pid 12345] wait4(-1, [{WIFEXITED(s) WEXITSTATUS(s) 0}], 0, NULL) 12346 [pid 12346] sched_yield() 0参数说明-f跟踪所有子进程fork()/clone()创建的-e trace...只显示指定系统调用避免海量read/write干扰clone()的flags参数中SIGCHLD表明父进程需处理子进程终止信号这正是wait4()被触发的原因wait4()返回值12346即子进程 PID证明你的create_process()成功获取了新进程 ID注意若strace输出中无clone()或wait4()说明pcb.c中未调用fork()或wait()此时你的“进程创建”只是内存数组赋值未进入内核调度视野。3.2 解析/proc/[pid]/stat将 PCB 字段映射到内核实时状态假设./pcb进程 PID 为12345执行# 获取 stat 文件全部字段共 52 列以空格分隔 cat /proc/12345/stat | awk {print $1,$2,$3,$4,$14,$15,$19,$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} # 提取关键字段PID, COMM, STATE, PPID, UTIME, STIME, PRIORITY, NICE, NUM_THREADS cat /proc/12345/stat | awk {printf PID:%s COMM:%s STATE:%s PPID:%s UT:%s ST:%s PRI:%s NICE:%s THREADS:%s\n, $1,$2,$3,$4,$14,$15,$19,$20,$23}字段对应关系/proc/[pid]/stat第 n 列$1PID进程 ID$2COMM进程名括号内如(pcb)$3STATER运行 S睡眠 D不可中断睡眠 T停止 Z僵尸$4PPID父进程 ID$14UTIME用户态 CPU 时间单位 jiffies$15STIME内核态 CPU 时间单位 jiffies$19PRIORITY内核调度优先级范围 0-139值越小优先级越高$20NICE用户态优先级调整值范围 -20 到 19$23NUM_THREADS线程数你的pcb.c若在create_process()中调用setpriority(PRIO_PROCESS, pid, 10)则$20应变为10若修改pcb_table[i].state R但/proc/12345/stat第3列仍为S说明该字段未与内核状态同步——这是用户态模拟与内核真实状态的天然鸿沟。3.3 用ps命令交叉验证避免ps显示与proc文件不一致的陷阱ps命令默认显示的是/proc/[pid]/stat的解析结果但存在缓存和权限限制# 强制刷新 ps 缓存避免旧状态残留 ps -eo pid,ppid,comm,state,pri,nice,%cpu,%mem,vsz,rss,tty,stime,time,cmd --sort-%cpu | head -10 # 检查当前进程的完整命令行验证 name 字段是否被正确设置 ps -o pid,comm,args -p $(pidof pcb)关键区别comm显示argv[0]的 basename最多 15 字符而args显示完整命令行ps的state列S/R/D/T/Z与/proc/[pid]/stat第3列一一对应但ps可能因权限不足无法读取某些进程的stat文件如 init 进程此时显示?若pcb.c中name字段设为my_proc但ps显示pcb说明你未修改argv[0]需在execv()中传入新argv4. 避坑指南pcb.c实验中最常踩的 5 个深坑与血泪修复方案4.1 现象fork()后子进程 PID 在 PCB 表中始终为 0原因fork()在子进程中返回 0但学生常误将pid fork()的返回值直接存入 PCB 表导致子进程记录的 PID 为 0。正确做法是父进程记录子 PID子进程需调用getpid()获取自身 PID。解决pid_t pid fork(); if (pid 0) { // 子进程 int my_pid getpid(); // 必须用 getpid() update_pcb(my_pid, child, ...); exit(0); } else if (pid 0) { // 父进程 update_pcb(pid, parent, ...); // 此处 pid 即子 PID }4.2 现象ps显示进程状态为Z僵尸但wait()未回收原因fork()后父进程未调用wait()或waitpid()子进程终止后成为僵尸进程占用 PID 和 PCB 表项。解决在父进程循环中加入非阻塞waitpid(-1, status, WNOHANG)pid_t wpid; while ((wpid waitpid(-1, status, WNOHANG)) 0) { printf(Child %d exited\n, wpid); remove_from_pcb_table(wpid); // 清理 PCB 表 }4.3 现象setpriority()失败返回 -1errno1Operation not permitted原因普通用户无法提升进程优先级降低nice值只能增加nice降低优先级。且PRIO_PROCESS需要目标进程属于同一用户。解决仅对自身进程调用setpriority(PRIO_PROCESS, 0, 10)0表示当前进程或使用nice()系统调用nice(10)等价于setpriority(PRIO_PROCESS, 0, 10)若需修改其他进程必须以 root 运行或配置CAP_SYS_NICE能力4.4 现象/proc/[pid]/stat中PPID显示为 1init 进程而非预期父 PID原因父进程提前退出子进程被 init 进程收养PPID自动变为 1。解决确保父进程在子进程结束前持续运行或使用prctl(PR_SET_CHILD_SUBREAPER, 1)让父进程成为子进程的“次级收割者”需 Linux 3.4#include sys/prctl.h prctl(PR_SET_CHILD_SUBREAPER, 1); // 父进程退出后子进程由本进程收养4.5 现象strace显示clone()成功但ps找不到子进程原因子进程执行极快fork()后立即exit()在ps扫描/proc时已消亡。解决在子进程中加入延时或阻塞操作if (pid 0) { printf(Child running...\n); sleep(5); // 保持存活 5 秒便于观察 exit(0); }5. 进阶技巧用ptrace动态注入 PCB 字段到内核态实现用户态与内核态 PCB 的双向同步5.1 为什么需要ptrace——突破用户态模拟的天花板pcb.c的核心局限在于所有字段仅存在于用户内存内核完全不知情。若想让ps的PRI列真实反映你 PCB 中的priority字段必须修改内核task_struct的static_prio。ptrace是 Linux 提供的调试接口允许一个进程tracer控制另一个进程tracee的执行并读写其内存和寄存器。虽然不能直接修改内核数据结构需 root 权限且风险极高但可通过ptrace(PTRACE_ATTACH, pid, 0, 0)暂停目标进程再用ptrace(PTRACE_PEEKTEXT, pid, addr, 0)读取其内存找到task_struct地址需/proc/[pid]/maps配合符号表进而定位static_prio偏移量。注意此操作仅限学习研究生产环境严禁使用。现代内核启用 KASLR内核地址空间布局随机化和 SMAPSupervisor Mode Access Prevention直接读写内核内存会导致SIGSEGV。5.2 安全可行的替代方案用cgroupsv2 控制进程资源间接映射 PCB 优先级更实用的做法是放弃修改内核转而用cgroups将pcb.c创建的进程纳入特定控制组通过cpu.weight控制 CPU 时间份额# 创建 cgroup需 root sudo mkdir -p /sys/fs/cgroup/pcb_group echo $$ | sudo tee /sys/fs/cgroup/pcb_group/cgroup.procs # 将当前 shell 加入 # 设置 CPU 权重100-10000100 为最低 echo 500 | sudo tee /sys/fs/cgroup/pcb_group/cpu.weight # 启动 pcb 程序并加入该 cgroup sudo sh -c echo \$\$ /sys/fs/cgroup/pcb_group/cgroup.procs ./pcb此时pcb.c中的priority字段可映射为cpu.weight值priority10→cpu.weight1000priority5→cpu.weight500。ps的%CPU列会真实反映该权重下的 CPU 占用率这才是操作系统层面的“优先级”。5.3 验证 PCB 字段与 cgroups 效果的量化方法编写验证脚本verify_pcb.sh#!/bin/bash # 启动 pcb 并获取 PID ./pcb PID$! sleep 2 # 记录 cgroup 设置 WEIGHT$(cat /sys/fs/cgroup/pcb_group/cpu.weight 2/dev/null || echo N/A) echo Cgroup weight: $WEIGHT # 持续采样 10 秒内的 CPU 使用率 for i in {1..10}; do CPU$(ps -o %cpu -p $PID 2/dev/null | xargs) echo Time $i: CPU${CPU:-0}% sleep 1 done # 清理 sudo kill $PID 2/dev/null sudo rmdir /sys/fs/cgroup/pcb_group 2/dev/null运行后若WEIGHT1000时平均%CPU为 15%WEIGHT200时降为 3%则证明你的pcb.c中priority字段已通过 cgroups 实现了可测量、可复现的系统级优先级映射——这比单纯修改用户态数组更有工程价值。我带过三届天津理工的操作系统实验课最深的教训是别急着交报告先strace你的pcb.c再cat /proc/$(pidof pcb)/stat最后ps -eo pid,ppid,comm,state,pri,nice --sort-pri。当这三行命令的输出能互相印证你才算真正摸到了进程控制块的脉搏。那些在pcb.c里写满注释却没看过一次strace输出的同学期末考调度算法时总会卡在“为什么就绪队列里的进程没被选中”——因为他们的 PCB 从未进入内核视野。希望帮到你。本文还有配套的精品资源点击获取