PHP及Zend Engine的安全執行緒模型分析

不知道怎麼回事總是令人不舒服的，因此我通過閱讀源碼和查閱有限的資料簡要瞭解一下相關機制，本文是我對研究內容的總結。 本文首先解釋了安全執行緒的概念及PHP中安全執行緒的背景，然後詳細研究了PHP的安全執行緒機制ZTS（Zend Thread Safety）及具體的實現TSRM，研究內容包括相關資料結構、實現細節及運行機制，最後研究了Zend對於單線程和多線程環境的選擇性編譯問題。

安全執行緒
安全執行緒問題，一言以蔽之就是多線程環境下如何安全存取公用資源。我們知道，每個線程只擁有一個私人棧，共用所屬進程的堆。在C中，當一個變數被聲明在任何函數之外時，就成為一個全域變數，這時這個變數會被分配到進程的共用儲存空間，不同線程都引用同一個地址空間，因此一個線程如果修改了這個變數，就會影響到全部線程。這看似為線程共用資料提供了便利，但是PHP往往是每個線程處理一個請求，因此希望每個線程擁有一個全域變數的副本，而不希望請求間相互幹擾。 早期的PHP往往用於單線程環境，每個進程只啟動一個線程，因此不存線上程安全問題。後來出現了多線程環境下使用PHP的情境，因此Zend引入了Zend安全執行緒機制（Zend Thread Safety，簡稱ZTS）用於保證線程的安全。

ZTS的基本原理及實現
基本思想
說起來ZTS的基本思想是很直觀的，不是就是需要每個全域變數在每個線程都擁有一個副本嗎？那我就提供這樣的機制： 在多線程環境下，申請全域變數不再是簡單聲明一個變數，而是整個進程在堆上分配一塊記憶體空間用作“線程全域變數池”，在進程啟動時初始化這個記憶體池，每當有線程需要申請全域變數時，通過相應方法調用TSRM（Thread Safe Resource Manager，ZTS的具體實現）並傳遞必要的參數（如變數大小等等），TSRM負責在記憶體池中分配相應記憶體區塊並將這塊記憶體的引用標識返回，這樣下次這個線程需要讀寫此變數時，就可以通過將唯一的引用標識傳遞給TSRM，TSRM將負責真正的讀寫操作。這樣就實現了安全執行緒的全域變數。給出了ZTS原理的：
Thread1和Thread2同屬一個進程，其中各自需要一個全域變數Global Var，TSRM為兩者線上程全域記憶體池中（黃色部分）各自分配了一個地區，並且通過唯一的ID進行標識，這樣兩個線程就可以通過TSRM存取自己的變數而互不干擾。 下面通過具體的程式碼片段看一下Zend具體是如何?這個機制的。這裡我用的是PHP5.3.8的源碼。 TSRM的實現代碼在PHP源碼的“TSRM”目錄下。

資料結構
TSRM中比較重要的資料結構有兩個：tsrm_tls_entry和tsrm_resource_type。下面先看tsrm_tls_entry。 tsrm_tls_entry定義在TSRM/TSRM.c中： 複製代碼 代碼如下:typedef struct _tsrm_tls_entry tsrm_tls_entry;

struct _tsrm_tls_entry {
void **storage;
int count;
THREAD_T thread_id;
tsrm_tls_entry *next;
}

每個tsrm_tls_entry結構負責表示一個線程的所有全域變數資源，其中thread_id儲存線程ID，count記錄全域變數數，next指向下一個節點。storage可以看做指標數組，其中每個元素是一個指向本節點代表線程的一個全域變數。最終各個線程的tsrm_tls_entry被組成一個鏈表結構，並將鏈表頭指標賦值給一個全域靜態變數tsrm_tls_table。注意，因為tsrm_tls_table是一個貨真價實的全域變數，所以所有線程會共用這個變數，這就實現了線程間的記憶體管理一致性。tsrm_tls_entry和tsrm_tls_table結構的如下：
tsrm_resource_type的內部結構相對簡單一些： 複製代碼 代碼如下:typedef struct {
size_t size;
ts_allocate_ctor ctor;
ts_allocate_dtor dtor;
int done;
}

tsrm_resource_type;上文說過tsrm_tls_entry是以線程為單位的（每個線程一個節點），而tsrm_resource_type以資源（或者說全域變數）為單位，每次一個新的資源被分配時，就會建立一個tsrm_resource_type。所有tsrm_resource_type以數組（線性表）的方式組成tsrm_resource_table，其下標就是這個資源的ID。每個tsrm_resource_type儲存了此資源的大小和構造、析構方法指標。某種程度上，tsrm_resource_table可以看做是一個雜湊表，key是資源ID，value是tsrm_resource_type結構。

實現細節
這一小節分析TSRM一些演算法的實現細節。因為整個TSRM涉及代碼比較多，這裡揀其中具有代表性的兩個函數分析。 第一個值得注意的是tsrm_startup函數，這個函數在進程起始階段被sapi調用，用於初始化TSRM的環境。由於tsrm_startup略長，這裡摘錄出我認為應該注意的地方： 複製代碼 代碼如下:/* Startup TSRM (call once for the entire process) */
TSRM_API int tsrm_startup(int expected_threads, int expected_resources, int debug_level, char *debug_filename)
{
/* code... */

tsrm_tls_table_size = expected_threads;

tsrm_tls_table = (tsrm_tls_entry **) calloc(tsrm_tls_table_size, sizeof(tsrm_tls_entry *));
if (!tsrm_tls_table) {
TSRM_ERROR((TSRM_ERROR_LEVEL_ERROR, "Unable to allocate TLS table"));
return 0;
}
id_count=0;

resource_types_table_size = expected_resources;
resource_types_table = (tsrm_resource_type *) calloc(resource_types_table_size, sizeof(tsrm_resource_type));
if (!resource_types_table) {
TSRM_ERROR((TSRM_ERROR_LEVEL_ERROR, "Unable to allocate resource types table"));
free(tsrm_tls_table);
tsrm_tls_table = NULL;
return 0;
}

/* code... */

return 1;
}

其實tsrm_startup的主要任務就是初始化上文提到的兩個資料結構。第一個比較有意思的是它的前兩個參數：expected_threads和expected_resources。這兩個參數由sapi傳入，表示預計的線程數和資源數，可以看到tsrm_startup會按照這兩個參數預先分配空間（通過calloc）。因此TSRM會首先分配可容納expected_threads個線程和expected_resources個資源的。要看各個sapi預設會傳入什麼，可以看各個sapi的源碼（在sapi目錄下），我簡單看了一下：
可以看到比較常用的sapi如mod_php5、php-fpm和cgi都是預分配一個線程和一個資源，這樣是因為不願浪費記憶體空間，而且多數情況下PHP還是運行於單線程環境。 這裡還可以看到一個id_count變數，這個變數是一個全域靜態變數，其作用就是通過自增產生資源ID，這個變數在這裡被初始化為0。所以TSRM產生資源ID的方式非常簡單：就是一個整形變數的自增。 第二個需要仔細分析的就是ts_allocate_id，編寫過PHP擴充的朋友對這個函數肯定不陌生，這個函數...