BUAA-UNIT2-总结

樊浩宇+22371055 学生 2024-04-19 16:58:24

前言
这是一个多线程的单元
这次多线程单元真的太有趣了（痛苦），因为多线程这个神奇的操作，让我写的时候对线程之间的操作很模糊，对互斥同步不理解。在熟悉了相关知识后，还有点迷茫，尤其在Debug时候，bug复现起来很困难，概率很小出现，不过De出来还是很开心呢。总的来说，一个美妙且艰辛的第二单元已经度过，也掌握了不少知识！

第五次作业要求
模拟一个电梯系统，楼座内有6部电梯，电梯可以在楼座内1-11层之间运行。

系统从标准输入中读入乘客请求信息(起点层，终点楼层)，调度器会根据此时电梯运行情况(电梯所在楼层，运行方向等)将乘客请求合理分配给某部电梯，然后被分配请求的电梯会经过上下行，开关门，乘客进入/离开电梯等动作将乘客从起点层运送到终点层。

请求的输入通过官方提供的输入接口来定时投放请求，输出也通过官方接口输出。

时序图

UML

线程设计
使用了生产者-消费者模式

输入线程（InputHandler）作为生产者，从终端获得请求。调度器线程（Schedule）负责调度，把输入线程收到的请求送到请求池（RequestTable）中。电梯线程（ElevatorProcessing）作为消费者，从请求池（RequesetTable）中获取请求并不断地进行状态更新。

可以看到作业的要求是很简单的，指定了哪部电梯承载哪个乘客，无需我们分配。

由于本次作业的共享对象只有请求池类（RequesetTable），因此对请求池中的所有方法上锁即可保证线程安全，采用$synchronized$上锁来正确性，就可以完成这次作业。

调度策略
采用简单的LOOK策略，而没有采用ASL调度策略（往届LOOK算法太优秀）

锁的设置
请求队列 RequestTable 可以同时被调度线程和电梯线程访问，因此存在线程安全问题。在这项作业中，对 RequestTable 涉及到成员变量读写的方法都使用简单粗暴的方式进行直接锁定，以确保每次只有一个线程访问请求队列。这种方法虽然可行，但可能会出现难以描述的错误，查找起来相当费力。

第六次作业要求
在第五次作业的基础上，增加如下迭代要求：
1.不指定接某个乘客的固定电梯，需要自行调度
2.新增RESET指令输入和RECEIVE指令输出
时序图

UML

新增加了Reset指令和Receive输出。
Reset
我采用一个小巧的方法，把Reset指令看作一个特殊的人（Id = 0）,对于这个特殊的请求，不用更改第一次addRequset()的notify策略。每次RequestTable中存在这个特殊的人，就立刻进行Reset。

Reset丢到Look策略中，优先级最高，且每次电梯运行，都判断一次Reset的有无。
在第一次作业的UML和这次UML方法增多，而没有新增类，可见第一次整体框架良好。

调度策略
采用最近最优和随机数相结合，即

    遍历六个电梯：
    if（电梯没有start()）{
        分配到该电梯；
    } else {
        根据楼层和方向，最快最优策略；
    }
    以上找到返回true，否则返回false；
    if（false） 随机数算法

该电梯分配策略相对性能较高，且便于操作实现。

第七次作业要求
在第六次作业的基础上，增加如下迭代要求：
1.引入新的重置指令要求
2.支持双轿厢电梯运行

UML

大体框架不变，只增加相关方法双轿厢电梯的方法，6电梯变12电梯。
调度器仍然与hw6类似，加入Double的调度，实现起来困难了点。

如何避免双轿厢碰撞呢？
采用辅助标记，如果在共享楼层，标记置一，后到的电梯要等一等，然后离开，标记取消，后来电梯到。

debug
只能一点一点瞪眼法和Print大法结合。

在第六次出现了RTLE的bug，五个在reset，一个已经完成reset，我的调度策略则是分配到这个完成的电梯，会出现60个人上一个电梯的超时！在后面随机算法中添加了伪随机，根据Wait的人进行相对分配。

第七次作业出现了CTLE，让我百般苦恼，本地无法查找CUP超时的bug，发现双轿厢电梯的结束不是那么简单，还需要判断电梯是否都在等待和都不在Reset！

心得与体会
体会到了多线程的奇妙之处和Debug困难之处。
首先要保证线程安全，我是对方法加锁，加了好多好多，会出现死锁的频率高了点。
尽量少加锁，理清层次和对象关系。
然后学会取舍和性价比为先，采用影子电梯固然性能高，但是我采用符合自己能力调度策略。
最后，多线程是结束了，但是多线程这种需要厘清代码之间逻辑关系的想法要保留住。

...全文