超市排隊隨想錄
阿新 • • 發佈：2019-01-03
昨天陽光城一新超市開張，去超市晃了一圈，人山人海啊！突然感覺這撫州的消費能力不是一般的強。今天討論一個問題：佇列，資源競爭和鎖。
“稱重處”一定是最繁忙的，因為“資源獨佔”，如果寫程式碼的時候這個地方是要加鎖的，不然一定會出現多執行緒下的併發問題。所以我一直觀察這“壯烈”的場景。很多人是沒有排隊的，直接擁堵在周圍，這裡我稱之為“搶佔式資源競爭”。計算機內部對於任務的排程並非採用這種方式，原因很簡單，會導致使用者響應不及時這樣不太好的使用者體驗。簡單的說一下為什麼，以“稱重處”這個場景為例，可能某個人搶了很久，但是他仍然沒有搶到“秤”這樣一個資源，所以他一直要等待，假設有另外一個人要等他稱重完，那麼對於等他的這個人而言體驗是很不好的。即使從資源公平來講也是不合理的。這裡基本上誰更蠻橫誰力氣大則更有機會搶到“秤”。所以一定會出現“排隊”的必要性。
排隊的好處不言而喻，計算機裡面所說的“FIFO（先進先出）”。這樣儘量的保證了資源競爭的公平性。程式設計師也很多的會出現排隊的場景。很多情況下會有“Queue(佇列)”的應用。這裡再說一下CPU的時間片分配。如果知道作業系統的都知道對於CPU而言是並非嚴格的按照排隊的順序進行處理。這裡也是為了解決一個問題。比如說一個任務執行時間是半個小時，如果嚴格按照排隊的方式則我執行下一個程式則需要在半個小時後（PS：另外還有一個原因，因為本身一個程式的執行並非都是CPU獨佔的，有可能等待IO，請求網路等其他資源）。對於多工場景下肯定是不適合的。所以計算機會引入“時間片”的概念。這裡其實最關鍵的是進行“
第一種策略是小A和小B進行“搶佔”。這樣小A和小B完成的時間是不可控的。比如說稱一袋商品的時間是20ms。在最優的情況下，小A完成的時間200ms。小B是100ms。當然最差的情況下小A是300ms。小B也是300ms。從演算法的角度來講可以說這個時間複雜度是不穩定的。下面的圖是一個簡化版，只要小A或者小B只要搶到秤就可以把所有的東西稱完。
下面是任務A最優的情況
下面是任務B最優的情況
第二種策略就是簡單的排隊，比如說小A排前面，那麼小A稱完10袋商品花了200ms。那麼再稱小B的商品。這樣稱完小B是100ms，但是小B總的時間是多少？300ms(等待時間200ms)。其實就是上圖中任務A最優的情況。
下面就把這個場景進行復雜化。 這裡增加一個打包處(打包處是可以並行的，小A和小B打包互不干擾)，每打包一份商品消耗20ms，這裡假設小A在打包的同時是無法把商品放到稱重處進行稱重的（現實場景中人有兩隻手，本身會有一個並行的工作，所以即使任務內部也可以進行並行，這裡為了把問題簡化，就不做這種處理）。那麼按照剛才排隊的策略很顯然，小A工作完是需要400ms。小B工作完是600ms。“稱重處”總的算起來是工作了580ms。
這張圖簡單的描述了小A在稱重和打包的同時間時間消耗，這裡可以很清楚的看到稱重處是有大量時間空閒的，B的工作佇列就不在此畫出來了。
上面那種策略有什麼問題？就是在小A或者小B打包的同時稱重處是空閒的，總的算起來其實空閒了280ms。這裡小A打包的同時，稱重處可以為小B進行稱重，這樣下來小A和小B工作完是400ms和220ms。但是最後稱重處並非工作了580ms。而是380ms，節約了200ms的時間。當然這裡跟CPU的時間片有關係嗎？已經有些接近了。CPU為了簡化一些處理，比如說CPU把時間切分成一個一個小片然後分配給任務。假設在這裡一個時間片為20ms是最優的。當然CPU的工作遠沒有這麼簡單，由於任務切換也同樣是需要時間的，這裡所描述的場景並沒有體現這樣點。
下面這張圖中很清楚的看到稱重處消耗的時間是380ms。時間利用率有比較大的提升，小A任務完成總共是400ms。小B任務完成只需要220ms。
這裡要講的其實是生活各處都會有各種策略運用於計算機的設計中。有些人說藝術來源於生活，計算機也是如此。上次在某篇文章中談到“影象記憶”。比如說我到過某個地方，其實在腦海裡會有一個快照（snapshot），這樣就記下來了。當然計算機怎麼做這個事情，呵呵，就複雜了，目前來講其實是記住“特徵值”，簡單點講比如說這裡有個星巴克，有多少樓，什麼顏色，朝向等一些重要特徵然後進行比對。當然人其實也是這樣的。真正把所有的資訊記下來是不可能的。
“稱重處”一定是最繁忙的，因為“資源獨佔”，如果寫程式碼的時候這個地方是要加鎖的，不然一定會出現多執行緒下的併發問題。所以我一直觀察這“壯烈”的場景。很多人是沒有排隊的，直接擁堵在周圍，這裡我稱之為“搶佔式資源競爭”。計算機內部對於任務的排程並非採用這種方式，原因很簡單，會導致使用者響應不及時這樣不太好的使用者體驗。簡單的說一下為什麼，以“稱重處”這個場景為例，可能某個人搶了很久，但是他仍然沒有搶到“秤”這樣一個資源，所以他一直要等待，假設有另外一個人要等他稱重完，那麼對於等他的這個人而言體驗是很不好的。即使從資源公平來講也是不合理的。這裡基本上誰更蠻橫誰力氣大則更有機會搶到“秤”。所以一定會出現“排隊”的必要性。
排隊的好處不言而喻，計算機裡面所說的“FIFO（先進先出）”。這樣儘量的保證了資源競爭的公平性。程式設計師也很多的會出現排隊的場景。很多情況下會有“Queue(佇列)”的應用。這裡再說一下CPU的時間片分配。如果知道作業系統的都知道對於CPU而言是並非嚴格的按照排隊的順序進行處理。這裡也是為了解決一個問題。比如說一個任務執行時間是半個小時，如果嚴格按照排隊的方式則我執行下一個程式則需要在半個小時後（PS：另外還有一個原因，因為本身一個程式的執行並非都是CPU獨佔的，有可能等待IO，請求網路等其他資源）。對於多工場景下肯定是不適合的。所以計算機會引入“時間片”的概念。這裡其實最關鍵的是進行“
第一種策略是小A和小B進行“搶佔”。這樣小A和小B完成的時間是不可控的。比如說稱一袋商品的時間是20ms。在最優的情況下，小A完成的時間200ms。小B是100ms。當然最差的情況下小A是300ms。小B也是300ms。從演算法的角度來講可以說這個時間複雜度是不穩定的。下面的圖是一個簡化版，只要小A或者小B只要搶到秤就可以把所有的東西稱完。
下面是任務A最優的情況
下面是任務B最優的情況
第二種策略就是簡單的排隊，比如說小A排前面，那麼小A稱完10袋商品花了200ms。那麼再稱小B的商品。這樣稱完小B是100ms，但是小B總的時間是多少？300ms(等待時間200ms)。其實就是上圖中任務A最優的情況。
下面就把這個場景進行復雜化。 這裡增加一個打包處(打包處是可以並行的，小A和小B打包互不干擾)，每打包一份商品消耗20ms，這裡假設小A在打包的同時是無法把商品放到稱重處進行稱重的（現實場景中人有兩隻手，本身會有一個並行的工作，所以即使任務內部也可以進行並行，這裡為了把問題簡化，就不做這種處理）。那麼按照剛才排隊的策略很顯然，小A工作完是需要400ms。小B工作完是600ms。“稱重處”總的算起來是工作了580ms。
這張圖簡單的描述了小A在稱重和打包的同時間時間消耗，這裡可以很清楚的看到稱重處是有大量時間空閒的，B的工作佇列就不在此畫出來了。
上面那種策略有什麼問題？就是在小A或者小B打包的同時稱重處是空閒的，總的算起來其實空閒了280ms。這裡小A打包的同時，稱重處可以為小B進行稱重，這樣下來小A和小B工作完是400ms和220ms。但是最後稱重處並非工作了580ms。而是380ms，節約了200ms的時間。當然這裡跟CPU的時間片有關係嗎？已經有些接近了。CPU為了簡化一些處理，比如說CPU把時間切分成一個一個小片然後分配給任務。假設在這裡一個時間片為20ms是最優的。當然CPU的工作遠沒有這麼簡單，由於任務切換也同樣是需要時間的，這裡所描述的場景並沒有體現這樣點。
下面這張圖中很清楚的看到稱重處消耗的時間是380ms。時間利用率有比較大的提升，小A任務完成總共是400ms。小B任務完成只需要220ms。
這裡要講的其實是生活各處都會有各種策略運用於計算機的設計中。有些人說藝術來源於生活，計算機也是如此。上次在某篇文章中談到“影象記憶”。比如說我到過某個地方，其實在腦海裡會有一個快照（snapshot），這樣就記下來了。當然計算機怎麼做這個事情，呵呵，就複雜了，目前來講其實是記住“特徵值”，簡單點講比如說這裡有個星巴克，有多少樓，什麼顏色，朝向等一些重要特徵然後進行比對。當然人其實也是這樣的。真正把所有的資訊記下來是不可能的。