0

所以我遇到了一個競爭條件,我有幾個解決方案來解決這個問題。我很清楚線程是新手,我的意見和研究是有限的。如果用戶從服務器接收到某些消息,可能會發生大量的異步調用。因此,由於我的物體的依賴性,我的設計很差。同步依賴的異步函數目標C

可以說我有一個名爲

adduser:(NSString s){ 
does some asynchronize activity 
} 
Messageuser:(NSString s) 
{ 
Does some more asychronize activity 
} 

功能,如果用戶要收到一條消息,告訴它要ADDUSER「瑞恩」。他會創建一個線程並繼續查找Ryan並存儲他。但是,如果用戶使應用程序處於掛起模式,並且在等待接收的消息緩衝中存在addUser請求和MessageUser請求,則會出現競爭條件,因爲完成Adduser所需的時間比完成MessageUser所需的時間更長。因此,如果調用messageUser,並且(在我們的示例中)「Ryan」尚未完全添加,則會引發錯誤。

這個問題有什麼可能的解決方案。我研究了鎖和信號燈,我試圖做的是,當MessageUser接收到一個調用時,檢查以確保當前沒有線程正在執行addUser。如果沒有,繼續。否則等待,而不是在完成後繼續。

回答

1

那麼這取決於郵件是如何發佈的,以及異步響應事件是什麼。

如果操作具有依賴關係(排序要求),那麼也許背景串行隊列將是適當的?這是確保按順序處理消息的一種簡單方法。

如果異步操作執行完成塊,則可以讓完成塊發出請求執行下一個操作,儘管您可能不會提前知道該操作。

如果您需要以更一般的方式解決此問題,則需要某種系統來跟蹤先決條件,以便跳過尚未滿足其先決條件的工作項目。這可能意味着您自己的後臺線程監視等待任務列表並接收所有任務完成通知,以便它可以掃描等待完成併發出它們的項目。

雖然看起來確實很複雜......我懷疑你並沒有真正具備如此強大的異步並行處理要求,而更簡單的設計也同樣有效。考慮到您從服務器接收消息的情況,我認爲串行隊列將是最佳選擇。然後,您可以按照服務器發送它們的順序處理消息,並使事情變得簡單。

//do this once at app startup 
dispatch_queue_t queue = dispatch_queue_create("com.example.myapp", NULL); 

//handle server responses 
dispatch_async(queue, ^{ 
    //handle server message here, one at a time 
}); 

在現實中,這取決於你如何連接到你的服務器,你可能能夠只通過郵件從UI派遣移動整個連接的處理交給後臺排隊和交流有了它,並更新UI將作爲UI線程的dispatch_get_main_queue()。