Python主線程與Python子線程之間區(qū)別之談
Python子線程在創(chuàng)建自身的線程狀態(tài)對象后，會通過_PyGILState_NoteThreadState這個語句將這個對象放入到線程狀態(tài)對象鏈表中，當(dāng)前活動的Python子線程不一定是獲得了GIL的線程。
在thread1.py中主線程現(xiàn)在是獲得了GIL的，但是子線程到現(xiàn)在還沒有申請GIL，自然也不會將自身掛起。由于主線程和子線程都是Win32的原生線程。所以操作系統(tǒng)可能在主線程和Python子線程之間切換。我們在這里要著重指出操作系統(tǒng)級的線程調(diào)度和Python級的線程調(diào)度是不同的。
Python級的線程調(diào)度一定意味著GIL擁有權(quán)的易手，而操作系統(tǒng)級的線程調(diào)度并不一定意味著GIL的易手，當(dāng)所有的線程都完成了初始化動作之后。操作系統(tǒng)的線程調(diào)度和Python的線程調(diào)度才會同一。那時，Python的線程調(diào)度會迫使當(dāng)前活動線程釋放GIL，而這一操作會觸發(fā)GIL中維護的Event內(nèi)核對象。
這個觸發(fā)又進而觸發(fā)操作系統(tǒng)的線程調(diào)度。而在線程的初始化完成之前，在Python線程調(diào)度和操作系統(tǒng)線程調(diào)度之間并沒有這樣的因果關(guān)系。顯示了GIL在Python級線程調(diào)度與操作系統(tǒng)級線程調(diào)度之間所起的橋梁作用。
前面我們已經(jīng)剖析過PyEval_AcquireThread的代碼，在PyEval_AcquireThread中，子線程進行了***的沖刺，它要生存，要執(zhí)行，于是它開始通過PyThread_acquire_ lock爭取GIL。到了這一步。
Python子線程將自己掛起，操作系統(tǒng)的線程調(diào)度機制再也不能靠自身的力量將其喚醒，只有等待Python的線程調(diào)度機制強迫主線程放棄GIL后。子線程才會被喚醒；而子線程被喚醒之后，主線程卻又陷入了苦苦地等待中，同樣苦苦地守望著Python強迫子線程放棄GIL的那一刻。
當(dāng)子線程被Python的線程調(diào)度機制喚醒之后，它所作的***件事就是通過PyThreadState_Swap將Python維護的當(dāng)前線程狀態(tài)對象設(shè)置為其自身的狀態(tài)對象，一如操作系統(tǒng)的進程上下文環(huán)境恢復(fù)一樣。
現(xiàn)在我們的Python子線程開始等待GIL，但是注意，線程的初始化還沒有真正完成，因為子線程還沒有順利進入字節(jié)碼解釋器。當(dāng)Python線程調(diào)度將子線程喚醒之后。子線程將回到t_bootstrap中。
并進入PyEval_CallObjectWithKeywords，從這里一直往前，最終將調(diào)用PyEval_EvalFrameEx，進入解釋器。到了那個時候，Python子線程和主線程一樣，就完全被Python線程調(diào)度機制所控制了。
需要注意的是，PyThread_start_new_thread是在主線程中執(zhí)行的，而從bootstrap開始，則是在子線程中執(zhí)行的。其中涉及線程銷毀的動作，如PyThreadState_ DeleteCurrent等，將在后續(xù)的部分剖析。到了這里，讀者可能有些疑惑了，我們花費了大量篇幅剖析的線程狀態(tài)對象鏈表似乎沒有什么用啊。其實不然，試想一下，當(dāng)線程調(diào)度發(fā)生時。
在Python一級，需要通過之前剖析過的PyTrheadState_Swap函數(shù)切換當(dāng)前的線程狀態(tài)對象，這時候就需要根據(jù)線程id從線程狀態(tài)對象鏈表中獲取線程對象了。事實上，在Python內(nèi)部的許多API中，比如PyGILState_Ensure等等中，都會涉及這個鏈表，這些API在C與Python交互時可能被大量調(diào)用，有興趣的讀者可以自行深入探索一下。
【編輯推薦】
