設計乙個系統，使其可以根據乘客的當前樓層和目的樓層，為乘客分配電梯資源並運送其至目的樓層。
根據需求，可以將整個系統分成三個部分：
顯然，這三個部分是有次序關係的：乘客輸入，處理輸入，將請求放入排程佇列，排程器從排程佇列中取出請求，根據各電梯狀態將請求分配給合適的電梯。
上述的過程可以看成是三組 producer-consumer 組：
輸入處理
阻塞式獲取輸入，直到檢測到 eof 或者輸入流關閉。處理後的請求儲存在 personrequest 類中。當獲取到合法請求，將請求存入排程佇列，喚醒排程器。
排程器從排程佇列中取出請求，根據電梯狀態來決定請求被分配至的電梯，對於需要換乘的請求，將後續請求也分配至同一電梯，待前置請求完成，重新對後續請求進行排程。這裡的電梯狀態包括但不止於電梯能夠停靠的樓層、電梯當前執行狀態、電梯當前的任務序列、電梯歷史執行狀態。前兩者對於排程起著決定性的作用，而後兩者主要是使得各電梯負載均衡。
電梯從任務序列中取出任務，前往指定樓層執行任務。若完成了某個需換乘請求的前置請求，將後續請求提交給排程器，使其被重新排程。
elevator
├── direction
├── dispatcher
├── dividetask
├── elevator
├── elevatorrequest
├── inputhandler
├── main
├── requestqueue
├── task
└── timer
顧名思義，用於處理乘客輸入的類。域中包含有乙個排程器（dispatcher 類例項）。
當獲取到合法輸入時，喚醒（notify）排程器，否則堵塞。
當輸入為 eof 或者流被關閉時，將排程器的狀態設定為停止狀態（false），並喚醒（notify）排程器。
dispatcher
排程器類。域中包含有
當排程隊列為空，進入等待狀態（wait）。
被喚醒後，從排程佇列中依次取出所有請求並進行分配。全部取出後，若狀態為執行狀態（true），重新進入等待狀態（wait）；否則，將所有電梯的狀態設定為停滯狀態（false），並依次喚醒，最後結束排程器執行緒，但是保留排程器例項。
elevator
電梯類。域中包含有
電梯執行總體採用 look 演算法：在不轉向的前提下先執行完畢乙個方向的任務，然後切換為另乙個方向的任務序列，繼續執行。執行過程中的等待過程都通過 timer 類來實現。
task
任務類。單純的資料聚合。域中包含有
elevatorrequest
電梯任務類。域中包含有
當電梯接收到請求，會將請求存入 elevatorrequest 中。首先進行方向的判斷，並將其拆分為兩個任務：乙個 in，乙個 out。然後判斷加入主任務序列或是加入副任務序列：若與電梯的任務方向相反，或者可以捎帶，則加入主任務序列，否則加入副任務序列。
當主任務序列為空，電梯轉向時，進行 fresh 操作，將主任務序列與副任務序列互換。
dividerequest
待排程請求類。單純的資料聚合。域中包含有
如下，與上述的設計描述大致相同。
使用 complexity mertics 生成。
總體而言，複雜度尚可，複雜度較高的幾個 method 都是與設計緊密相關的，沒有修改或者拆分的必要。
在第二次電梯作業中，由於電梯的上下極限從 1-15 變為-3-20，而我在第一次作業中空任務的標誌 magic number 設定為了 0 忘記修改，導致第二次作業出現了問題。由此可以看出測試的重要性，因而第三次作業我專門寫了乙個評測機放在伺服器上進行長時間測試。
在多執行緒程式設計中，要特別關注暴露在多個執行緒之外的***，嚴格控制進入臨界區的執行緒數量。
電梯排程演算法
在高峰時間，實習生小飛常常會被電梯每層樓都停弄得很不耐煩，於是他想出了這樣乙個辦法 由於樓層並不高，那麼在繁忙的時間，每次電梯從一層往上走時，我們只允許電梯停在其中的某一層。所有乘客都從一樓上電梯，到達某層樓後，電梯聽下來，所有乘客再從這裡爬樓梯到自己的目的層。在一樓時，每個乘客選擇自己的目的層，電...
電梯排程演算法（ ）
今天我們做的是乙個結對程式設計作業，其實對結對程式設計，我也有兩種看法，第一 提高自己，第二 埋沒自己。關鍵看是如何去利用結對程式設計，才能達到事半功倍的效果。這次我們做的是乙個關於電梯控制排程的程式，這個程式的演算法思想做了一天，初步有了電梯排程演算法的框架。由於電腦換了，拿到聯想服務站維修，只在...
電梯排程 初
一。活動目的 避免公交車式的等待時間了，節省使用者的時間 到達目的地 使使用者的平均總旅行時間最短。二 概述問題 石家莊鐵道大學基礎教學樓的電梯配置如下 大廈有1 層，4部電梯，很多乘客使用這些電梯的日常 旅客重量 平均70公斤最大120公斤，最小45公斤 其他常量資料 電梯速度，開 關門時間，乘客...