操作系統多進程多線程的相關問題？

01-06

對於主流的操作系統Linux、Windows、Unix等
1.對於單核CPU，多線程程序和多進程程序調度是一樣的嗎？即例如最開始系統中有50個進程，加進來一個進程，每個進程的調度頻率是1/51，再加進來一個進程，每個進程調度頻率是1/52，所以對於一個多進程的程序，如果最開始它開啟了2個進程，那麼它的調度頻率就是2/52。那麼如果這個程序是一個進程中開啟的是兩個線程，那麼它的調度周期是2/52，還是1/51，即操作系統是以線程調度還是進程調度。同時對於一個程序是不是開的進程或線程越多，那麼一般情況下(不考慮進程線程創建，和特殊情況)，這個程序的效率就越高（同一個調度周期內，它能夠上CPU的機會更多）
2.對於問題1，如果是以線程為調度單位，那麼操作系統會不會優化讓連續一個進程的多個線程依次調度，這樣就可以節省進程上下文的時間。
3.對於多核的CPU（例如4核），是以進程為調度單位，還是以線程為調度單位？如果以進程為調度單位，那麼是不是內存中要同時保持4個進程的上下文？如果是以線程為單位，那麼是否必須是同一個進程的4個線程，還是可以是4個不同進程的4個不同線程？
4. 對於3的情況，如果是以線程為調度單位，操作系統是否可以優化，讓一個進程的多個線程首先佔據4個核，然後下一個調度周期優先讓這個進程的其餘線程繼續跑，餘下來的核再給其他進程的線程用，這樣可以節省進程上下文的時間。

5. 多核CPU的每個核能否做到非同步時鐘？
6. 多個核，每個核操作系統是統一管理還是分別管理，總感覺對於每個進程在單核CPU中和多核CPU中的管理不同，正所謂4個核 != 一個核*4（效率方面）？
7. 多個核，對於進程通信與線程同步有什麼影響？
望真正大神解答！

1.對於單核CPU，多線程程序和多進程程序調度是一樣的嗎？即例如最開始系統中有50個進程，加進來一個進程，每個進程的調度頻率是1/51，再加進來一個進程，每個進程調度頻率是1/52，所以對於一個多進程的程序，如果最開始它開啟了2個進程，那麼它的調度頻率就是2/52。那麼如果這個程序是一個進程中開啟的是兩個線程，那麼它的調度周期是2/52，還是1/51，即操作系統是以線程調度還是進程調度。同時對於一個程序是不是開的進程或線程越多，那麼一般情況下(不考慮進程線程創建，和特殊情況)，這個程序的效率就越高（同一個調度周期內，它能夠上CPU的機會更多）

絕大多數操作系統調度單位是線程，不是進程。

但跟你想像的不同，絕大多數的情況下CPU是閑著的而不是滿著，你自己看任務管理器就知道了，在有些OS上時間片的長度不一定固定，如果真是計算密集型任務（需要吃CPU），操作系統會讓它多佔一會的。

2.對於問題1，如果是以線程為調度單位，那麼操作系統會不會優化讓連續一個進程的多個線程依次調度，這樣就可以節省進程上下文的時間。

對於x86的CPU來說，切進程無非是換頁+刷TLB這些，動作其實很快。你打開Windows任務管理器，看上去似乎很多進程，但多數進程都是閑著不幹活的。

任務都是有一定優先順序的，操作系統考慮的是根據優先順序來調度，而不是切換上下文的時間，切換上下文的這點時間不算什麼時間。

3.對於多核的CPU（例如4核），是以進程為調度單位，還是以線程為調度單位？如果以進程為調度單位，那麼是不是內存中要同時保持4個進程的上下文？如果是以線程為單位，那麼是否必須是同一個進程的4個線程，還是可以是4個不同進程的4個不同線程？

不管單核多核，調度單位都是線程，跟進程沒關係。具體每個核是同一個進程還是不同進程，操作系統不關係，CPU也不關心，每個CPU都有寄存器能保存當前任務狀態，其餘的狀態都在內存里。

4. 對於3的情況，如果是以線程為調度單位，操作系統是否可以優化，讓一個進程的多個線程首先佔據4個核，然後下一個調度周期優先讓這個進程的其餘線程繼續跑，餘下來的核再給其他進程的線程用，這樣可以節省進程上下文的時間。

前面說了，進程切換的代價很低，而且多數情況下一個線程不可能跑滿一個時間片，如果一個進程把全部核都佔滿，如果某些線程跑完了需要釋放時間片怎麼辦？怎麼解決每個線程佔用時間片長度不同問題？

現場跑完了不釋放CPU？浪費。

釋放？又不符合你的模型，調度單位又變成線程了。

所以進程不作為調度的單位看待。

5. 多核CPU的每個核能否做到非同步時鐘？

可以。

6. 多個核，每個核操作系統是統一管理還是分別管理，總感覺對於每個進程在單核CPU中和多核CPU中的管理不同，正所謂4個核 != 一個核*4（效率方面）？

基於線程的調度效率比基於進程的效率高，因為一個進程的各個線程佔用時間片是不同的，基於進程的調度會造成極大的CPU時間浪費。

7. 多個核，對於進程通信與線程同步有什麼影響？

多核對於操作系統調度、鎖的寫法方面比較麻煩，對於上層應用，不需要考慮這些問題。按正常多線程加保護就夠用了。

-------------------------------------

你的問題里，覺得任務切換的開銷很大，實際上任務切換代價再大，也比浪費一個時間片要小。

基於進程的多核調度，就意味著某些情況下，某些核的時間片被浪費掉，這種性能損失比任務切換要大得多。

一個時間片內做幾百次任務切換都沒問題，與其減少任務切換，不如把浪費的時間片都用上。

任務切換的代價比中斷切換的代價要小，操作系統中各種外設的中斷（時鐘、PCI、DMA等）比任務切換的代價要大的多。

1.大多數調度器是按照線程調度的，而且，是的，你的線程越多你搶到的cpu也會越多，不過大多數情況下cpu是不用搶的，而計算密集的程序因為時刻處於就緒態也會比io密集的程序獲得多得多的時間片，雖然通常計算密集程序的優先順序更低

2.不過切個cr3沒那麼慢吧，而且觸發各種中斷的時候也可能切cr3，所以感覺對性能沒多大影響……tlb不命中的開銷確實是有一些的，不過切換線程也可能觸發tlb不命中

3.調度肯定最終是調度到線程的，因為只有線程才有rip的值，沒有rip就沒辦法iret。通常內存中會保存所有進程式控制制塊和線程式控制制塊，因通常os是不允許自己的內存被swap的，會大幅度降低效率，頁表可以被換出。

每個核心的的調度過程其實可以說是獨立的，每個核心的時鐘中斷是獨立的，然後在觸發調度時調度程序會在觸發調度的那一個核心上進行，所以基本上調度器不需要考慮其他核心的調度情況，然後，因為每個核心都有自己的cr3寄存器，所以，任意4個線程，cpu不在乎是否來自同一個進程，一般調度器也不在乎

4.沒必要，切cr3沒多少時間，tlb緩存吧反正中斷和系統調用都有可能tlb不命中呢，os只能把自己常用的東西放到tlb裡面，不可能全放。再說現在內存這麼大，tlb不命中還有內存呢，到需要訪問swap中的頁表的時候就是相對比較少的情況了。

5.非同步時鐘可以，cpu一個核心有幾個可編程時鐘，定時的長度可以調的。

6.大多數情況核心是互相獨立的，中斷，系統調用這些東西都是獨立進行，cpu 0上可以運行控制其他核心的特權指令

7.沒啥大區別，ipc是在內存中進行的，多核需要一些特殊的lock技巧什麼的

一般都是按線程調度，但是其實你說的這些都有個問題，就是只在所有線程優先順序相同、而且所有線程都100%佔用CPU的情況下才成立。實際操作系統當中很少會遇到這種情況。大部分情況下，線程都是處在空閑（一般是等待一個系統調用比如信號量）、或者等待IO的情況下，這時候線程會被掛起，等待IO或者系統調用完成，不會被調度進CPU。

多核情況下是任意的四個線程都可以調度到多核CPU中，沒有任何限制，但是有沒有優先順序不太清楚，Linux下面似乎進程和線程區別不大，線程是一種輕量級的進程的樣子。

我談談自己的看法。

看回答之前，希望你能夠知道：

1) 一般用途的操作系統中，很少有進程需要跑滿CPU。絕大多數情況下，都有CPU處於空閑狀態。這意味著絕大多數情況下，進程想用CPU時都能用個夠。

2) 上下文切換消耗的時間非常短。上下文切換主要造成的影響是上下文切換完之後，CPU cache命中率降低，導致短時間內CPU執行效率降低。

3) 現在一個系統上有多核CPU是很普遍的現象。保證多核CPU的每個核心都被充分利用才能夠更好的提升整個操作系統的效率。太過關註上下文切換帶來的性能降低是不值得的。

4) 除了上下文切換，一個線程從一個CPU核心被調度到另一個CPU核心也是需要時間代價的。代價會比上下文切換大一些。但跨CPU調度一般發生在某個CPU空閑的時候。也就是說跨CPU調度雖然代價大，但跨CPU調度是在「廢物利用」。對於操作系統整體而言是提升效率。

下面回答問題：

1.對於單核CPU，多線程程序和多進程程序調度是一樣的嗎？即例如最開始系統中有50個進程，加進來一個進程，每個進程的調度頻率是1/51，再加進來一個進程，每個進程調度頻率是1/52，所以對於一個多進程的程序，如果最開始它開啟了2個進程，那麼它的調度頻率就是2/52。那麼如果這個程序是一個進程中開啟的是兩個線程，那麼它的調度周期是2/52，還是1/51，即操作系統是以線程調度還是進程調度。同時對於一個程序是不是開的進程或線程越多，那麼一般情況下(不考慮進程線程創建，和特殊情況)，這個程序的效率就越高（同一個調度周期內，它能夠上CPU的機會更多）

多線程程序和多進程程序調度是不一樣的。

現在大多數調度器都是基於線程調度，即在不考慮優先順序、內存結構等調度參數影響的情況下，線程越多，整個進程效率越高。

但是CPU運算量是固定的，如果線程太多，調度器在每次調度時就需要在大量線程中選擇一個線程進行調度，這會浪費一些CPU運算量。而且如果線程過多，每個線程的調度延遲就會加大。

比如操作系統每1ms做一次任務調度，如果有100個線程處於就緒狀態，那需要1ms*100 = 100ms才能完整調度一次。這個調度延遲會讓用戶覺得系統卡爆了。

2.對於問題1，如果是以線程為調度單位，那麼操作系統會不會優化讓連續一個進程的多個線程依次調度，這樣就可以節省進程上下文的時間。

不會。上下文切換時間不值得通過這樣的優化去節省。

現在操作系統中的CPU資源大多數情況下是足夠的，與其在一個CPU上等待調度，不如換個核心直接跑。這連在同一CPU上下文切換都省了。

3.對於多核的CPU（例如4核），是以進程為調度單位，還是以線程為調度單位？如果以進程為調度單位，那麼是不是內存中要同時保持4個進程的上下文？如果是以線程為單位，那麼是否必須是同一個進程的4個線程，還是可以是4個不同進程的4個不同線程？

以線程為調度單位。在同一時刻可以有4個不同進程的4個不同線程在跑。因為多核CPU的每個核心是獨立的，可以分別控制。不必共用同一個內存空間，也就不必是同一進程的4個線程。

4. 對於3的情況，如果是以線程為調度單位，操作系統是否可以優化，讓一個進程的多個線程首先佔據4個核，然後下一個調度周期優先讓這個進程的其餘線程繼續跑，餘下來的核再給其他進程的線程用，這樣可以節省進程上下文的時間。

這種優化是有好處的，但是怎麼選擇哪些線程佔據哪個核呢？如果某個核上被分配的幾個線程恰好都是在等待IO或信號量，那這個核心就閑下來了。

而且如果不管其他CPU核心忙不忙，直接給別的核心增加線程的行為也欠妥吧。有可能有個核已經忙得要死要死的了，你還給它加線程，你這是要搞死它啊。不如讓線程先在當前CPU核心上運行，說不定線程在執行一點點之後就等待IO或者信號量去了呢？這樣不需要把線程分散到各其他CPU核心也能很快完成任務。說不定效率更高呢。

現在對於多核CPU，操作系統一般都有這樣一個調度機制。首先，所有進程在創建時都在創建者的CPU上等待。然後，當某個核空閑的時候，它會從忙的核心上調度一些在等待CPU的任務到自己這裡執行。執行完了再調一些任務過來。

這樣才能夠最大化的利用CPU，提升整個操作系統的效率。

5. 多核CPU的每個核能否做到非同步時鐘？

能，但是不覺得有什麼用。

6. 多個核，每個核操作系統是統一管理還是分別管理，總感覺對於每個進程在單核CPU中和多核CPU中的管理不同，正所謂4個核 != 一個核*4（效率方面）？

這還是蠻複雜的，應該算是分組管理吧。現在的CPU cache、超線程技術、NUMA技術等，都是調度器要考慮的東西，都會對操作系統進程管理產生影響。操作系統一般都會按照物理核心、numa域等對CPU核心進行分組，然後再考慮調度。

拿CPU cache舉個例子。

現在CPU都有cache，cache的作用就是拿一部分內存數據放到CPU裡面，這能提高CPU操作內存的速度。而且cache有L1、L2、L3等很多級。L1速度最快，一個CPU物理核心獨享。L2、L3速度依次降低，而且一般是一個CPU內的幾個核心共享。

如果一個CPU有4個核心，那麼在任務調度的時候，不管任務被調度到哪個核心，大多數情況下，L2、L3都有一點cache可以用到。這會減少重新從內存中讀取的數據量，速度就會快一些。這種情況下調度器會激進一點，儘可能讓每個核心得到利用。

如果有4個CPU，那麼任務調度的時候，不管任務被調度到了哪個CPU，大多數情況下，都沒有cache可以用，這樣的話CPU需要重新從內存中讀取大量數據，速度就會慢一些。這種情況下調度器會謹慎一點，減少跨CPU調度的情況。

但是，有4個CPU就會有4倍cache容量。在跨CPU調度任務較少發生的情況下，4倍cache容量能夠提高CPU的效率。

7. 多個核，對於進程通信與線程同步有什麼影響？

如果寫應用程序而不寫操作系統的話，沒啥影響。當做一般多線程操作就行了。

-----------------------

一個操作系統面對的實際問題是很複雜的，很多時候效率和響應時間不可兼得。如果為了節省上下文切換時間把一個進程的所有線程集中到一個核心上

不是真正大神,隨便水一發.

1.現代的OS基本以線程為調度單位,簡單來說也就是線程開越多,CPU佔用越大.如果以進程為調度單位的OS,也可以實現線程,用戶級線程,線段調度等由用戶(庫文件)編寫.這樣的話多少個線程CPU佔用一樣.

2.會.線程切換和進程切換,在操作還是有較大區別的.切線程比切進程快.

3.線程,不是必須.這樣理解,因為上下文數據是在CPU中,一個CPU獨佔一份上下文.不過有些內核操作需要互斥

4.不清楚,感覺不會.我覺得是反過來,多個線程偏愛某個CPU,這樣這個CPU切換的時候只是線程切換,不是進程切換,比較省力.

5.不清楚.

6.不理解題意.

7.對用戶來說是透明,它們都是用鎖和消息的介面.對OS來說,要使用原語操作而不能僅僅用關中斷來實現互斥.