OO第二单元总结
1.第五次作业
-
1.1同步块的设置和锁的选择
本单元的作业中,我选择对
Dispathcer
对象上锁,本质上是对request
属性上锁InputHandler
线程中有对request
的写操作Elevator
线程中有对request
的读和取操作针对这些读、写、取操作,需要对
Dispatcher
对象上锁 -
1.2调度器设计
-
我的调度器中起主要作用的,是内部的总请求池
request
和输入是否结束信号end
-
电梯的
hasIn()
通过对Dispatcher
中request
的读判断是否有乘客上电梯 -
电梯的
goIn()
通过对Dispatcher
中request
的取实现乘客上电梯 -
电梯的
changeState()
通过对Dispatcher
中request
的读实现电梯状态变化
-
-
1.3UML类图
-
-
我的理解:尽可能让电梯少变换方向 适用于Random和Night的策略,Morning需要略作调整
-
空载:
-
若存在((from-floor)*state>0)的同方向请求,电梯方向不变,主请求为距离当前楼层最远(abs(from-floor)最大值)的同方向请求;
-
若不存在,说明电梯此时需要换方向;
-
寻找主请求的过程中,允许电梯捎带同方向请求,即(state*(to-from)> 0)
-
-
电梯内有乘客:
-
所有请求的运行方向(to-from的正负表示)一定相同,也是电梯的方向;
-
-
-
-
2.第六次作业
-
2.1同步块的设置和锁的选择
本单元的作业中,我选择对
Dispathcer
对象上锁,本质上是对request
属性上锁InputHandler
线程中有对request
的写操作Elevator
线程中有对request
的读和取操作针对这些读、写、取操作,需要对
Dispatcher
对象上锁 -
2.2调度器设计
-
我的调度器中起主要作用的,是内部的总请求池
request
和输入是否结束信号end
-
电梯的
hasIn()
通过对Dispatcher
中request
的读判断是否有乘客上电梯 -
电梯的
goIn()
通过对Dispatcher
中request
的取实现乘客上电梯 -
电梯的
changeState()
通过对Dispatcher
中request
-
-
-
-
-
-
声明:不符合实际,是对电梯资源的浪费
-
多部电梯竞争最近的请求
-
空载:
-
所有电梯主请求是所有指令中from楼层离当前楼层最近的请求(abs(from - floor)最小值)
-
-
电梯内有乘客:
-
所有请求的运行方向(to-from的正负表示)一定相同,也是电梯的方向
-
-
-
-
-
3.第七次作业
-
3.1同步块的设置和锁的选择
-
在前两次作业对
Dispathcer
对象上锁基础上,对Controller
对象中上锁
-
-
3.2UML类图
-
3.3调度算法——换乘=分配+竞争
-
-
先分配:C与A/B之间没有竞争关系
-
根据换乘情况列表,将需要换乘的指令拆分
-
将拆分后的指令分为两部分,与无需换乘的指令一起,根据换乘情况列表,加入C的请求池或者A/B请求池
-
-
后竞争:种内竞争
-
种内:
-
A/B在公共楼层可以看做同种类电梯
-
同种类电梯之间存在种内竞争
-
-
竞争:在满足自身楼层限制的基础上进行与HW6完全相同的竞争
-
换乘点计算
-
换乘点计算:不换乘的最优情况用时仍大于等于换乘的最坏情况
-
A换乘点的计算:
-
(18 - A) * 0.4 >= (A - 3) * 0.6 + 0.4 + 15 * 0.2
-
不换乘的最优情况:直接乘坐B电梯从B至3楼;
-
换乘的最坏情况:乘坐A电梯至3楼后,乘坐C至18楼
-
解得 A <= 5.6 由此确定第一个换乘临界值A = 5
-
-
B换乘点的计算:
-
(B - 3) * 0.4 >= (18 - B) * 0.6 + 0.4 + 15 * 0.2
-
-
-
-
-
Sequence Diagram
InputHandler
Elevator