最大化工作線程利用

要解決的一個問題（和更好的多任務處理我的理解），我已經寫了一個小的線程池實現。這個線程池會加速一些工作線程，這些工作線程會在線程池的客戶端添加它們時將任務從隊列中彈出。出於此問題的目的，當任務隊列爲空時，工作線程全部終止。最大化工作線程利用

做一些基本的標杆，我已經發現了應用程序後花費〜其60％的時間等待獲取隊列鎖。據推測，這主要發生在工作者線程內。

這僅表示我不會放棄工作線程足夠的做，或更多的東西？有沒有直截了當的我可能會失去增加工作線程吞吐量？

編輯：這是一些粗略的僞代碼，應該說明一些事情。這些是鎖被收購的只有兩個地方/工作線程的執行過程中釋放（這是絕大多數的應用程序的運行時間。）

std::list<task_t> task_list; 

// Called by the client to add tasks to the thread pool 
void insert_task(const task_t& task) 
{ 
    lock_type listlock(task_mutex); 

    task_list.push_back(task); 
} 

// The base routine of each thread in the pool. Some details 
// such as lifetime management have been omitted for clarity. 
void worker_thread_base() 
{ 
    while (true) 
    { 
     task_t task; 

     { 
     lock_type listlock(task_mutex); 

     if (task_list.empty()) 
      continue; 

     task = task_list.front(); 

     task_list.pop_front(); 
     } 

     do_task(task); 
    } 
}

來源

2010-08-05 fbrereto

我們需要查看一些代碼，以瞭解爲什麼您的應用程序卡在隊列鎖中。我認爲你的線程大部分時間應該停留在「等待」狀態（使用條件變量或類似的東西）。 – Starkey 2010-08-05 17:17:54

你設計安裝，每個線程坐和「旋轉」，試圖獲取鎖。除非每個工作者線程都在執行工作，否則這種情況會不斷髮生 - 在這種情況下，鎖定會不受歡迎，工作就會發生。

與您的所有線程只是坐在紡上的鎖，你要使用相當多的CPU時間等待。根據您的設計，這是有點期待的。

你會發現受阻，如果你有較少的工作線程可能會大幅收縮時間的百分比 - 在這裏你比線程更多的工作項目，並在該點，你會花很少的時間等待這個鎖。

一個更好的設計是使用某種形式的無鎖隊列爲您的工作隊列，因爲這可能防止在這一點上等待。另外，有一個等待句柄可以阻止工作線程，直到隊列中有工作，這將防止不必要的旋轉。

來源

2010-08-05 17:39:28

你是想用一個做到這一點單鎖，多鎖？ Mutexs？你在用什麼等待語義？

我就從你的描述猜測（這純粹是猜測），你有類似的東西：

lock(theLock) { 
// ... do lots of work ... 
}

在你的主線程，其包含的代碼派遣到輕量級線程。一個原因可能會導致等待時間加劇，這是因爲你需要從已經排隊等待執行的線程中取回信號（再次，這是一個猜測，因爲你沒有給出任何代碼）。你可能會解決這個

一種方法是使用一個明確的鎖，如上切換，進入使用當你想線程搶工作的其中一個是脈衝信號一個互斥。

雖然沒有看到您的當前實現，我不知道我能在更過這一點。

來源

2010-08-05 17:23:53 GrayWizardx

最大化工作線程利用

回答

相關問題