OO第二单元博客作业

yplqing 学生 2024-04-19 20:42:34

hw5

电梯运行策略（LOOK策略）

尝试放客

确定主方向

判断是否需要停止

尝试接客

关门

移动

确定主方向

若到了两端，直接设定主方向；

若有内部请求，则主方向不需更新，跳到下一步接客；

（以下没有内部请求）

否则，若没有能接的外部请求，若没有结束就wait()，否则false；// 实现：遍历，用flag记录是下面的ABC哪种情况

（以下有外部请求）

否则，若有来自主方向、不来自本层的外部请求，则不变主方向；// A

（以下外部请求【来自主方向但来自本层或来自反方向】）

否则，若来自本层的外部请求的方向去往主方向，则不变主方向；// B

（以下全是来自反方向的外部请求）

否则，转向 // C

正优化

1.开门与关门之间间隔的时间应接尽接——实现：在关门前查询一次即可

对应的样例

[0.0]1-FROM-1-TO-2-BY-1
[0.4]2-FROM-1-TO-2-BY-1

2.（量子电梯）关门后与到达下一层之间间隔中，若有人则“回来”，重复步骤1——实现：在到达前查询一遍，重复步骤1即可

关键代码：

requestPool.wait(tmp);

对应样例

[0.0]1-FROM-1-TO-2-BY-1
[0.5]2-FROM-1-TO-2-BY-1
[0.8]3-FROM-1-TO-2-BY-1

hw6

电梯运行策略（加粗为新增）

尝试放客

检查是否需要重置

检查是否需要计算

尝试接客

确定主方向

检查——需要重置或计算就 continue

判断是否需要停止

检查——需要重置或计算就 continue

尝试接客

检查——需要重置或计算就 continue

关门

检查——需要重置或计算就 continue

移动

说明

此次作业新增 receive 输出要求，需要调度策略，我采用了影子电梯的方法。上述的“计算”指电梯检查到“需要计算的请求”不为空时，立刻调用cal()函数，计算出此电梯完成所有分配给它的请求的时间，然后通知控制器，接着进入等待，等待控制器接收到这个算出来的时间后通知自己。由上述电梯运行策略可知，电梯的某些操作似乎是“原子性”的，不能进入计算状态，导致控制器等待，我的解决方法是在某些必要操作中嵌入“是否需要计算”的判断，导致函数冗长。更好的解决方法是改写成状态机实现。

对reset的处理

请求池中新增cnt变量记录包括reset请求的数量，cnt为0才通知电梯线程停止。

reset前被迫出电梯的人变成新请求，为了防止互锁问题，使用新线程加入请求。

由于在reset过程中需要计算影子耗时，需提前将“上次到达时间”置为重置结束时间

对新请求的调度

将此请求的 usedForCal 变量置为真，表示此请求是出于计算目的临时进入请求池中；依次将各电梯“计算状态位”置为真，进入等待，等待电梯通知；比较时间，得出 bestId ，将此请求的 id 置为 bestId，usedForCal 变量置为假，唤醒所有电梯。

电梯及时反应控制器的措施

为了及时计算出耗时，电梯在关门、量子移动、重置过程中都要保持对锁的监视，以便于通信，所以我采用了将某个对象作为锁 + 标志位的方法。

比如在reset的1.2s中，双重判定——等待前判定、拿到锁后再判定一次

while ((tmp = gapForReset()) > 0) {
        cal();
        synchronized (Lock.getLockForNewRequest(id)) { // 锁
            try {
                if (needToCal) { continue; } // 标志位
                Lock.getLockForNewRequest(id).wait(tmp);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
}

这个方法其实有明显问题，因为还是会造成线程唤不醒的情况，但概率很低

hw7

双轿厢电梯的影响

电梯的“分裂”

我的处理方法是直接开12个电梯线程，id分别为1~12，1~6 对应 1-A、2-A、……、6-A，7-12 对应 1-B、2-B、……、6-B，初始化时，所有A电梯的楼层为0，B电梯的楼层为1，换乘楼层都为1，也就是一开始都是B电梯在工作。

另外，对于A的启动，我选择在B进行双轿厢电梯重置时启动A，具体来说B存着A的指针，直接更改A的楼层和换乘楼层即可。

由于A和B不能同时在换乘楼层，A中也要有B的指针，便于它们互相获取对方的当前楼层。我选择了双向通信处理

新请求的调度

为减少工作量，不考虑不同id电梯间的合作；

具体过程如下：

遍历电梯id(1~6)，若上方的B或者下方的A能单独完成，就返回B或A的时间；

否则，如果从下到上，计算A类完成将此请求放入换乘楼层和其他任务的总时间 t1、将此请求放入换乘楼层的时间 t2 （两个时间）；另外计算B正常移动到达换乘楼层并接走此请求的时间 t4 ，和完成包括这个请求的所有任务的时间 t3——t2小于t4说明B能顺便接走请求，两者互不影响，返回 t1和 t3 的较大值；否则，返回 t1 和 (t3 + t2 - t4) 的最大值；

如果从上到下，计算B类完成将此请求放入换乘楼层和其他任务的总时间 t1、将此请求放入换乘楼层的时间 t2 （两个时间）；另外计算A正常移动到达换乘楼层并接走此请求的时间 t4 ，和完成包括这个请求的所有任务的时间 t3——t2小于t4说明A能顺便接走请求，两者互不影响，返回 t1和 t3 的较大值；否则，返回 t1 和 (t3 + t2 - t4) 的最大值；

根据时间选出bestId即可