我有一個主線程程序和診斷線程之前限制線程的運行時間。主線程基本上是一個while(1)循環，執行各種任務。其中一項任務是爲診斷引擎提供有關係統的信息，然後稍後再檢查（即在下一個循環中）以查看是否有任何問題需要處理。主循環的迭代時間不應超過0.1秒。如果一切正常，那麼診斷引擎幾乎沒有時間回覆答案。但是，如果出現問題，診斷引擎可能需要幾秒鐘才能確定問題。由於這個原因，每次診斷引擎收到新的信息時，它都會啓動一個新的診斷線程。升壓線程：是否有可能移動到另一個線程
我們遇到的問題是，診斷線程正在偷離主線程的時間。實際上，儘管我們有兩個線程，但主線程無法按照我的意願運行，因爲診斷線程仍在旋轉。
使用Boost線程，是否可以在移動到另一個線程之前限制線程可以運行的時間量？此處的重要性在於，我們使用的診斷算法是blackbox，所以我們不能在其中放置任何線程代碼。謝謝！
如果你運行多個線程，他們確實會消耗CPU時間來執行。如果您只有一個處理器，並且一個線程正在處理處理器密集型工作，那麼該線程將減慢在其他線程上完成的工作。如果使用特定於OS的工具來更改線程優先級，則可以使診斷線程的優先級低於主線程。另外，你提到診斷線程是「旋轉」的。你的意思是，它確實有一個相當於自旋等待這樣的：
while(!check_done()) ; // loop until done
如果是的話，我會強烈建議你儘量避免這種忙等待，因爲它會佔用CPU時間沒有取得什麼。但是，雖然多個線程可能會導致對方減慢速度，但如果看到幾秒鐘的實際延遲，則會提示存在另一個問題，並且主線程實際上正在等待診斷線程完成。檢查診斷線程對join()的調用是否在主循環之外。
另一種可能性是，診斷線程正在鎖定主線程循環所需的互斥鎖。檢查哪些互斥鎖被鎖定以及在哪裏。
要真正幫助，我需要看一些代碼。
從你提出問題的方式看來，你不太清楚線程是如何工作的。我假設「移動到另一個線程之前線程可以運行的時間量」是指每個線程花費的CPU週期數。這發生在每秒數十萬次。
Boost.Thread不支持線程優先級，雖然您的操作系統特定的線程API會。但是，您的問題似乎表明需要進行基本的重新設計 - 或至少嚴重分析找出瓶頸。
你不能在操作系統級別這樣做，所以我懷疑boost有什麼具體的限制執行時間。你可以用小塊操作和等待來僞裝它，但它不乾淨。
我會建議尋找處理器親和力，無論是在線程或進程級別（這將是操作系統特定的）。如果您可以將診斷處理隔離到多核機器上的[邏輯]處理器的有限子集，那麼它將爲您提供一個非常重要的機制來控制相對於主進程的最大執行量。這是我嘗試做類似事情時找到的最佳解決方案。
希望有所幫助。
看起來像你的線程是互鎖的，所以你的主線程等待，直到後臺線程完成其工作。檢查任何可能導致此問題的多線程同步。
檢查沒什麼關係到你的雙核系統上編程OS調度運行，所以兩個線程可以真正並行
這正是我的想法，但在主循環期間，我查詢診斷循環以查看它是否已經很忙。當它忙時，我將這條消息打印到屏幕上。在我的程序似乎掛起的情況下，我至少會看到一個，但有時會出現幾個「診斷線程正忙」的消息。也許它還是別的，但我認爲如果檢查回來* busy *，那麼我不會做任何其他干擾該線程的事情。 – JnBrymn 2010-09-22 20:25:15
由於我*很*新線程編程，肯定有可能我誤解了事情。然而你引用的例子更可能是一個糟糕的選擇。如果我有線程A和線程B，那麼我希望操作系統能夠很快地在A和B之間來回切換，因此對於線程A中的GUI用戶來說，A總是處於打開狀態。在我看來，操作系統似乎允許線程B在切換回線程A之前運行2秒。爲什麼會這樣呢？ （另外，請告訴我，如果我仍然對某些線程問題感到困惑。） – JnBrymn 2010-09-19 00:44:12
線程不會像這樣阻塞。你的操作系統不應該允許這個。但是，應該可以使用您的分析器來確定在每個線程中花費的實際時間。 – rlbond 2010-09-19 00:57:39
我從未使用過探查器。任何建議？我的IDE是Eclipse CDT，我正在使用gnu工具鏈（gcc，g ++，make，gdb）。 – JnBrymn 2010-09-19 01:08:09