OO_第二单元总结

第一次作业

乘客的请求信息:起点层和终点层不同,起点座和终点座相同。如1-FROM-A-1-TO-A-2
思路:采用LOOK策略。若同方向上没有请求且电梯里的乘客的目的地都在反方向,则转换电梯运行方向。(捎带前往目的地与电梯运行方向相同的乘客)

UML类图

自己程序的bug

输出时间戳没递增。

第二次作业

乘客的请求信息:[起点座 == 终点座] + [起点层 == 终点层] == 1,即楼座和楼层两者中有且仅有一个相同。如1-FROM-C-7-TO-A-7
思路:横向电梯的调度策略与LOOK策略类似。判断方向的方法:若顺时针更近则方向为右,若逆时针更近则方向为左。(优先捎带前往目的地与电梯运行方向相同的乘客,再捎带在当前层等待进入电梯的乘客)
采用自由竞争,让电梯去抢请求,哪个电梯快,乘客就坐哪个电梯。

UML类图

自己程序的bug

终于没有bug了,高兴TvT。

第三次作业

乘客的请求信息:[起点座 == 终点座] + [起点层 == 终点层] != 2,即楼座和楼层不会同时相同。如1-FROM-A-4-TO-C-3
思路:将请求分成好几段(最多三段),当完成一段请求后,就根据该请求的下一段请求信息put进相应的processingQueue,直到完成所有段则完成了一个乘客请求。
需要用Counter来记录完成的请求数量,所有的请求完成后,才结束所有电梯线程(记得notifyAll)。

UML类图

自己程序的bug

忽略了可达性问题,强测和互测都被hack烂了,快乐的时光总是那么短暂。

UML协作图

同步块的设置和锁的选择

明确共享对象以及哪个线程对共享对象进行写操作,哪个线程对共享对象进行读操作,在这些操作中访问共享对象时需要加上锁,确保在同一时刻只有一个线程在访问共享资源。(使用synchronized加锁)
在第一次作业中创建了共享类对象,所以在加锁的时候,只需要在该类的方法上加上synchronized就可以了,这样方便了很多,也比较难出错。
三次作业中的共享对象都是waitQueue和processingQueue,所以在对它们俩进行操作时要多上点心。
锁与同步块中处理语句之间的关系:若线程A进入同步块获取锁后,其他线程还想要进入同步块获取同个锁是不行的,只能阻塞在外面,直到线程A退出同步块释放锁,其他线程才可以获取锁。

调度器设计

以生产者消费者模式的角度来看,生产者(InputThread)生成A-O类的请求,我的调度器会负责将这些请求分配给相应的消费者。如将A类请求分给处理A类请求的消费者A(Elevator),将B类请求分给处理B类请求的消费者B......
第一次作业:只有纵向电梯,所以只需要根据电梯的楼座ID分配。
第二次作业:引入了横向电梯,根据横向电梯的楼层ID或纵向电梯的楼座ID分配。
第三次作业:和第二次作业一样。

发现别人程序bug所采用的策略

用测试自己代码的数据拿去测试别人(重复利用 😄),然后再稍微写点自己认为比较强的数据(好像只能这样了)。

心得体会

觉得架构上比较有优势(参考了实验课和讨论区提供的思路),所以比较少出现线程安全或死锁问题,比较常遇到的问题是轮询。还有就是在写多线程的时候可以稍微注意一下原子操作。

posted @ 2022-05-03 13:42  日常写bug的路人甲  阅读(8)  评论(1编辑  收藏  举报