今日得到： 三人行，必有我師焉，擇其善者而從之，其不善者而改之。
現在已經是2020年了，而在2010年的時候，大佬David Beazley就做了講座講解Python GIL的設計相關問題，10年間相信也在不斷改善和優化，但是並沒有將GIL從CPython中移除，可想而知，GIL已經深入CPython，難以移除。就目前來看，工作中常用的還是協程，多線程來處理高併發的I/O密集型任務。CPU密集型的大型計算可以用其他語言來實現。
1. GIL
In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.) —– Global Interpreter Lock
為了防止多線程共享內存出現競態問題，設置的防止多線程併發執行機器碼的一個Mutex。
2. python32 之前-基於opcode數量的調度方式
在python3.2版本之前，定義了一個tick計數器，表示當前線程在釋放gil之前連續執行的多少個字節碼(實際上有部分執行較快的字節碼並不會被計入計數器)。如果當前的線程正在執行一個 CPU 密集型的任務, 它會在 tick 計數器到達 100 之後就釋放 gil, 給其他線程一個獲得 gil 的機會。
(圖片來自 Understanding the Python GIL(youtube))
以opcode個數為基準來計數，如果有些opcode代碼複雜耗時較長，一些耗時較短，會導致同樣的100個tick，一些線程的執行時間總是執行的比另一些長。是不公平的調度策略。
（圖片來自Understanding-the-python-gil）
如果當前的線程正在執行一個 IO密集型的 的任務, 你執行 sleep/recv/send(...etc) 這些會阻塞的系統調用時, 即使 tick 計數器的值還沒到 100, gil 也會被主動地釋放。至於下次該執行哪一個線程這個是操作系統層面的，線程調度算法優先級調度，開發者沒辦法控制。
在多核機器上, 如果兩個線程都在執行 CPU 密集型的任務, 操作系統有可能讓這兩個線程在不同的核心上運行, 也許會出現以下的情況, 當一個擁有了 gil 的線程在一個核心上執行 100 次 tick 的過程中, 在另一個核心上運行的線程頻繁的進行搶佔 gil, 搶佔失敗的循環, 導致 CPU 瞎忙影響性能。 如下圖：綠色部分表示該線程在運行，且在執行有用的計算，紅色部分為線程被調度喚醒，但是無法獲取GIL導致無法進行有效運算等待的時間。
由圖可見，GIL的存在導致多線程無法很好的利用多核CPU的併發處理能力。
3. python3.2 之後-基於時間片的切換
由於在多核機器下可能導致性能下降， gil的實現在python3.2之後做了一些優化 。python在初始化解釋器的時候就會初始化一個gil，並設置一個DEFAULT_INTERVAL=5000, 單位是微妙，即0.005秒(在 C 裏面是用 微秒 為單位存儲, 在 python 解釋器中以秒來表示)這個間隔就是GIL切換的標誌。
// Python\ceval_gil.h
#define DEFAULT_INTERVAL 5000
static void _gil_initialize(struct _gil_runtime_state *gil)
{
_Py_atomic_int uninitialized = {-1};
gil->locked = uninitialized;
gil->interval = DEFAULT_INTERVAL;
}
python中查看gil切換的時間
In [7]: import sys
In [8]: sys.getswitchinterval()
Out[8]: 0.005
如果當前有不止一個線程, 當前等待 gil 的線程在超過一定時間的等待后, 會把全局變量 gil_drop_request 的值設置為 1, 之後繼續等待相同的時間, 這時擁有 gil 的線程看到了 gil_drop_request 變為 1, 就會主動釋放 gil 並通過 condition variable 通知到在等待中的線程, 第一個被喚醒的等待中的線程會搶到 gil 並執行相應的任務, 將gil_drop_request設置為1的線程不一定能搶到gil
4 condition variable相關字段
- locked ： locked 的類型是
_Py_atomic_int， 值-1表示還未初始化，0表示當前的gil處於釋放狀態，1表示某個線程已經佔用了gil，這個值的類型設置為原子類型之後在 ceval.c 就可以不加鎖的對這個值進行讀取。
- interval：是線程在設置
gil_drop_request這個變量之前需要等待的時長，默認是5000毫秒
- last_holder：存放了最後一個持有 gil 的線程的 C 中對應的 PyThreadState 結構的指針地址, 通過這個值我們可以知道當前線程釋放了 gil 后, 是否有其他線程獲得了 gil(可以採取措施避免被自己重新獲得)
- switch_number： 是一個計數器, 表示從解釋器運行到現在, gil 總共被釋放獲得多少次
- mutex：是一把互斥鎖, 用來保護
locked, last_holder, switch_number 還有 _gil_runtime_state 中的其他變量
- cond：是一個 condition variable, 和 mutex 結合起來一起使用, 當前線程釋放 gil 時用來給其他等待中的線程發送信號
- ** switch_cond and switch_mutex**
switch_cond 是另一個 condition variable, 和 switch_mutex 結合起來可以用來保證釋放后重新獲得 gil 的線程不是同一個前面釋放 gil 的線程, 避免 gil 切換時線程未切換浪費 cpu 時間
這個功能如果編譯時未定義 FORCE_SWITCHING 則不開啟
static void
drop_gil(struct _ceval_runtime_state *ceval, PyThreadState *tstate)
{
...
#ifdef FORCE_SWITCHING
if (_Py_atomic_load_relaxed(&ceval->gil_drop_request) && tstate != NULL) {
MUTEX_LOCK(gil->switch_mutex);
/* Not switched yet => wait */
if (((PyThreadState*)_Py_atomic_load_relaxed(&gil->last_holder)) == tstate)
{
/* 如果 last_holder 是當前線程, 釋放 switch_mutex 這把互斥鎖, 等待 switch_cond 這個條件變量的信號 */
RESET_GIL_DROP_REQUEST(ceval);
/* NOTE: if COND_WAIT does not atomically start waiting when
releasing the mutex, another thread can run through, take
the GIL and drop it again, and reset the condition
before we even had a chance to wait for it. */
/* 注意, 如果 COND_WAIT 不在互斥鎖釋放后原子的啟動,
另一個線程有可能會在這中間拿到 gil 並釋放,
'並且重置這個條件變量, 這個過程發生在了 COND_WAIT 之前 */
COND_WAIT(gil->switch_cond, gil->switch_mutex);
}
MUTEX_UNLOCK(gil->switch_mutex);
}
#endif
}
4. gil在main_loop中的體現
//
main_loop:
for (;;) {
/* 如果 gil_drop_request 被其他線程設置為 1 */
/* 給其他線程一個獲得 gil 的機會 */
if (_Py_atomic_load_relaxed(&ceval->gil_drop_request)) {
/* Give another thread a chance */
if (_PyThreadState_Swap(&runtime->gilstate, NULL) != tstate) {
Py_FatalError("ceval: tstate mix-up");
}
drop_gil(ceval, tstate);
/* Other threads may run now */
take_gil(ceval, tstate);
/* Check if we should make a quick exit. */
exit_thread_if_finalizing(runtime, tstate);
if (_PyThreadState_Swap(&runtime->gilstate, tstate) != NULL) {
Py_FatalError("ceval: orphan tstate");
}
}
/* Check for asynchronous exceptions. */
/* 忽略 */
fast_next_opcode:
switch (opcode) {
case TARGET(NOP): {
FAST_DISPATCH();
}
/* 忽略 */
case TARGET(UNARY_POSITIVE): {
PyObject *value = TOP();
PyObject *res = PyNumber_Positive(value);
Py_DECREF(value);
SET_TOP(res);
if (res == NULL)
goto error;
DISPATCH();
}
/* 忽略 */
}
/* 忽略 */
}
這個很大的 for loop 會按順序逐個的加載 opcode, 並委派給中間很大的 switch statement 去進行執行, switch statement 會根據不同的 opcode 跳轉到不同的位置執行
for loop在開始位置會檢查 gil_drop_request變量, 必要的時候會釋放 gil
不是所有的 opcode 執行之前都會檢查 gil_drop_request 的, 有一些 opcode 結束時的代碼為 FAST_DISPATCH(), 這部分 opcode 會直接跳轉到下一個 opcode 對應的代碼的部分進行執行
而另一些 DISPATCH() 結尾的作用和 continue 類似, 會跳轉到 for loop 頂端, 重新檢測 gil_drop_request, 必要時釋放 gil 。
5 如何解決GIL
GIL只會對CPU密集型的程序產生影響，規避GIL限制主要有兩種常用策略：一是使用多進程，二是使用C語言擴展，把計算密集型的任務轉移到C語言中，使其獨立於Python，在C代碼中釋放GIL。當然也可以使用其他語言編譯的解釋器如 Jpython、PyPy。
6.總結
- Python語言和GIL沒有半毛錢關係，僅僅是由於歷史原因在CPython解釋器中難以移除GIL
- GIL：全局解釋器鎖，每個線程在執行的過程都需要先獲取GIL，確保同一時刻僅有一個線程執行代碼，所以python的線程無法利用多核。
- 線程在I/O操作等可能引起阻塞的system call之前，可以暫時釋放GIL，執行完畢后重新獲取GIL，python3.2以後使用時間片來切換線程，時間閾值是0.005秒，而python3.2之前是使用opcode執行的數量(tick=100)來切換的。
- Python的多線程在多核CPU上，只對於IO密集型計算產生正面效果；而當有至少有一個CPU密集型線程存在，那麼多線程效率會由於GIL而大幅下降
參考
Cpython-gil講解-zpoint
Python的GIL是什麼鬼-盧鈞軼(cenalulu)
Youtube-Understanding the Python GIL
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※想知道最厲害的網頁設計公司"嚨底家"!
※別再煩惱如何寫文案,掌握八大原則!
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※回頭車貨運收費標準
※台中搬家公司費用怎麼算?
