建站
咨詢
售后
建站咨詢
新聞中心
在Python中提供的一些接口中，一定不能少的肯定是創(chuàng)建Python應(yīng)用線程的接口，倘若沒有這個接口，編程還有什么太多的意義啊，對多線程的支持并非是沒有代價的。
我們注意到boot->interp中保存了Python的PyInter- preterState對象，這個對象中攜帶了Python的module pool這樣的全局信息，Python中所有的thread都會共享這些全局信息。關(guān)于代碼清單所示的多線程環(huán)境的初始化動作。
有一點需要特別說明，當(dāng)Python啟動時，是并不支持多線程的。換句話說，Python中支持多線程的數(shù)據(jù)結(jié)構(gòu)以及GIL都是沒有創(chuàng)建的，Python之所以有這種行為是因為大多數(shù)的Python應(yīng)用線程都不需要多線程的支持。
假如一個簡單地統(tǒng)計詞頻的Python腳本中居然出現(xiàn)了多線程，面對這樣的代碼，我們一定都會抓狂的J。對多線程的支持并非是沒有代價的。最簡單的一點，如果激活多線程機制，而執(zhí)行的Python程序中并沒有多線程，那么在100條指令之后，Python虛擬機同樣會激活線程的調(diào)度。
而如果不激活多線程，Python虛擬機則不用做這些無用功。所以Python選擇了讓用戶激活多線程機制的策略。在Python虛擬機啟動時，多線程機制并沒有被激活，它只支持單線程，一旦用戶調(diào)用thread.start_new_thread。
明確指示Python虛擬機創(chuàng)建新的線程，Python就能意識到用戶需要多線程的支持，這個時候，Python虛擬機會自動建立多線程機制需要的數(shù)據(jù)結(jié)構(gòu)、環(huán)境以及那個至關(guān)重要的GIL。
在這里，我們終于看到了Python中多線程機制的平臺相關(guān)性，在Python25\Python目錄下，有一大批thread_***.h這樣的文件。在這些文件中，包裝了不同操作系統(tǒng)的原生線程，并通過統(tǒng)一的接口暴露給Python，比如這里的PyThread_allocate_lock就是這樣一個接口。
我們這里的thread_nt.h中包裝的是Win32平臺的原生thread，在本章中后面的代碼剖析中，還會有大量與平臺相關(guān)的代碼，我們都以Win32平臺為例。在PyThread_allocate_lock中，與PyEval_InitThreads非常類似的，它會檢查一個initialized的變量，如果說GIL指示著Python的多線程環(huán)境是否已經(jīng)建立。
那么這個initialized變量就指示著為了使用底層平臺所提供的原生thread，必須的初始化動作是否完成。這些必須的初始化動作通常都是底層操作系統(tǒng)所提供的API，不同的操作系統(tǒng)可能需要不同的初始化動作。
一切真相大白了，原來，GIL（NRMUTEX）中的hevent就是Win32平臺下的Event這個內(nèi)核對象，而其中的thread_id將記錄任一時刻獲得GIL的線程的id。到了這里，Python中的線程互斥機制的真相漸漸浮出水面。
看來Python應(yīng)用線程是通過Win32下的Event來實現(xiàn)了線程的互斥，熟悉Win32的朋友馬上就可能想到，與這個Event對應(yīng)的，必定有一個WaitForSingleObject。在PyEval_InitThreads通過PyThread_allocate_lock成功地創(chuàng)建了GIL之后，當(dāng)前線程就開始遵循Python的多線程機制的規(guī)則：
在調(diào)用任何Python C API之前，必須首先獲得GIL。因此PyEval_InitThreads緊接著通過PyThread_acquire_lock嘗試獲得GIL。最終，一個線程在釋放GIL時，會通過SetEvent通知所有在等待GIL的hevent這個Event內(nèi)核對象的線程，結(jié)合前面的分析。
如果這時候有線程在等待GIL的hevent，那么將被操作系統(tǒng)喚醒。這就是我們在前面介紹的Python將線程調(diào)度的第二個難題委托給操作系統(tǒng)來實現(xiàn)的機制。到了這時，調(diào)用PyEval_InitThread的線程（也就是Python主線程）已經(jīng)成功獲得了GIL，最后會調(diào)用PyThread_get_thread_ident()。
通過Win32的API：GetCurrent- ThreadId，獲得當(dāng)前Python主線程的id，并將其賦給main_thread，main_thread是一個靜態(tài)全局變量。專職存儲Python主線程的線程id，用以判斷一個線程是否是Python主線程。最后，我們在給出整個PyEval_InitThread的函數(shù)調(diào)用關(guān)系。
值得注意的是，obj.done是一個Win32下的Semaphore內(nèi)核對象，這個特殊的內(nèi)核對象的用途我們馬上就會看到。我們創(chuàng)建線程的工作需要func和arg，但是Win32下創(chuàng)建線程的API只允許用戶指定一個自定義的參數(shù)，這就是需要用obj來打包的原因。
完成打包之后，調(diào)用Win32下創(chuàng)建thread的API：_beginthread來完成線程的創(chuàng)建。奇怪的是，我們期望的線程過程應(yīng)該是thread1.py中定義的那個threadPoc呀，而這里指定的線程過程卻是一個相當(dāng)面生的bootstrap。實際上，在bootstrap中，會最終調(diào)用thread1.py中定義的threadProc。
但是，這里有一個至關(guān)重要的轉(zhuǎn)折，還記得我們現(xiàn)在在哪里嗎？沒錯，我們現(xiàn)在是沿著主線程的執(zhí)行路徑在剖析，而對bootstrap的調(diào)用并不是在主線程中發(fā)生的，而是在通過_beginthread所創(chuàng)建的子線程中發(fā)生的。從這里開始，我們需要特別注意代碼的執(zhí)行是在哪個線程中執(zhí)行的，這對于理解Python應(yīng)用線程機制相當(dāng)重要。
好了，花開兩朵，各表一枝。我們繼續(xù)沿著主線程的執(zhí)行路徑前進。如果不出什么意外，_beginthread將最終成功地創(chuàng)建Win32下的原生線程，并順利返回。在返回之后，主線程開始將自己掛起，等待obj.done。
我們前面看到，這是一個Win32的Semaphore內(nèi)核對象。由于obj已經(jīng)作為參數(shù)傳遞給了子線程，所以我們猜想，子線程會設(shè)置這個Semaphore，并最終喚醒主線程?，F(xiàn)在我們來理清一下Python當(dāng)前的狀態(tài)。
Python當(dāng)前實際上由兩個Win32下的原生thread構(gòu)成，一個是執(zhí)行python程序（python.exe）時操作系統(tǒng)創(chuàng)建的主線程，另一個是我們通過thread1.py創(chuàng)建的子線程。主線程在執(zhí)行PyEval_InitThread的過程中。
得了GIL，但是目前已經(jīng)被掛起，這是為了等待子線程中控制著的obj.done。子線程的線程過程是bootstrap，不過我們剛才已經(jīng)猜測了，從bootstrap出發(fā)，最終將在Python解釋器中執(zhí)行python1.py中定義的theadProc。但是，我們知道，子線程為了訪問Python解釋器，必須首先獲得GIL，這是Python世界的游戲規(guī)則，誰也不能例外。
【編輯推薦】
- 漫談Python 源代碼編制技巧
- 簡單易于操作的Python 工具詳解
- 有關(guān)Python應(yīng)用領(lǐng)域進行說明介紹
- PythonAndroid面向?qū)ο蟮木幊獭狿ython應(yīng)用程序
- 如何使用Python模塊解析配置文件 ？
分享文章：對Python應(yīng)用線程介紹說明
轉(zhuǎn)載源于：http://www.dlmjj.cn/article/codpohs.html
