2 回答

TA貢獻(xiàn)1827條經(jīng)驗(yàn) 獲得超8個(gè)贊
你為什么要這樣做?
死鎖問題是,如果您不允許安排其他goroutine,則除非有緩沖,否則您的頻道發(fā)送將無法進(jìn)行。Go的頻道具有有限的緩沖,因此您在耗盡狀態(tài)之前就陷入了競爭的局面,然后才被發(fā)送出去。您可以引入無限緩沖,也可以將每個(gè)發(fā)送放入自己的goroutine中,但是又可以歸結(jié)為:為什么要這樣做?您想達(dá)到什么目的?
另一件事:如果只希望確保* s之間的三組代碼互斥,那么可以使用互斥鎖。如果要確保沒有代碼中斷塊,無論塊在何處被掛起,則可能需要使用runtime.LockOSThread和runtime.UnlockOSThread。這些級別很低,您需要知道自己在做什么,而很少需要它們。希望沒有其他goroutine運(yùn)行,您必須要有runtime.GOMAXPROCS(1),這是當(dāng)前的默認(rèn)值。

TA貢獻(xiàn)2036條經(jīng)驗(yàn) 獲得超8個(gè)贊
回答您的問題的問題在于,似乎沒有人了解您的問題的實(shí)質(zhì)。我看到您反復(fù)詢問大致相同的內(nèi)容,盡管尚未取得任何進(jìn)展。這么說并沒有冒犯。這是通過建議以其他人可以理解的方式幫助您解決問題的嘗試。作為一個(gè)可能的好副作用,某些問題確實(shí)可以解決,同時(shí)可以用一種可以理解的方式向其他人解釋。我一個(gè)人經(jīng)歷了很多次。
另一個(gè)提示可能是顯式同步和頻道通信的可疑混合。這并不意味著設(shè)計(jì)必然壞了。它只是在典型/簡單的情況下不會發(fā)生。再一次,您的問題可能不典型/不平凡。
也許有可能僅使用渠道來重新設(shè)計(jì)您的問題。實(shí)際上,我相信可以在僅使用通道的情況下對涉及顯式同步(在Go中)的每個(gè)問題進(jìn)行編碼。也就是說,確實(shí)可以很容易地通過顯式同步編寫一些問題。同樣,信道通信雖然便宜,卻不如大多數(shù)同步原語便宜。但這可以在以后的代碼運(yùn)行時(shí)得到解決。如果有人說出“ pattern”說出了sync.Mutex將會出現(xiàn)在代碼中,那么應(yīng)該可以切換到它,并且當(dāng)代碼已經(jīng)可以工作時(shí)更容易做到這一點(diǎn),并希望在進(jìn)行調(diào)整的同時(shí)進(jìn)行測試以觀察您的步驟。
嘗試像獨(dú)立代理一樣思考您的goroutine,這些代理可以:
獨(dú)家擁有從通道接收的數(shù)據(jù)。語言不會強(qiáng)制執(zhí)行此操作,您必須部署自己的學(xué)科。
不要再觸摸他們已發(fā)送到頻道的數(shù)據(jù)。它遵循第一條規(guī)則,但足夠重要,必須明確。
通過數(shù)據(jù)類型與其他代理(goroutine)進(jìn)行交互,這些數(shù)據(jù)類型封裝了工作流/計(jì)算的整個(gè)單元。例如,這消除了您之前在“單元”完成之前獲得正確數(shù)量的通道消息的工作。
對于它們使用的每個(gè)通道,必須絕對清楚是否必須取消緩沖該通道,必須為固定數(shù)量的項(xiàng)目緩沖該通道或該通道可能未綁定。
如果代理需要自己的信息來完成自己的任務(wù),則不必考慮(了解)其他代理正在做什么,這是更廣闊的前景的一部分。
即使使用很少的經(jīng)驗(yàn)法則,也有望產(chǎn)生出更易于推理且通常不需要任何其他同步的代碼。(我現(xiàn)在有意忽略關(guān)鍵任務(wù)應(yīng)用程序的性能問題。)
- 2 回答
- 0 關(guān)注
- 210 瀏覽
添加回答
舉報(bào)