Python 用戶級線程和內(nèi)核級線程

用戶級線程和內(nèi)核級線程（了解）

線程的實現(xiàn)可以分為兩類：用戶級線程(User-Level Thread)和內(nèi)核線線程(Kernel-Level Thread)，后者又稱為內(nèi)核支持的線程或輕量級進程。在多線程操作系統(tǒng)中，各個系統(tǒng)的實現(xiàn)方式并不相同，在有的系統(tǒng)中實現(xiàn)了用戶級線程，有的系統(tǒng)中實現(xiàn)了內(nèi)核級線程。

1、用戶級線程

內(nèi)核的切換由用戶態(tài)程序自己控制內(nèi)核切換,不需要內(nèi)核干涉，少了進出內(nèi)核態(tài)的消耗，但不能很好的利用多核Cpu。

在用戶空間模擬操作系統(tǒng)對進程的調(diào)度，來調(diào)用一個進程中的線程，每個進程中都會有一個運行時系統(tǒng)，用來調(diào)度線程。此時當該進程獲取cpu時，進程內(nèi)再調(diào)度出一個線程去執(zhí)行，同一時刻只有一個線程執(zhí)行。

2、內(nèi)核級線程

內(nèi)核級線程:切換由內(nèi)核控制，當線程進行切換的時候，由用戶態(tài)轉化為內(nèi)核態(tài)。切換完畢要從內(nèi)核態(tài)返回用戶態(tài)；可以很好的利用smp，即利用多核cpu。windows線程就是這樣的。

3、用戶級與內(nèi)核級線程的對比

用戶及線程和內(nèi)核線程的區(qū)別：

內(nèi)核支持線程是OS內(nèi)核可感知的，而用戶級線程是OS內(nèi)核不可感知的。 用戶級線程的創(chuàng)建、撤消和調(diào)度不需要OS內(nèi)核的支持，是在語言（如Java）這一級處理的；而內(nèi)核支持線程的創(chuàng)建、撤消和調(diào)度都需OS內(nèi)核提供支持， 而且與進程的創(chuàng)建、撤消和調(diào)度大體是相同的。 用戶級線程執(zhí)行系統(tǒng)調(diào)用指令時將導致其所屬進程被中斷，而內(nèi)核支持線程執(zhí)行系統(tǒng)調(diào)用指令時，只導致該線程被中斷。 在只有用戶級線程的系統(tǒng)內(nèi)，CPU調(diào)度還是以進程為單位，處于運行狀態(tài)的進程中的多個線程，由用戶程序控制線程的輪換運行；在有內(nèi)核支持線程的系統(tǒng)內(nèi)， CPU調(diào)度則以線程為單位，由OS的線程調(diào)度程序負責線程的調(diào)度。 用戶級線程的程序?qū)嶓w是運行在用戶態(tài)下的程序，而內(nèi)核支持線程的程序?qū)嶓w則是可以運行在任何狀態(tài)下的程序。

內(nèi)核線程的優(yōu)缺點：

優(yōu)點：當有多個處理機時，一個進程的多個線程可以同時執(zhí)行。 缺點：由內(nèi)核進行調(diào)度。

用戶級線程的優(yōu)缺點：

優(yōu)點： 線程的調(diào)度不需要內(nèi)核直接參與，控制簡單。 可以在不支持線程的操作系統(tǒng)中實現(xiàn)。 創(chuàng)建和銷毀線程、線程切換代價等線程管理的代價比內(nèi)核線程少得多。 允許每個進程定制自己的調(diào)度算法，線程管理比較靈活。 線程能夠利用的表空間和堆棧空間比內(nèi)核級線程多。 同一進程中只能同時有一個線程在運行，如果有一個線程使用了系統(tǒng)調(diào)用而阻塞，那么整個進程都會被掛起。另外，頁面失效也會產(chǎn)生同樣的問題。 缺點： 資源調(diào)度按照進程進行，多個處理機下，同一個進程中的線程只能在同一個處理機下分時復用

4、混合實現(xiàn)

用戶級與內(nèi)核級的多路復用，內(nèi)核同一調(diào)度內(nèi)核線程，每個內(nèi)核線程對應n個用戶線程

介紹：

歷史 在內(nèi)核2.6以前的調(diào)度實體都是進程，內(nèi)核并沒有真正支持線程。它是能過一個系統(tǒng)調(diào)用clone()來實現(xiàn)的，這個調(diào)用創(chuàng)建了一份調(diào)用進程的拷貝，跟fork()不同的是 ,這份進程拷貝完全共享了調(diào)用進程的地址空間。LinuxThread就是通過這個系統(tǒng)調(diào)用來提供線程在內(nèi)核級的支持的(許多以前的線程實現(xiàn)都完全是在用戶態(tài)， 內(nèi)核根本不知道線程的存在)。非常不幸的是，這種方法有相當多的地方?jīng)]有遵循POSIX標準，特別是在信號處理，調(diào)度，進程間通信原語等方面。 很顯然，為了改進LinuxThread必須得到內(nèi)核的支持，并且需要重寫線程庫。為了實現(xiàn)這個需求，開始有兩個相互競爭的項目：IBM啟動的NGTP(Next?Generation?POSIX?Threads)項目， 以及Redhat公司的NPTL。在2003年的年中，IBM放棄了NGTP，也就是大約那時，Redhat發(fā)布了最初的NPTL。 NPTL最開始在redhat?linux?9里發(fā)布，現(xiàn)在從RHEL3起內(nèi)核2.6起都支持NPTL，并且完全成了GNU?C庫的一部分。 設計 NPTL使用了跟LinuxThread相同的辦法，在內(nèi)核里面線程仍然被當作是一個進程，并且仍然使用了clone()系統(tǒng)調(diào)用(在NPTL庫里調(diào)用)。 但是，NPTL需要內(nèi)核級的特殊支持來實現(xiàn)，比如需要掛起然后再喚醒線程的線程同步原語futex. NPTL也是一個1*1的線程庫，就是說，當你使用pthread_create()調(diào)用創(chuàng)建一個線程后，在內(nèi)核里就相應創(chuàng)建了一個調(diào)度實體，在linux里就是一個新進程， 這個方法最大可能的簡化了線程的實現(xiàn)。 除NPTL的1*1模型外還有一個m*n模型，通常這種模型的用戶線程數(shù)會比內(nèi)核的調(diào)度實體多。在這種實現(xiàn)里，線程庫本身必須去處理可能存在的調(diào)度， 這樣在線程庫內(nèi)部的上下文切換通常都會相當?shù)目欤驗樗苊饬讼到y(tǒng)調(diào)用轉到內(nèi)核態(tài)。然而這種模型增加了線程實現(xiàn)的復雜性,并可能出現(xiàn)諸如優(yōu)先級反轉的問題， 此外，用戶態(tài)的調(diào)度如何跟內(nèi)核態(tài)的調(diào)度進行協(xié)調(diào)也是很難讓人滿意

軟件開發(fā) 人工智能 云計算 機器學習

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。