第一次作业
第一次作业要求六部电梯，支持处理从某层楼到某层楼的请求
整体架构如下：
Input读入任务后，将任务交给Dispatcher，Dispatcher内持有多个Scheduler，它来决定某个任务该分配给哪个Scheduler，Scheduler使用RequestTable来维护所有拿到的任务，操作电梯以某个策略完成这些任务
第二次作业
在原有设计的基础上增加了ADD-Elevator和MAINTAIN的操作，在MAINTAIN时会出现“请求回流”的现象：即某个乘客的请求已经到达某个电梯上，但是由于电梯即将进入维护状态，所以要将该乘客转移回Dispatcher，由Dispatcher进行请求的重新分配
在第二次作业中终止条件的判断变得复杂起来了，第一次作业Dispatcher的终止条件仅为Input线程读到了文件末尾，而现在即使Input线程读到文件末尾，也可能存在请求回流导致Dispatcher将继续担任分配任务的职责，所以考虑在Dispatcher内维护一个记录目前还有多少个任务的变量cnt，每新增一个任务就让cnt++，每完成一个任务就让cnt--，Dispatcher终止的条件即为Input读到文件末尾且cnt==0
第三次作业
电梯增加了可达性限制，导致某些乘客可能需要换乘，需要进行路径规划，在这一步中可以用bfs算法来找到换乘数量最少的一种乘梯方案，如果有多种换成数量最少的方案，设某方案的负载为该方案涉及的电梯的最大挂载任务量，那么我们选最小负载的一种方案
每一层增加了停靠电梯的数量的限制，可以用信号量来解决
整体架构如下：
时序图如下：
