我会构建健壮的多线程电梯评测机
我会构建健壮的多线程电梯评测机:smiley:已同步更新至本人blog，欢迎大家来参观:blush: 对于像电梯这样的复杂的、行为不确定的并发系统，构建自动化、系统化、能够进行状态跟踪和规则检查的测试框架，是确保程序正确性、提高开发效率的必备手段。直接手动测试覆盖面有限，且难以复现并发问题。因此，构建一个自动化的、能够生成有强度数据的、能够精确判定正确性的评测机就显得尤为必要。同学，你也不想你的代码被我们hack吧 在经历了 HW5 到 HW6 的迭代后，电梯系统的规则变得更加复杂。在此之前，我和舍友合力搭建了一套基于 Python 的自动化评测框架，希望能较为全面地测试电梯程序的健壮性和性能。经过了一次迭代，该评测机的性能和正确性能够做到更优。在此，我想分享一下这套评测机的核心思路和实现细节，希望能为大家提供一些参考 一、 核心组件概览我们的评测机主要由以下 Python 脚本构成： generate_data.py: 负责生成符合要求的、具有不同侧重点和强度的测试输入数据 (stdin.txt)，包括乘客请求和临时调度 (SCHE) 请求 validator.py: 核心...
BUAA_OO_Unit1_单元总结
「BUAA OO」第一单元总结总览使用MetricsReload插件对我的项目进行分析，得到类的复杂度如下图所示，整体来看，主要复杂度高的地方在第二次作业和第三次作业迭代的地方，这也与我设计上有所欠缺有关。 架构优点 分类明确。每个类都处理好自己的工作，相互没有过多交集，所有的get方法我都是返回一个映射而非返回类成员本身，符合面向对象封装的思想。 可迭代性好。整体的迭代工作并不困难。 架构缺点 可读性差。在函数因子FuncFactor与函数定义FuncCall里面，在参数处理方面，我写了很大的if - else分支，导致了代码可读性很差，而且这样很容易漏掉一些情况，这也与我强测寄了有一定的联系 重复性高。出于一些原因其实就是懒，我没有对代码进行重构，导致在递推函数FuncFactor和普通函数SimpleFuncFactor里面存在大量的代码重复，没有提炼成合理的方法，确实是不可取的地方。 类图如下 第一次作业设计思路设计思路上，我套用了之前OOpre的第七次作业给的递归下降的模版，从表达式逐层下降解析，直到把整个表达式解析完成。在预处理和最后的化简阶段，我使用了一些...
BUAA_OS_Lab1_实验报告
思考题Thinking 1.1 在阅读 附录中的编译链接详解 以及本章内容后，尝试分别使用实验环境中的原生 x86 工具链（gcc、ld、readelf、objdump 等）和 MIPS 交叉编译工具链（带有mips-linux-gnu- 前缀，如 mips-linux-gnu-gcc、mips-linux-gnu-ld），重复其中的编译和解析过程，观察相应的结果，并解释其中向 objdump 传入的参数的含义。 指导书中提到的objdump指令为 1objdump -DS 要反汇编的目标文件名 > 导出文本文件名 其中： -D表示：反汇编（Disassemble）那些预计包含指令的所有节区。 -S表示：在反汇编输出中，尽可能地将源代码（如果编译时包含了调试信息，通常是使用 gcc -g 编译）与汇编代码交错显示。这对于理解某段汇编代码对应哪行 C/C++ 源代码非常有帮助。通常需要与-d或-D一起使用。 -d表示：反汇编那些预计包含指令的代码节区。 首先，编写一个简单的程序helloworld.c，如下 12345#include <stdio.h&...
BUAA_OS_Lab0_实验报告
思考题Thinking 0.1执行git status > Untracked.txt，是查询当前README.txt的文件状态，并将其记录在Untracked.txt文件中。后续两个命令同理。 执行完cat Untracked.txt后，显示出未跟踪的文件，说明文件刚刚新建的时候，其处于未跟踪的状态；执行cat Stage.txt后，显示出要提交的变更，说明修改了文件，并使用add命令之后，文件处于暂存的状态；执行cat Modified.txt之后，显示出尚未暂存以备提交的变更，说明文件再被修改之后，处于被修改状态。 Thinking 0.2add the file 对应的是git中的git add命令 stage the file 对应的也是git中的git add命令 commit 对应的是git中的git commit命令 Thinking 0.3 git checkout --print.c git reset HEAD print.c && git checkout --print.c git rm --cached hello.txt Th...
