oo第二单元总结

oo第二单元总结


第一次作业

同步
  • 第一次作业中只有请求队列Queue共享给InputThreadBuilding两个线程,使用最简单的synchronized进行同步。
调度器
  • 第一次作业独立出了调度器,采用Look策略,通过共享elevatorqueue实例与线程交互。
架构


Bug
  • 错误理解开关门时间导致TLE:修改时间

  • 输出线程安全问题:添加同步锁

感想
  • 第一次作业较为简单,旨在了解多线程的实现,并无复杂的线程安全问题。也得益于此我重点关注了程序架构的设计,为之后的扩展打下了基础。

第二次作业

同步
  • 请求队列的同步方式与第一次相同,第二次增加了电梯信息类ElevatorList共享给电梯ELevator与输入线程InputThread,同样采用synchronized进行同步。
调度器
  • 本次作业为简化数据传输将调度器整合到了电梯类中,采用随机分配的方式
    • 横向调度器:采用ALS策略
    • 纵向调度器:整体采用ALS策略,查找总路程最近的楼层中转
架构

Bug
  • 采用先下后上运算,但输出时先上后下导致超载:输出改为先下后上
  • 遍历时修改对象:采用深克隆遍历新对象
感想
  • 单例模式能十分简便地跨层次传输信息,但实际忽略了信息传输的逻辑造成结构的混乱。本单元的测试难度真的大大提高,除了较长的运行时间外,复现一个bug更要跑无数遍。同时线程安全的问题更是不好定位,感觉只能通过逻辑分析的方式,在设计时就应该做好时序分析。

第三次作业

同步
  • 同第二次作业
调度器
  • 同第二次作业
架构

Bug
  • InputThread依据当时电梯信息将请求分配至相应楼座,但电梯处理请求时电梯信息有变,导致乘客一致停留在电梯:进电梯时增加判断
  • 线程安全结束问题:增加InputQueue判断所有请求被处理
感想
  • 掩码通过每一位存储信息,有很高的效率。无脑同步会浪费大量时间,选择性同步又会存在不易察觉的线程安全问题。设计时还是应明确基础的消费者生产者模式,全面考虑所有时序关系。
posted @ 2022-05-04 12:47  后玉洲  阅读(16)  评论(0编辑  收藏  举报