python 多線程效率

在一臺(tái)8核的CentOS上，用python 2.7.6程序執(zhí)行一段CPU密集型的程序。

import time
def fun(n):#CPU密集型的程序
  while(n>0):
    n -= 1

start_time = time.time()
fun(10000000)
print('{} s'.format(time.time() - start_time))#測(cè)量程序執(zhí)行時(shí)間

測(cè)量三次程序的執(zhí)行時(shí)間，平均時(shí)間為0.968370994秒。這就是一個(gè)線程執(zhí)行一次fun(10000000)所需要的時(shí)間。

下面用兩個(gè)線程并行來跑這段CPU密集型的程序。

import time
import threading

def fun(n):
  while(n>0):
    n -= 1

start_time = time.time()
t1 = threading.Thread( target=fun, args=(10000000,) )
t1.start()
t2 = threading.Thread( target=fun, args=(10000000,) )
t2.start()

t1.join()
t2.join()
print('{} s'.format(time.time() - start_time))

測(cè)量三次程序的執(zhí)行時(shí)間，平均時(shí)間為2.150056044秒。

為什么在8核的機(jī)器上，多線程執(zhí)行時(shí)間并不比順序執(zhí)行快呢？

再做另一個(gè)實(shí)驗(yàn)，用下面的命令，把8核cpu中的7個(gè)核禁掉。

[xxx]# echo 0 > /sys/devices/system/cpu/cpu1/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu2/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu3/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu4/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu5/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu6/online
[xxx]# echo 0 > /sys/devices/system/cpu/cpu7/online

然后在運(yùn)行這個(gè)多線程的程序，三次平均時(shí)間為2.533491453秒。為什么多線程程序在多核上跑的時(shí)間只比單核快一點(diǎn)點(diǎn)呢？

這就要提到python程序多線程的實(shí)現(xiàn)機(jī)制了。

Python多線程實(shí)現(xiàn)機(jī)制

python的多線程機(jī)制，就是用C實(shí)現(xiàn)的真實(shí)系統(tǒng)中的線程。線程完全被操作系統(tǒng)控制。

python內(nèi)部創(chuàng)建一個(gè)線程的步驟是這樣的：

• 創(chuàng)建一個(gè)數(shù)據(jù)結(jié)構(gòu)PyThreadState，其中含有一些解釋器狀態(tài)
• 調(diào)用pthread創(chuàng)建線程
• 執(zhí)行線程函數(shù)

由于python是解釋形動(dòng)態(tài)語言，所以在實(shí)現(xiàn)線程時(shí)，需要PyThreadState結(jié)構(gòu)來保存一些信息：

• 當(dāng)前的stack frame (對(duì)python代碼)
• 當(dāng)前的遞歸深度
• 線程ID
• 可選的tracing/profiling/debugging hooks

PyThreadState是C語言實(shí)現(xiàn)的一個(gè)結(jié)構(gòu)體（摘自[2]）：

typedef struct _ts {
  struct _ts *next; # 鏈表指正
  PyInterpreterState *interp; # 解釋器狀態(tài)
  struct _frame *frame; # 當(dāng)前的stack frame
  int recursion_depth; # 當(dāng)前的遞歸深度
  int tracing;
  int use_tracing;
  Py_tracefunc c_profilefunc;
  Py_tracefunc c_tracefunc;
  PyObject *c_profileobj;
  PyObject *c_traceobj;
  PyObject *curexc_type;
  PyObject *curexc_value;
  PyObject *curexc_traceback;
  PyObject *exc_type;
  PyObject *exc_value;
  PyObject *exc_traceback;
  PyObject *dict;
  int tick_counter;
  int gilstate_counter;
  PyObject *async_exc;
  long thread_id; # 線程ID
} PyThreadState;

從目前最新的python源碼中來看，這個(gè)結(jié)構(gòu)體中的內(nèi)容已經(jīng)有所改變，但記錄解釋器狀態(tài)的指針PyInterpreterState *interp依然存在。

python解釋器實(shí)現(xiàn)時(shí)，用了一個(gè)全局變量(_PyThreadState_Current)

[https://github.com/python/cpython/blob/3.1/Python/pystate.c]（python3.1和之前的代碼中都存在，python3.2就有所不同了）

PyThreadState *_PyThreadState_Current = NULL;

_PyThreadState_Current指向當(dāng)前執(zhí)行線程的PyThreadState數(shù)據(jù)結(jié)構(gòu)。解釋器通過這個(gè)變量，來獲取當(dāng)前所執(zhí)行線程的信息。

python程序中，有一個(gè)全局解釋器鎖GIL來控制線程的執(zhí)行，每一個(gè)時(shí)刻只允許一個(gè)線程執(zhí)行。

GIL的行為

GIL最基本的行為只有下面兩個(gè)：

• 當(dāng)前執(zhí)行的線程持有GIL
• 線程遇到I/O阻塞時(shí)，會(huì)釋放GIL。（阻塞等待時(shí)，就釋放GIL，給另一個(gè)線程執(zhí)行的機(jī)會(huì)）

那么，如果遇到CPU密集型的線程，一直占用CPU，不會(huì)被I/O阻塞，是不是其它線程就沒有機(jī)會(huì)執(zhí)行了呢？

非也，為了避免這種情況，解釋器還會(huì)周期性的check并執(zhí)行線程調(diào)度。

解釋器周期性check行為，做的就是下面這3件事：

• 復(fù)位tick計(jì)數(shù)器
• 在主線程中，檢查有沒有需要處理的信號(hào)
• 讓當(dāng)前執(zhí)行線程釋放(Release)GIL，讓其他線程獲取(acquire)GIL并執(zhí)行（給其他線程執(zhí)行的機(jī)會(huì)）

而解釋器check的周期，默認(rèn)是100個(gè)tick。解釋器的tick并不是基于時(shí)間的，每個(gè)tick大致相當(dāng)于一條匯編指令的執(zhí)行時(shí)間。

從解釋器的check行為中可以看到，只有主線程中會(huì)處理信號(hào)，子線程中都不處理信號(hào)。所以python多線程程序，會(huì)給人一種無法處理Ctrl+C的假象，因?yàn)榇蟛糠智闆r下主線程被block住了，無法處理SIGINT信號(hào)。

注意python中并沒有實(shí)現(xiàn)線程調(diào)度，python的多線程調(diào)度完全依賴于操作系統(tǒng)。所以python多線程編程中沒有線程優(yōu)先級(jí)等概念。

GIL的實(shí)現(xiàn)

python的GIL并不是簡(jiǎn)單的用lock實(shí)現(xiàn)的，GIL是用signal實(shí)現(xiàn)的。

• 線程獲取(acquire)GIL前，先檢查有沒有被free，如果沒有，就sleep等待signal
• 線程釋放GIL時(shí)，還要發(fā)送signal

參考

[1] Understanding the Python GIL.  http://dabeaz.com/python/UnderstandingGIL.pdf

[2] Inside the Python GIL.  http://www.dabeaz.com/python/GIL.pdf

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。