麵包師有很多麵包,由n個銷售人員推銷,每個顧客進店後取乙個號,並且等待叫號。當乙個銷售人員空閒下來時,就叫下乙個號。設計乙個銷售人員與顧客同步的演算法。
這一類題型代表性很強,比如銀行櫃檯,各種商店的服務等,都是一樣的模式。
演算法。分析:這裡有n個銷售人員可用,像是n個緩衝區一樣。每個顧客取號,等待的看似是號碼,實際是銷售。因此,這是簡化的生產者消費者問題,這裡沒有互斥問題,僅僅是同步。
以上是一種典型的錯誤分析的思路。
因為,即使只有乙個銷售,可以叫的號碼也可以有無數個,雖然會讓這乙個銷售累死。。。
因此,這個過程中,號碼是非常關鍵非常關鍵的東西。我們設計同步全是圍繞著數字而來。
而上面那種把數字等同於銷售的做法,簡直錯透了!
分析到這裡,我們明白不同的銷售之間其實是在搶數字的,雖然他們本身並不是這麼勤奮,看到號碼就想搶,給顧客推銷。但是實際運作的機制是這樣:對每乙個號碼,互斥訪問。
同理,在顧客這邊,也不能讓兩個顧客共用乙個號,因而對號碼也是互斥訪問的。
號碼在顧客這方是順序增長的。
想到在銀行排隊辦理業務,我突然明白以上的分析其實很多餘。。。
那麼,我們只需要設計兩個訊號量用於顧客這裡產生的叫號的互斥訪問和銷售端號碼的處理的互斥訪問。
int i = 0, j = 0; // i是當前取號值,j是當前叫號值
semaphore mutex_i = 1, mutex_j = 1;
consumer()//號碼遞增
seller() //從小號開始叫
else
}
這是乙個生活中非常常見的簡單的場景,寫到**裡來,也是很有趣,可見pv操作不僅是一種os的演算法,也是一種生活智慧型的體現。
以上除學科相關知識外都是胡扯。
SAP銷售發票同步產生會計憑證的兩種做法
問題背景及問題描述 sap是乙個高度整合的系統,在各個後勤模組中發生某些的業務,能夠在系統中自動產生會計憑證,同步更新財務會計科目餘額,開具銷售發票的同時產生會計憑證便是其中一種。具體來說,當銷售業務人員在sap系統開出銷售發票的同時,會同步產生會計憑證如下 借 應收賬款 貸 主營業務收入 貸 應交...
程序間同步臨界區的Peterson演算法
在所有專案中,進入和退出臨界區時都有輸出以表示已進入和退出臨界區。臨界區內的操作是將公共變數 icount 這個兩個執行緒的公共變數疊加到 50,000,000 然後輸出,以此證明執行緒成功進入臨界區,滿足互斥 因為倘若沒有實現互斥,兩線程間的干擾會導致資料一致性問題而使 icount 不能準確加到...
非阻塞的同步 無鎖(CAS演算法)
基於鎖的同步方式,是一阻塞的執行緒間同步方式,不同執行緒在鎖競爭時,總不能避免相互等待,為了避免這個問題,就提出了非阻塞同步的方式,最簡單的一種非阻塞同步實現就是threadlocal。另一種方式就是基於比較並交換 compare and swap cas演算法的無鎖併發控制方法。cas演算法的是有...