301
社区成员
发帖
与我相关
我的任务
分享BUAA-面向对象设计与构造2024-第二单元总结
前言
此篇主要围绕hw5和hw6。
程序架构分析
UML类图
hw5和hw6的架构主要参考了实验的代码架构，采用生产者-消费者模式，总共分为3类线程：输入线程，调度器和电梯线程，线程之间通过队列等共享空间传输信息。
主要流程：输入线程读取每个请求，并实例化加入总的请求等待队列；而调度器从这个队列中取一个请求，并按要求中指定的电梯或是自行按顺序分配给指定电梯线程自己的等待队列；电梯线程获取一个请求，将其视为主请求，进行一系列的运行，将请求送达。
调度器设计与调度策略
hw5的调度器实际上没有实质性上的调度，即从总队列中读取一个请求，并按请求分配给指定电梯线程的等待队列。
对于hw6的调度器（主要）：
首先还是从总队列中读取一个请求，然后根据请求是乘客请求还是重置请求，分别处理。
重置请求的话，会按重置请求分配给指定电梯的重置队列。
乘客请求的话，针对于互测时会出现同一时间输入很多请求的情况，前四五十个请求会依次分配给每部电梯线程等待队列，之后通过电梯的状态线程获取电梯的最新状态，将请求分配给能捎带的电梯线程等待队列。
hw6中调度器线程和每部电梯线程之间共享电梯的乘客请求等待队列、重置请求等待队列、电梯状态队列。
先平均分配再根据电梯状态分配的调度策略在hw6中强测和互测中都没有什么大问题，相较于影子电梯或是打分，性能上肯定还是差一点。
电梯运行策略（hw6）
- 首先会判断是否有重置请求，有进行重置处理：将电梯内的请求复制一份，并将内部请求都out开始重置；重置完成后，按顺序尽量将out的请求都加入内部，多余的请求改动起始层后加回等待队列的头部。
- 乘客请求处理：
- 乘客请求队列有请求且内部无请求的话，读取一个请求视为主请求，接送主请求，在接送过程中每到达一层判断是否有请求能捎带进行捎带。
- 乘客请求队列有请求且内部有请求的话，则视内部第一个请求为主请求，送主请求，在接送过程中每到达一层判断是否有请求能捎带进行捎带。
- 乘客请求队列无请求但内部有请求，同上。
- 乘客请求队列和内部都无请求，则电梯进行等待直到调度器往等待队列中加入一个请求唤醒电梯线程。
同步块的设置和锁的选择
我在共享队列的每个读写方法都加了synchronized确保线程安全。
复杂度分析
Class Metrics
hw5
hw6
代码量分析
hw5
hw5有效代码行数为401行。
hw6
hw6有效代码行数为801行。
Debug
主要通过prinIn观察代码的执行情况。
出现过的bug挺多，多为代码逻辑执行的顺序错误，线程不结束等。
调度bug：同一时间输入大量请求，调度器来不及获取到最新的电梯状态，从而将大量的请求分配给一部电梯。
关于hw7
hw7差在双轿厢不碰撞没有完成。
改动的地方主要是：
- 重置成双轿厢电梯时开启B电梯线程，原来的线程即为A电梯线程。两者共用一个乘客请求队列，以及总的未完成请求队列。
- 两者从队列中取请求时会判断是否起始层是否为管辖范围，只拿取自己能运行的起始层的请求。
- 原来hw6电梯重置时采取尽量将放出去的乘客在重置完成后放回，放不下则加入等待队列的头部。hw7则先改动乘客的起始层，并将全部放回请求队列头部。
- A和B电梯在到达转换层时会将放出的乘客的起始层改为转换层。
- 线程结束条件的改动：新增总的未完成请求队列为空时才能结束，其中一个结束时会唤醒另一部，重新判定一次条件，以防等待不能唤醒。
心得体会
第二单元作业相较于第一单元作业更容易上手，但在实现电梯的运行策略、调度策略等时，还是有很多细节需要注意的。
- 线程安全方面，第一次提交的时候，发现CPU运行超时了，原因是线程等不到请求一直在轮询，之后加入了无请求时就wait顺利解决了。
- 层次化设计方面，从hw5到hw6，我新增了BaseRequest类作为所有请求的基础类，新增了重置请求类和原来的乘客请求类继承了BaseRequest；新增了电梯状态队列和电梯状态类作为调度器和电梯线程之间的共享空间；在电梯线程中新增修改receive等输出逻辑。
总的来说，除了hw7因为时间分配的问题，还差一点最终没能完成，有点可惜。除此之外，第二单元的整个学习过程还是满意的。
...全文
请发表友善的回复…
发表回复
