NSOperationQueues中的信號量

我在Swift/NSOperationQueue基礎設計中第一次使用Swing，並且試圖找出如何保持隊列之間的數據完整性。NSOperationQueues中的信號量

我在設計過程中很早，但架構可能會涉及一個隊列（稱爲sensorQ），處理來自各種傳感器的傳感器測量流，這些傳感器將饋送融合模型。傳感器數據將以各種速率出現，一些速度相當快（例如，加速度計數據），但有些則需要擴展計算，可能需要一秒或更多時間。

我想弄清楚的是如何將當前狀態捕獲到UI中。 UI必須由主隊列處理（稱爲mainQ），但會反映融合引擎的當前狀態。

我不想在傳感器隊列上發生的每次更新都敲擊UI線程，因爲它們可能會頻繁發生，所以NSOperationQueue.mainQueue.addOperationWithBlock()調用傳遞狀態返回UI似乎不可行。同樣的道理，我不想發送查詢到傳感器隊列，因爲如果它正在處理一個長時間的計算，我會阻止等待它。

我正在考慮設置一個NSTimer，可以每十分之一秒左右將狀態複製到UI中。

爲此，我需要確保傳感器隊列上的狀態沒有被更新，同時我將它拷貝到UI隊列中。看起來像是一個信號量的工作，但我並沒有提到與NSOperationQueues有關的信號量。

我在Grand Central Dispatch中找到對dispatch_semaphore_t對象的引用。

所以我的問題是基本上，處理這些情況的推薦方式是什麼？除非您需要優化較低級別（如GCD），否則我會看到反覆告誡在最高級別的抽象級別（NSOperationQueue）工作。這是我需要優化的情況嗎？ dispatch_semiphore_t可以使用NSOperationQueue嗎？在這裏，我忽略了一個基於NSOperationQueue的方法嗎？

來源

2016-05-05 Omegaman

你可能想看https://developer.apple.com/videos/play/wwdc2015/226/的想法，也有一些基於這個談話的庫。 –

這裏你可能不需要信號量。您可以嘗試將UI刷新操作添加爲長時間運行的依賴項，AFAIK依賴項可以是交叉隊列，也可以作爲依賴項。每10次快速刷新一次。同時儘量避免定時器，它們可能會對電池壽命產生非常負面的影響。 –

設置不會違反MVC體系結構的依賴關係的最佳方式是什麼？傳感器數據直接傳送給爲模型提供信息的sensorQ。 UI不應該從模型中提取數據，而不是讓模型知道視圖控制器？也許通知是要走的路？（我還在看那個視頻 - 感謝指針）。 – Omegaman

您發送給用戶界面的數據量是多少？幾個數字？一個複雜的圖形？

如果您正在處理NSOperationQueue上的所有傳感器數據（我們稱其爲sensorQ），爲什麼不使隊列連續？然後，當您的計時器觸發時，您可以發送一個「更新UI」任務給sensorQ。當更新任務到達sensorQ時，您知道沒有其他傳感器正在修改狀態。您可以打包數據併發布到主（UI）隊列中。如果我們知道： 1.您的傳感器是否具有最小和最大數據速率？ 2.有多少傳感器對您的融合模型有貢獻？ 3.你如何同步從傳感器到融合模型的訪問？ 4.有多少數據以及什麼格式是UI的「更新」？

我的預感是，信號量不是必需的。

來源

2016-05-05 04:41:41 Curmudgeonlybumbly

避免信號量與NSOperationQueues的首選習慣用法？傳感器補碼還沒有完全確定，但上面提到的極限值應該是100-200Hz的加速度計數據，而圖像數據可能需要一秒鐘才能處理。後者反對將UI請求放入sensorQ中。 sensorQ將是串行的，確保傳感器更新是FIFO。到用戶界面的數據將是一組生產中的數字，但對於診斷可能還要多一點（不太重要）。圖形化可以通過在UI控制器中保留時間序列來完成。 – Omegaman

可能在這裏工作的一種方法是通過環形緩衝區將傳感器數據隊列與UI活動分離。這有效地消除了信號量的需要。

這個想法是，傳感器數據處理組件將數據推入環形緩衝區，UI組件從環形緩衝區中提取數據。傳感器數據線程以您的傳感器/處理確定的速率寫入，UI線程讀取適合您應用程序的任何刷新速率。

來源

2016-06-08 15:27:23

NSOperationQueues中的信號量

回答

相關問題