「實時」約束是否阻止使用任務調度程序？

Question

通過任務調度程序，我的意思是工作線程池的任何實現，它根據設計的任何算法將工作分配給線程。 （如英特爾TBB）

我知道「實時」約束意味着工作在可預測的時間內完成（我不是在談論速度）。所以我的猜測是使用一個任務調度程序，據我所知，它不能保證某個任務會在給定時間之前執行，這使得應用程序無法在這些約束中使用。

或者我錯過了什麼？有沒有辦法兼得？也許是通過強制假設可以處理的數據量？或者也許有可預測的任務調度程序？

我說的是「硬」實時約束，而不是軟實時（如視頻遊戲）。

澄清：

據瞭解，有在C++的功能，是不可能在這種情況下的使用方法：新建，刪除，拋出時，將dynamic_cast。它們是不可預測的（你不知道在這些操作之一上可以花費多少時間，這取決於執行前甚至不知道的太多參數）。 你不能真正在實時環境中使用它們。 我問的是，任務調度程序是否具有相同的不可預測性，以至於無法在實時應用程序中使用它們？

Answer 1

實時術語相當靈活。 「硬實時」傾向於意味着幾十微秒會使「正確工作」和「不正常工作」之間的區別，而不是所有的「實時」系統都需要這種實時性。

我曾經在一個手機無線電基站工作過，主板上的一個設備有一箇中斷，每2毫秒觸發一次，爲了正確操作（不會失去呼叫），我們必須處理中斷，即在中斷內部完成工作，並在100微秒內將新值寫入硬件寄存器 - 如果我們錯過了，會有掉話，如果在160微秒後沒有中斷，系統會這就是「硬實時」，特別是當處理器運行在幾十MHz時。如果您生產視頻播放器，則需要在幾毫秒的範圍內實時播放。

「顯示股票價格」可能在100ms範圍內。

對於網絡服務器來說，在1-2秒內做出響應可能是沒有問題的。

此外，「最差的情況比X更糟糕」意味着失敗（例如上面的情況有100微秒或掉線的情況 - 如果每幾周發生一次以上的情況就會很糟糕 - 甚至幾次一年是真的應該固定的東西）。這被稱爲「硬實時」。

但是其他系統錯過了最後期限意味着「哦，好吧，我們必須再做一遍」或者「一幀視頻閃爍一下」，只要它不經常發生，它可能是好的。這被稱爲「軟實時」。

許多現代硬件會使硬實時（10秒或100微秒範圍）變得困難，因爲圖形處理器只會停止處理器訪問內存，或者如果處理器變熱，引腳stopclk拉100微秒...

大多數現代操作系統的，如Linux和Windows，都沒有真正的意思是「硬實時」。有些代碼段在這些操作系統的某些部分禁止中斷時間超過100微秒。

你可以幾乎肯定會得到一些不錯的「軟實時」（即，錯過最後期限是不是失敗，只是一個小麻煩）了主流的現代操作系統擁有現代化的硬件。它可能需要修改操作系統或專用實時操作系統（也許還有適當的特殊硬件），以使系統能夠實時實時操作。

但只有在世界上的幾件事情需要這一類的硬實時。硬實時要求通常由硬件來處理 - 例如，我上面描述的下一代無線基站具有更聰明的硬件，所以你只需要在下一個2年內給它新的值，幾毫秒，而且你沒有「瘋狂地在幾十微秒內完成它」。在現代移動電話中，GSM或UMTS協議主要由專用DSP（數字信號處理器）處理。

即使未達到最終期限的情況只發生一次，如果無法滿足特定的期限（或一組期限），「實時實時」要求是系統真正失敗。但是，不同的系統有不同的系統對截止日期的實際時間有不同的敏感度（正如Jerry Coffin所提到的那樣）。幾乎可以肯定的是，我們可以找到一些商業上可用的通用OS完全適合處理硬實時系統的實時需求的情況。還有一些絕對確定的情況是，如果沒有專門的系統，這種硬實時要求不可能實現。

我想說的是，如果你從OS希望亞毫秒級的保證，那麼桌面Windows或Linux不適合你。這實際上取決於操作系統和調度程序設計的整體理念，而構建硬實時操作系統需要考慮很多關於鎖定和潛在的一個線程以阻止另一個線程，從運行等。

我不認爲有一個答案適用於你的問題。是的，您當然可以在具有嚴格實時要求的系統中使用線程池。除非在操作系統中對此有明確的支持，否則你可能無法在毫秒級的基礎上完成。您可能需要有專用的線程和進程來處理最高優先級的實時行爲，這不屬於線程池本身。

對不起，如果這不是說你的答案是「是」或「否」，但我認爲你需要對操作系統的實際行爲進行一些研究，看看它能給出什麼樣的保證最壞的情況下）。你還必須決定什麼是最糟糕的情況，以及如果你錯過了最後期限 - 會有很多人死亡（飛機從天上掉下來），或者一些銀行家會損失數百萬美元，會發生什麼？燈會在路口兩個方向同時出現，還是從揚聲器中發出一些不好的聲音？

Answer 2

是的，這是可以做到的，但沒有它不是小事，而且是有極限。

可以編寫調度以保證（例如），該中斷處理程序，異常處理（等）保證在不脫離發生時的一段固定的時間被調用。您可以保證任何給定的線程將（例如）在任何給定的秒（或適當的幾分之一秒）內獲得至少X毫秒的CPU時間。

爲了執行後者，您通常需要准入標準 - 調度程序說「抱歉」的能力，但我不能將此調度爲實時線程，因爲CPU已經負載過多。

在其他情況下，它所做的只是保證至少（比如說）99％的CPU時間將被賦予實時任務（如果有的話），並且取決於系統的設計，安排足夠的實時任務，這將確保他們完成得足夠快。

我覺得有必要補充一點，實時要求的「硬度」幾乎完全正交於所需的響應速度。相反，這幾乎完全取決於遲到的嚴重後果。

舉個例子，考慮一個核電站。對於發生的很多事情，你正在處理的時間以分鐘爲單位，有些甚至是幾小時。例如，用50萬加侖的水填充一個特定的腔室就不會在幾微秒或幾毫秒內發生。

與此同時，後面的答案的後果可能是巨大的 - 很可能導致不只是幾個人死亡像醫院設備可以，但潛在的數百甚至數千人死亡，數億美元的損害，等等。因此，儘管截止日期在大多數典型標準中非常「寬鬆」，但它與實時要求一樣「很難」。

另一方面，數字音頻播放有多更嚴格的限制。在某些情況下，延遲或退出可能會聽起來很低，只有幾分之一毫秒。同時，除非您爲大型音樂會（或其他音樂會）提供聲音處理，否則退出的後果通常會成爲用戶的一小部分煩惱。

當然，也有可能將兩者結合起來 - 例如，在高頻交易中，截止日期可能會在幾微秒左右（因此）錯過截止日期的損失可能很容易數百萬或數千萬（美元|歐元|磅|等等）

Answer 3

「實時」不僅僅意味着「快速」，這意味着系統可以響應以滿足現實世界的最後期限。這些截止日期取決於你在現實世界中處理的事情。

任務是否在特定時間範圍內完成是該任務的一個特徵，而不是調度程序。調度程序可以決定哪個任務獲取資源，如果任務尚未完成截止日期，它可能會被停止或資源使用受到限制，以便其他任務可以滿足截止日期。

因此，您的問題的答案是您需要將工作負載，截止日期和調度程序放在一起，並構建您的系統以滿足您的要求。沒有魔法調度程序可以執行任意任務並在可預測的時間內完成任務。

更新：

任務調度可以在實時系統中使用，如果它提供了你需要的保障。正如其他人所說，有任務調度程序提供這些保證。

關於意見：問題是時間的上限。

如果您將它們重載爲具有您之後的性能特徵，則可以使用new和delete;問題不是新的和刪除，它是動態內存分配。沒有要求new和delete使用通用動態分配器的情況，您可以使用它們從靜態分配的池中分配，這些池的大小適合您的工作負載並具有確定性行爲。

在dynamic_cast上：我傾向於不使用它，但我不認爲它的性能是非確定性的，應該在實時代碼中被禁止。這是一個同樣問題的例子：理解最壞情況的表現很重要。