基于pcode數(shù)量的調(diào)度方式

按照Python社區(qū)的想法，操作系統(tǒng)本身的線程調(diào)度已經(jīng)非常成熟穩(wěn)定了，沒(méi)有必要自己搞一套。所以Python的線程就是C語(yǔ)言的一個(gè)pthread，并通過(guò)操作系統(tǒng)調(diào)度算法進(jìn)行調(diào)度(例如linux是CFS)。為了讓各個(gè)線程能夠平均利用CPU時(shí)間，python會(huì)計(jì)算當(dāng)前已執(zhí)行的微代碼數(shù)量，達(dá)到一定閾值后就強(qiáng)制釋放GIL。而這時(shí)也會(huì)觸發(fā)一次操作系統(tǒng)的線程調(diào)度(當(dāng)然是否真正進(jìn)行上下文切換由操作系統(tǒng)自主決定)。

偽代碼

whileTrue:

acquireGIL

foriin1000:

dosomething

releaseGIL

/*GiveOperatingSystemachancetodothreadscheduling*/

這種模式在只有一個(gè)CPU核心的情況下毫無(wú)問(wèn)題。任何一個(gè)線程被喚起時(shí)都能成功獲得到GIL(因?yàn)橹挥嗅尫帕薌IL才會(huì)引發(fā)線程調(diào)度)。但當(dāng)CPU有多個(gè)核心的時(shí)候，問(wèn)題就來(lái)了。從偽代碼可以看到，從releaseGIL到acquireGIL之間幾乎是沒(méi)有間隙的。所以當(dāng)其他在其他核心上的線程被喚醒時(shí)，大部分情況下主線程已經(jīng)又再一次獲取到GIL了。這個(gè)時(shí)候被喚醒執(zhí)行的線程只能白白的浪費(fèi)CPU時(shí)間，看著另一個(gè)線程拿著GIL歡快的執(zhí)行著。然后達(dá)到切換時(shí)間后進(jìn)入待調(diào)度狀態(tài)，再被喚醒，再等待，以此往復(fù)惡性循環(huán)。

PS：當(dāng)然這種實(shí)現(xiàn)方式是原始而丑陋的，Python的每個(gè)版本中也在逐漸改進(jìn)GIL和線程調(diào)度之間的互動(dòng)關(guān)系。例如先嘗試持有GIL在做線程上下文切換，在IO等待時(shí)釋放GIL等嘗試。但是無(wú)法改變的是GIL的存在使得操作系統(tǒng)線程調(diào)度的這個(gè)本來(lái)就昂貴的操作變得更奢侈了。

關(guān)于GIL影響的擴(kuò)展閱讀

為了直觀的理解GIL對(duì)于多線程帶來(lái)的性能影響，這里直接借用的一張測(cè)試結(jié)果圖(見(jiàn)下圖)。圖中表示的是兩個(gè)線程在雙核CPU上得執(zhí)行情況。兩個(gè)線程均為CPU密集型運(yùn)算線程。綠色部分表示該線程在運(yùn)行，且在執(zhí)行有用的計(jì)算，紅色部分為線程被調(diào)度喚醒，但是無(wú)法獲取GIL導(dǎo)致無(wú)法進(jìn)行有效運(yùn)算等待的時(shí)間。

GIL的存在導(dǎo)致多線程無(wú)法很好的立即多核CPU的并發(fā)處理能力。

那么Python的IO密集型線程能否從多線程中受益呢?我們來(lái)看下面這張測(cè)試結(jié)果。顏色代表的含義和上圖一致。白色部分表示IO線程處于等待。可見(jiàn)，當(dāng)IO線程收到數(shù)據(jù)包引起終端切換后，仍然由于一個(gè)CPU密集型線程的存在，導(dǎo)致無(wú)法獲取GIL鎖，從而進(jìn)行無(wú)盡的循環(huán)等待。

簡(jiǎn)單的總結(jié)下就是：Python的多線程在多核CPU上，只對(duì)于IO密集型計(jì)算產(chǎn)生正面效果;而當(dāng)有至少有一個(gè)CPU密集型線程存在，那么多線程效率會(huì)由于GIL而大幅下降

以上內(nèi)容為大家介紹了python之當(dāng)前GIL設(shè)計(jì)的缺陷，希望對(duì)大家有所幫助，如果想要了解更多Python相關(guān)知識(shí)，請(qǐng)關(guān)注IT培訓(xùn)機(jī)構(gòu):千鋒教育。http://m.2667701.com/