詳細(xì)說明Python虛擬機(jī)狀態(tài)問題
現(xiàn)在說明一下關(guān)于Python虛擬機(jī)的狀態(tài)問題，實(shí)際上Python當(dāng)前由兩個(gè)原生thread構(gòu)成，一個(gè)是主線程執(zhí)行程序（python.exe）時(shí)操作系統(tǒng)創(chuàng)建的，另一個(gè)是通過thread1.py創(chuàng)建的子線程。
在代碼清單15-1的[1]中，我們注意到boot->interp中保存了Python虛擬機(jī)的PyInter- preterState對象，這個(gè)對象中攜帶了Python的module pool這樣的全局信息，Python中所有的thread都會(huì)共享這些全局信息。
關(guān)于代碼清單15-1的[2]處所示的多線程環(huán)境的初始化動(dòng)作，有一點(diǎn)需要特別說明，當(dāng)Python啟動(dòng)時(shí)，是并不支持多線程的。換句話說，Python中支持多線程的數(shù)據(jù)結(jié)構(gòu)以及GIL都是沒有創(chuàng)建的，Python之所以有這種行為是因?yàn)榇蠖鄶?shù)的Python程序都不需要多線程的支持。
- [threadmodule.c]
- static PyObject* thread_PyThread_start_new_thread(PyObject *self, PyObject
- *fargs)
- {
- PyObject *func, *args, *keyw = NULL;
- struct bootstate *boot;
- long ident;
- PyArg_UnpackTuple(fargs, "start_new_thread", 2, 3, &func, &args, &keyw);
- //[1]：創(chuàng)建bootstate結(jié)構(gòu)
- boot = PyMem_NEW(struct bootstate, 1);
- boot->interp = PyThreadState_GET()->interp;
- boot->funcfunc = func;
- boot->argsargs = args;
- boot->keywkeyw = keyw;
- //[2]：初始化多線程環(huán)境
- PyEval_InitThreads(); /* Start the interpreter's thread-awareness */
- //[3]：創(chuàng)建線程
- ident = PyThread_start_new_thread(t_bootstrap, (void*) boot);
- return PyInt_FromLong(ident);
- [thread.c]
- /* Support for runtime thread stack size tuning.
- A value of 0 means using the platform's default stack size
- or the size specified by the THREAD_STACK_SIZE macro. */
- static size_t _pythread_stacksize = 0;
- [thread_nt.h]
- long PyThread_start_new_thread(void (*func)(void *), void *arg)
- {
- unsigned long rv;
- callobj obj;
- obj.id = -1; /* guilty until proved innocent */
- obj.func = func;
- obj.arg = arg;
- obj.done = CreateSemaphore(NULL, 0, 1, NULL);
- rv = _beginthread(bootstrap, _pythread_stacksize, &obj); /* use default stack size */
- if (rv == (unsigned long)-1) {
- //創(chuàng)建raw thread失敗
- obj.id = -1;
- }
- else {
- WaitForSingleObject(obj.done, INFINITE);
- }
- CloseHandle((HANDLE)obj.done);
- return obj.id;
- }
假如一個(gè)簡單地統(tǒng)計(jì)詞頻的Python腳本中居然出現(xiàn)了多線程，面對這樣的代碼，我們一定都會(huì)抓狂的J。對多線程的支持并非是沒有代價(jià)的，最簡單的一點(diǎn)，如果激活多線程機(jī)制。
而執(zhí)行的Python程序中并沒有多線程，那么在100條指令之后，Python虛擬機(jī)同樣會(huì)激活線程的調(diào)度。而如果不激活多線程，Python虛擬機(jī)則不用做這些無用功。所以Python選擇了讓用戶激活多線程機(jī)制的策略。在Python虛擬機(jī)啟動(dòng)時(shí)，多線程機(jī)制并沒有被激活，它只支持單線程，一旦用戶調(diào)用thread.start_new_thread。
明確指示Python虛擬機(jī)創(chuàng)建新的線程，Python就能意識到用戶需要多線程的支持，這個(gè)時(shí)候，Python虛擬機(jī)會(huì)自動(dòng)建立多線程機(jī)制需要的數(shù)據(jù)結(jié)構(gòu)、環(huán)境以及那個(gè)至關(guān)重要的GIL。在這里，我們終于看到了Python中多線程機(jī)制的平臺(tái)相關(guān)性，在Python25\Python目錄下，有一大thread_***.h這樣的文件，在這些文件中，包裝了不同操作系統(tǒng)的原生線程。#t#
并通過統(tǒng)一的接口暴露給Python，比如這里的PyThread_allocate_lock就是這樣一個(gè)接口。我們這里的thread_nt.h中包裝的是Win32平臺(tái)的原生thread，在本章中后面的代碼剖析中，還會(huì)有大量與平臺(tái)相關(guān)的代碼。
我們都以Win32平臺(tái)為例。一切真相大白了，原來，GIL（NRMUTEX）中的hevent就是Win32平臺(tái)下的Event這個(gè)內(nèi)核對象，而其中的thread_id將記錄任一時(shí)刻獲得GIL的線程的id。
到了這里，Python虛擬機(jī)中的線程互斥機(jī)制的真相漸漸浮出水面，看來Python是通過Win32下的Event來實(shí)現(xiàn)了線程的互斥，熟悉Win32的朋友馬上就可能想到，與這個(gè)Event對應(yīng)的，必定有一個(gè)WaitForSingleObject。
在PyEval_InitThreads通過PyThread_allocate_lock成功地創(chuàng)建了GIL之后，當(dāng)前線程就開始遵循Python的多線程機(jī)制的規(guī)則：在調(diào)用任何Python C API之前，必須首先獲得GIL。因此PyEval_InitThreads緊接著通過PyThread_acquire_lock嘗試獲得GIL。
與InterlockedCompareExchange相同的，InterlockedIncrement也是一個(gè)原子操作，其功能是將mutex->owned的值增加1。從這里可以看到，當(dāng)一個(gè)線程開始等待GIL時(shí)，其owned就會(huì)被增加1。顯然我們可以猜測，當(dāng)一個(gè)線程最終釋放GIL時(shí)，一定會(huì)將GIL的owned減1，這樣當(dāng)所有需要GIL的線程都最終釋放了GIL之后，owned會(huì)再次變?yōu)?1，意味著GIL再次變?yōu)榭捎谩?/P>
為了清晰地展示這一點(diǎn)，我們現(xiàn)在就來看看PyThread_aquire_lock的逆運(yùn)算，PyThread_release_lock每一個(gè)將從運(yùn)行轉(zhuǎn)態(tài)轉(zhuǎn)為等待狀態(tài)的線程都會(huì)在被掛起之前調(diào)用它以釋放對GIL的占有。
【編輯推薦】
