在我的主要功能我設置：HTOP和OpenMP線程
omp_set_num_threads(20);
告訴OpenMP的使用20個線程（可有40個線程）。
然後我執行我的代碼，其中包含了指令：
#pragma omp parallel for shared(x,y,z)
主for循環，並通過監控HTOP CPU使用率（也許不是最好的方式，但仍然）。 for循環必須執行50個「任務」，每個任務都需要很長時間。我通過htop觀察到的是，任務完成後，線程數會下降。具體來說，使用20個線程，我期望編輯看到2000％的CPU使用率，直到剩餘的任務少於20個之後線程應該「釋放」自己。但是，我所看到的是2000％，在完成n個任務後，我看到了2000％ - （n * 100％）的表現。因此，看起來任務完成後，線程關閉而不是完成新任務。
這是預料之中還是聽起來很奇怪？
幾乎所有現有OpenMP編譯器的默認並行循環調度是static，這意味着OpenMP運行時將嘗試在線程之間平均分配迭代空間並執行靜態工作分配。由於您有50次迭代和20次線程，因此無法將工作平均分割爲20次，因此，一半線程將執行三次迭代，而另一半執行兩次迭代。
在（結合的parallel）for構造的末尾有一個隱含屏障，其中完成的線程等待其餘線程完成。根據OpenMP實現的不同，障礙可能實現爲繁忙的等待循環，作爲某個OS同步對象的等待操作，或作爲兩者的組合。在後兩種情況下，碰到屏障的線程的CPU使用率會在進入可中斷睡眠時立即降至零，或者最初在短時間內保持在100％（繁忙循環），然後降至零（這段等待）。
如果循環迭代需要完全相同的時間量，那麼會發生什麼情況是最初的CPU使用率爲2000％，然後在兩次迭代後（如果屏障實現使用短忙循環，則會多一點）將下降到1000％。如果迭代每次花費的時間不同，那麼線程將在屏障的不同時刻到達，並且CPU使用率將逐漸降低。
在任何情況下，請使用schedule(dynamic)讓第一個線程的每次迭代變爲可用。這將在迭代花費不同時間的情況下提高CPU利用率。當迭代每次花費相同的時間時，它將無濟於事。後一種情況下的解決方案是將迭代次數作爲線程數的整數倍。
因此，在20個任務之後，CPU使用率下降到零，並且您的並行循環永遠不會結束？ –
否，結束。我的問題是爲什麼線程在仍有任務需要處理時顯示死亡。 – user1938803
由於50除以20是2.5，並且大多數編譯器的默認循環調度是「靜態」，因此一半線程處理兩次迭代，另一半處理三次迭代。 –