我的應用程序目前有一個「任務」列表（每個任務都包含一個函數 - 該函數可以像打印某些東西一樣簡單，但也可能更復雜），它可以循環使用。 （附加說明：大多數任務在執行後發送一個數據包）由於其中一些任務可能需要一段時間，因此我考慮爲每個任務使用不同的異步線程，從而允許同時運行所有任務。
這是一個聰明的事情嗎？
一個問題是，我不可能事先知道任務的數量，因此可能會導致創建不少線程，並且我在某處讀到每個不同的硬件都有其限制。我打算在一個樹莓派上運行我的應用程序，我認爲我將一直需要運行5到20個任務。每個任務有一個異步線程？
另外，一些任務有較低的「優先級」來運行其他人。
我應該先運行重要的任務，然後再運行不太重要的任務嗎？ （這裏的問題是，如果所有任務所需的時間總和超過了應該運行某個特定的重要任務的時間，那麼我的應用程序將不再準確）或者在異步線程中實現所有內容？或者只是嘗試通過在異步線程中進行「數據包發送」來使所有事情變得更快一些，因此無需等到數據包實際發送完畢？
在合理設計解決方案之前，您需要問自己很多問題。
是否希望限制併發任務的數量？
是否有可能在未來併發任務的數量將增加，你今天無法預測？
...並且可能還有更多。
如果回答任何這些是「是」，那麼你有幾種選擇：
生產者/消費者隊列有固定數量的線程排出隊列（不推薦恕我直言）
將您的任務作爲異步狀態機寫入事件分派器，如boost::io_service（這是更具可擴展性）。
如果你知道它一定會是20級併發的任務，你可能會逃脫std::async，但它是寫代碼草率的方式。
（1）我個人並不想限制他們。硬件是限制他們，我想。 （2）由於任務數量也受硬件限制，併發任務的數量不能真正增加太多。爲什麼這會是一種拙劣的編寫代碼的方式？感謝你的回答。 –
C++標準中未定義允許的併發線程數。也沒有（便攜式）的方式來查詢系統的線程限制。這提供了一種方法，其中可用於程序的線程數由環境提供（confit文件，命令行等）。然後，這就提出了一種基於異步任務的方法，因爲我們不受任意線程限制的限制。 –
那麼，如果你忘記編程方面本身，我認爲可以同時運行多少個線程非常依賴於硬件？由於我打算在非常小的PC上運行我的應用程序，例如RaspberryPi，我不確定20個併發線程是不是太多。 –
你看了OpenMP（openmp.org） –
@WilliamJones謝謝，我會給它一個閱讀。但我認爲，現在我的問題仍然是理論上的，已經沒有選擇圖書館了：首先，我需要知道我想做什麼是可能的，或者如果有更好的方法。 –