OO第二次博客作业——多线程电梯

一、基于度量的作业分析

　　h1可以说是一个非常傻瓜的多线程电梯，原理非常简单直接粗暴

　　实际运用可能会被客户投诉（是一定）

 

　　在第二次作业中，我采用了一种非常复杂的写法

 

　　可以看到复杂度最高的地方集中在电梯的运行函数和调度函数中，但其实这种复杂性对于电梯的运行并没有任何的帮助，只是由于对于多线程知识的一知半解和架构设计不清晰而形成的这种结构

 

　　相较于第二次作业来说，电梯的设计有了一定的改进，将一些不必要单列的线程和功能进行了抽象化和集中

　　但是电梯的复杂度还是比较高的，尽管指导书要求我们写的应该是一个有着实际运用价值的电梯，但是我的电梯的目的只是为了过中测性能和调度算法还是比较差的

 

　　二、设计策略

 

在前两次的电梯作业中，我对于多线程的了解都只是错误或者不全面的

重点叙述一下第三次电梯作业的设计策略

首先，电梯问题是一个很经典的“生产者——消费者模型”

生产者——需求

在这里需求分为两类

1.能直达

2.不能直达（从起点到换乘楼层，从换乘楼层到达目的楼层），相当于两个需求，但是这两个需求是有时间的先后顺序的

消费者——电梯

由于三部电梯拥有不同的到达楼层，乘客可能有换乘的情况发生，所以在需求产生的时候，我就将这个乘客是否需要换乘，在那层楼换乘进行了一个判断

对于每个电梯，都有一个运行序列，主需求序列通过调度器将各个乘客分配到三部电梯的运行序列中

调度器的运行是在电梯上下楼之间的时间完成的，也就是说，没上升或者下降一层楼，都会对电梯进行一次调度，同时根据电梯的运行状态（上行或者下行，是否满载），来进行乘客的进出

 

 

三、发现的bug以及处理

1. 电梯不能读入请求

　　这里的问题主要是线程安全导致的，对于让电梯和调度器wait和唤醒时的设置有问题

        2.超载

　　最开始没有设计电梯容量，在电梯的运行函数中修改

　　3.电梯疯狂向一个方向跑

　　对于判断电梯运行状态的方法设计有问题，修改

　　4.需求不能执行完，执行几条之后就不执行了

　　这里是线程安全的问题，出现了部分死锁的情况

 

　　四、分析自己程序的bug和分析自己发现别人程序bug所采用的策略

　　bug还是挺多的，设计本身有问题。

　　主要出现在调度算法的漏洞，电梯仅依靠判断本电梯运行序列中乘客的情况判断是否上下人，然后有时候调度器错误的调度就导致电梯不能正确执行指令

　　关于debug的方法：

　　先设计好数据，然后黑盒测试，对于有问题的数据进行代码的调试和bug的定位

　　（这里感谢ffdl的定时投放数据脚本）

 

　　五、心得体会

首先，多线程是真的挺难的。

对于如何让自己的代码兼具高效和正确性对我来说还是一个比较大的挑战。

在学习多线程的过程中，我认为还是多和同学进行交流，这样就可以及时的将一些错误的理解避免，免除不必要的代码工作

更重要的一点是，一定要在认真阅读过指导书后在进行设计，然后再进行代码

不然就有可能整个程序架构崩盘（你问我怎么知道的？呵呵）