OO第二次博客作业

Posted 2020-11-02 zrst

第五次作业：多线程电梯

多线程的协同和同步控制：

本次作业一共有以下几个线程：读入处理线程inputHandler，单个电梯运行线程elevatorRun*3，任务分派线程newNewDispatch。

inputHandler线程用来读入并判断是否合法，提取指令并将其放入总指令队列。

每个elevatorRun线程负责调度一个电梯，有自己的一个指令队列，操纵这台电梯按照指令队列的要求运行，有点类似上一次的dispatch。

newNewDispatch负责根据floor亮灯情况和每个电梯的状态等从总指令队列取出指令并放进每个电梯的指令队列。

需要进行处理的是inputHandler与newNewDispatch共同操作中指令队列；newNewDispatch和exevatorRun操作floor和elevator

对于前一个，简单的锁总指令队列即可。

对于后一个，为了避免死锁，我请求状态时按照电梯顺序分别锁电梯123，其他情况下锁需要使用的电梯。

度量分析

 

主要问题是在调度类中为了省事大量使用了重复的代码。此外在使用前几次的代码时修补bug也增加了许多补丁式的代码，增加了长度与复杂度。

BUG分析

我在电梯调度分配上出了些奇怪的问题，导致了有些情况下捎带指令没有被捎带。

我拿到的那位是一个巨佬，洋洋洒洒写了10个类，快2k行代码，测了一下并没有任何bug

第六次作业：IFTTT

多线程的协同和同步控制：

本次作业一共有以下几个线程：读入处理线程inputHandler，监控线程*n

这次的相对比较简单，主要冲突在输出问价上。对summary和detail输出分别加锁就好了。

度量分析

问题在于监控时把四种方法写在一起用了一个而没有分开。我使用了switch+一段代码的模式，看上去也比较清晰，但是会导致代码过长。

BUG分析

对方并没有给我公测，根据我自己测试结果来看过公测没有什么问题，但是互测中应该是能发现一些小问题的。

我拿到的那一份写的比较一般，基本随手就能找到bug，公测挂了好几个点。测完公测后简单又测了一下，发现甚至不能定位错误原因，搞得我也不知道是不是有一个问题导致的错误，最后挂了一个点以后放弃了进一步测试。

 

第七次作业：出租车1

多线程的协同和同步控制：

本次作业一共有以下几个线程：出租车线程*100，调度分配线程*运行的指令个数，读入处理线程

产生冲突的主要是出租车选单，出租车当前状态，任务派单时对出租车的访问

度量分析

在处理接单等任务时处理逻辑还是有点复杂。本来写的想法有漏洞，后来在修补时把那里的代码搞得很乱。

BUG分析

直接使用了助教提供的GUI中的bfs算法计算最短距离，现在发现提供的实现运算太慢了，单次误差有几十毫秒，一次性输入几百条时直接卡死了。下次作业时要把这段重写了。

此外，接到乘客时忘记sleep了。

心得体会

写代码前要认真规划，防止写到一半发现问题再重新添加的情况。虽然修改代码可以解决大部分的bug，可是这会导致自己的代码越来越长，检查时会十分不爽。