第五次作業：多線程電梯

多線程的協同和同步控制：

本次作業一共有以下幾個線程：讀入處理線程inputHandler，單個電梯運行線程elevatorRun*3，任務分派線程newNewDispatch。

inputHandler線程用來讀入並判斷是否合法，提取指令並將其放入總指令隊列。

每個elevatorRun線程負責調度一個電梯，有自己的一個指令隊列，操縱這臺電梯按照指令隊列的要求運行，有點類似上一次的dispatch。

newNewDispatch負責根據floor亮燈情況和每個電梯的狀態等從總指令隊列取出指令並放進每個電梯的指令隊列。

需要進行處理的是inputHandler與newNewDispatch共同操作中指令隊列；newNewDispatch和exevatorRun操作floor和elevator

對於前一個，簡單的鎖總指令隊列即可。

對於後一個，為了避免死鎖，我請求狀態時按照電梯順序分別鎖電梯123，其他情況下鎖需要使用的電梯。

度量分析

主要問題是在調度類中為了省事大量使用了重復的代碼。此外在使用前幾次的代碼時修補bug也增加了許多補丁式的代碼，增加了長度與復雜度。

BUG分析

我在電梯調度分配上出了些奇怪的問題，導致了有些情況下捎帶指令沒有被捎帶。

我拿到的那位是一個巨佬，洋洋灑灑寫了10個類，快2k行代碼，測了一下並沒有任何bug

第六次作業：IFTTT

多線程的協同和同步控制：

本次作業一共有以下幾個線程：讀入處理線程inputHandler，監控線程*n

這次的相對比較簡單，主要沖突在輸出問價上。對summary和detail輸出分別加鎖就好了。

度量分析

問題在於監控時把四種方法寫在一起用了一個而沒有分開。我使用了switch+一段代碼的模式，看上去也比較清晰，但是會導致代碼過長。

BUG分析

對方並沒有給我公測，根據我自己測試結果來看過公測沒有什麽問題，但是互測中應該是能發現一些小問題的。

我拿到的那一份寫的比較一般，基本隨手就能找到bug，公測掛了好幾個點。測完公測後簡單又測了一下，發現甚至不能定位錯誤原因，搞得我也不知道是不是有一個問題導致的錯誤，最後掛了一個點以後放棄了進一步測試。

第七次作業：出租車1

多線程的協同和同步控制：

本次作業一共有以下幾個線程：出租車線程*100，調度分配線程*運行的指令個數，讀入處理線程

產生沖突的主要是出租車選單，出租車當前狀態，任務派單時對出租車的訪問

度量分析

在處理接單等任務時處理邏輯還是有點復雜。本來寫的想法有漏洞，後來在修補時把那裏的代碼搞得很亂。

BUG分析

直接使用了助教提供的GUI中的bfs算法計算最短距離，現在發現提供的實現運算太慢了，單次誤差有幾十毫秒，一次性輸入幾百條時直接卡死了。下次作業時要把這段重寫了。

此外，接到乘客時忘記sleep了。

心得體會

寫代碼前要認真規劃，防止寫到一半發現問題再重新添加的情況。雖然修改代碼可以解決大部分的bug，可是這會導致自己的代碼越來越長，檢查時會十分不爽。

OO第二次博客作業