Goroutines 在通道上阻塞的順序是否決定了它們將解除阻塞的順序？我不關心發(fā)送的消息的順序（它們保證是有序的），而是將解除阻塞的 Goroutine 的順序。想象一個ch在多個 Goroutines（1、2 和 3）之間共享的空 Channel ，每個 Goroutine 都試圖在 上接收消息ch。由于ch為空，每個 Goroutine 都會阻塞。當我向 發(fā)送消息時ch，Goroutine 1 會先解除阻塞嗎？或者 2 或 3 人可能會收到第一條消息？（反之亦然，Goroutines 嘗試發(fā)送）我有一個操場似乎表明 Goroutines 阻塞的順序就是它們被解除阻塞的順序，但我不確定這是否是由于實現(xiàn)而導致的未定義行為。
3 回答
三國紛爭
TA貢獻1804條經(jīng)驗 獲得超7個贊
這是一個很好的問題 - 它涉及進行并發(fā)設計時的一些重要問題。如前所述，根據(jù)當前的實現(xiàn)，您的具體問題的答案是基于 FIFO。它不太可能有所不同，除非實施者出于某種原因認為 LIFO 更好。
有沒有保證，雖然。因此，您應該避免創(chuàng)建依賴于特定實現(xiàn)的代碼。
更廣泛的問題涉及非確定性、公平和饑餓。
也許令人驚訝的是，基于 CSP 的系統(tǒng)中的非確定性并非來自并行發(fā)生的事情。有可能是因為并發(fā)，但不是因為并發(fā)。相反，當做出選擇時會出現(xiàn)不確定性。在 CSP 的正式代數(shù)中，這是用數(shù)學建模的。幸運的是，您無需了解數(shù)學即可使用 Go。但形式上，兩個 goroutine 代碼并行執(zhí)行，如果消除所有選擇，結(jié)果仍然是確定性的。
Go 允許select通過 goroutine 之間共享的通道的末端顯式和隱式引入非確定性的選擇。如果你有點對點（一個讀者，一個作者）的渠道，就不會出現(xiàn)第二種。因此，如果它在特定情況下很重要，則您可以做出設計選擇。
公平和饑餓通常是同一枚硬幣的兩面。饑餓是那些可能導致性能不佳，更可能導致錯誤行為的動態(tài)問題之一（以及死鎖、活鎖和競爭條件）。這些動態(tài)問題是不可測試的（更多關于這個），需要一些層次分析來解決。顯然，如果系統(tǒng)的一部分因為無法訪問某些資源而沒有響應，那么在管理這些資源時就需要更加公平。
由于當前的 FIFO 行為，對通道端的共享訪問可以很好地提供一定程度的公平性，這似乎就足夠了。但是，如果您希望它得到保證（無論實現(xiàn)的不確定性如何），則可以select在數(shù)組中使用 a和一組點對點通道。通過始終按照將最后選擇的放在堆底部的順序優(yōu)先選擇它們，很容易實現(xiàn)公平索引。此解決方案可以保證公平性，但可能會帶來很小的性能損失。
（旁白：請參閱“Wot No Chickens”，了解英國坎特伯雷的研究人員關于 Java 虛擬機中的公平性缺陷的一個有點有趣的發(fā)現(xiàn)——該缺陷從未得到糾正！）
大話西游666
TA貢獻1817條經(jīng)驗 獲得超14個贊
順序未指定，但當前的實現(xiàn)使用 FIFO 隊列來等待 goroutine。
權(quán)威文檔是Go Memory Model。內(nèi)存模型沒有為發(fā)送到同一個通道的兩個 goroutine 定義發(fā)生在之前的關系，因此沒有指定順序。同上接收。
- 3 回答
- 0 關注
- 232 瀏覽
添加回答
舉報
0/150
提交
取消