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