向高手學習：Glib如何來封裝跨平臺的線程庫
- 一、前言
- 二、glib 簡介
- 三、線程庫的設計
- 四、總結
一、前言
這篇文章，按照下面這 2 張圖，來描述 glib 在 Linux 和 Windows 平臺上，是如何來進行線程庫的設計的。
Linux 平臺：
Windows 平臺：
最近寫了幾篇關于跨平臺的應用程序設計思路，有些小伙伴在后臺留言詢問關于一些通用的跨平臺庫，看來這方面的需求還是很多的。
所謂的跨平臺，無非就是希望用同一份應用程序的代碼，可以編譯出在多個平臺上運行的可執行程序。
那么如何才能做到應用程序代碼的平臺無關呢?很明顯需要中間的一個橋接層，把自己不想處理的、那些與平臺相關的、煩人的代碼丟給這個中間層去處理。
簡單的說：就是那些需要處理與平臺相關的臟活、累活，都由這個中間層幫你做好了，我們在寫應用程序時，只需要關心自己的業務層事務就可以了。
如果沒有這個中間層的話，你的代碼中可能會充斥著大量的#if...#else代碼。
而 glib 就是這樣的一個中間層跨平臺庫，它提供了很多常用的封裝，線程庫只是其中的封裝之一，這篇文章我們主要來學習一下 glib 是如何來設計跨平臺的線程庫。
二、glib 簡介
第一眼看上去的時候，很容易把 glib 與 glibc 混淆，它倆都是基于 GPL 的開源軟件，但是卻屬于完全不同的概念。
glibc是GNU實現的一套標準C的函數庫，而glib是gtk+的一套函數庫。
那么 gtk+ 是什么呢?使用 Linux 的小伙伴一定知道 gnome 這個桌面環境，gnome 就是基于 gtk+ 開發的一套桌面系統，而 glib 就是位于 gtk 后面的那位無名英雄。
glib可以在多個平臺下使用，比如Linux、Unix、Windows等。glib為許多標準的、常用的 C 語言結構提供了相應的替代物。
作為一名 C 語言開發者，有時候我們會非常的羨慕 C++ 開發者，標準庫(SDL)有辣么多的工具可用：鏈表、向量、字符串處理。。。
可是 C 語言里呢?哪哪都要自己去實現這些輪子。
不過反過來說，如果我們在日常的開發過程中，把自己編寫的、從別處借鑒的那些好用的輪子都積累起來，形成自己的“寶庫”，這也是一種經驗的體現、也是一種競爭力。
如今，在 github 上也有很多雷鋒實現了高質量的 C 庫：有專注于跨平臺的、有專注于某個領域的(比如：網絡處理、格式化文本解析)。
glib 在解決跨平臺的同時，也提供了其他很多有用的工具箱，例如：事件循環、線程池、同步隊列、內存管理等等。
既然它提供的功能多，那么必然會導致體積比較大。這也是很多開發者面對不同的選擇時，放棄 glib 的原因。
不管如何，既然 glib 這么厲害，我們可以來學習它的設計思想，這可是比盲目的敲幾千行代碼更能提升一個人的元技能!
三、線程庫的設計
1. 線程相關的文件
在 Linux 系統中，創建線程一般都是通過 POSIX 接口(可移植操作系統接口)，例如：創建線程 API 函數是 pthread_create(...)。
在 Windows 系統中，創建線程有好幾種方式：
- CreateThread()
- _beginthread()
既然 glib 庫時專門用來解決跨平臺問題的，那么它向上面對應用層程序時，一定是提供一個統一的接口;而向下面對不同的操作系統時，調用不同系統中的線程函數。
glib 把這些線程相關的操作分別封裝在了平臺相關的代碼中，具體來說如下圖：
- Linux 系統：gthread.c, gthread_posix.c 參與編譯，生成 glib 庫;
- Windows 系統：gthread.c, gthread_win32.c 參與編譯，生成 glib 庫;
關于這種跨平臺的文件構建方式(也就是編譯啦)，建議您看一下這篇小短文：跨平臺代碼的3種組織方式
2. 數據結構
你一定聽說過這個公式：程序 = 數據結構 + 算法，對于一個 C 語言項目，明白了數據結構的設計，對于理解整個程序的思路是非常重要的，在 glib 中也是如此。
glib 在設計線程庫的時候，分成 2 個層次：平臺無關部分，平臺相關部分。
平臺無關的數據結構有(一些不影響理解的代碼就刪掉了)：
- struct _GThread
- {
- GThreadFunc func;
- gpointer data;
- gboolean joinable;
- };
- typedef struct _GThread GThread;
- struct _GRealThread
- {
- GThread thread;
- gint ref_count;
- gchar *name;
- };
- typedef struct _GRealThread GRealThread;
平臺相關的數據結構有:
Linux 系統：
- typedef struct
- {
- GRealThread thread;
- pthread_t system_thread;
- gboolean joined;
- GMutex lock;
- void *(*proxy) (void *);
- const GThreadSchedulerSettings *scheduler_settings;
- } GThreadPosix;
Windows 系統：
- typedef struct
- {
- GRealThread thread;
- GThreadFunc proxy;
- HANDLE handle;
- } GThreadWin32;
仔細看一下每個結構體的第一個成員變量，是不是發現點什么?
從層次關系上看，這幾個結構體的關系為：
Linux 平臺:
Windows 平臺：
結構體在內存模型中意味著什么?占據一塊內存空間。
而這幾個數據結構都把"子"結構體，放在"父"結構體的第一個位置，就可以方便的進行強制類型轉換。
在以上內存模型中，GRealThread 結構體的第一部分是 GThread，那么就完全可以把 GRealThread 所處內存的開始部分，當做一個 GThread 結構體變量來操作。
用 C++ 中面向對象的術語來描述更準確：基類指針可以指向派生類對象。
在下面的代碼中，可以看到這樣的操作。
3. 線程的創建
(1) 函數原型
平臺無關函數(gthread.c 中實現)
- GThread *g_thread_new (const gchar *name,
- GThreadFunc func,
- gpointer data);
- GThread *
- g_thread_new_internal (const gchar *name,
- GThreadFunc proxy,
- GThreadFunc func,
- gpointer data,
- gsize stack_size,
- const GThreadSchedulerSettings *scheduler_settings,
- GError **error);
平臺相關函數(gthread_posix.c or ghread_win32.c 中實現)
- GRealThread *
- g_system_thread_new (GThreadFunc proxy,
- gulong stack_size,
- const GThreadSchedulerSettings *scheduler_settings,
- const char *name,
- GThreadFunc func,
- gpointer data,
- GError **error);
(2) Linux 平臺函數調用鏈
先來看一下 Linux 平臺上的函數調用關系：
如果你的手邊有源代碼，請關注 g_thread_new() 這個函數中的 func 和 data 這2個參數。
func 是最開始用戶層傳入的線程執行函數，也就是用戶創建這個線程，最終想執行的函數。data 是 func 函數所接收的函數參數。
如果直接面對 Linux 操作系統編程，在調用 POSIX 接口函數 pthread_create() 時，一般是直接傳入用戶想要執行的函數以及參數。
但是 glib 層并沒有直接把用戶層的函數直接交給 Linux 操作系統，而是自己提供了 2 個線程代理函數，在調用 pthread_create() 時，根據不同的情況，把這2個代理函數之一傳遞給操作系統：
第一個線程代理函數：g_thread_proxy();
第二個線程代理函數：linux_pthread_proxy();
至于傳遞哪一個代理函數，取決于宏定義 HAVE_SYS_SCHED_GETATTR 是否有效。
下面是 g_system_thread_new() 函數簡化后的代碼：
- g_system_thread_new (proxy, stack_size, scheduler_settings,
- name, func, data, error);
- GThreadPosix *thread;
- GRealThread *base_thread;
- // 填充 base_thread 字段，重點關注下面2句
- base_thread->thread.func = func;
- base_thread->thread.data = data;
- thread->scheduler_settings = scheduler_settings;
- thread->proxy = proxy;
- #if defined(HAVE_SYS_SCHED_GETATTR)
- ret = pthread_create (&thread->system_thread, &attr, linux_pthread_proxy, thread);
- #else
- ret = pthread_create (&thread->system_thread, &attr, (void* (*)(void*))proxy, thread);
- #endif
4. 線程的執行
我們就假設這個宏定義 HAVE_SYS_SCHED_GETATTR 被定義了、是有效的，Linux 系統中的 pthread_create() 接收到 linux_pthread_proxy() 函數。
當這個新建的線程被調度執行時，linux_pthread_proxy() 函數被調用執行：
簡化后的 linux_pthread_proxy() 函數：
- static void *
- linux_pthread_proxy (void *data)
- {
- // data 就是 g_system_thread_new 中 GThreadPosix 類型指針，這是平臺相關的。
- GThreadPosix *thread = data;
- if (thread->scheduler_settings)
- {
- // 設置線程屬性
- tid = (pid_t) syscall (SYS_gettid);
- res = syscall (SYS_sched_setattr, tid, thread->scheduler_settings->attr, flags);
- }
- // 調用 glib 中的線程代理函數，其實就是 g_thread_proxy()
- return thread->proxy (data);
- }
這個函數關注 3 點：
- data 參數: 就是 g_system_thread_new 函數中的GThreadPosix類型指針，這是平臺相關的。
- 中間部分是設置線程屬性;
- 最后的 return 語句，調用了 glib 中第一個線程代理函數 g_thread_proxy。
繼續貼一下這個函數的簡化后代碼：
- gpointer
- g_thread_proxy (gpointer data)
- {
- // data 就是 g_system_thread_new 中 GThreadPosix 類型指針，這是平臺相關的。
- // 這里把它強轉成平臺無關的 GRealThread 類型。
- GRealThread* thread = data;
- if (thread->name)
- {
- // 設置線程屬性：名稱
- g_system_thread_set_name (thread->name);
- }
- // 調用應用層的線程入口函數
- thread->retval = thread->thread.func (thread->thread.data);
- return NULL;
- }
這個函數也只要關注 3 點：
- data 參數: linux_pthread_proxy 函數傳過來的是 GThreadPosix 類型指針，但是這里直接賦值給了 GRealThread 類型的指針，因為它們的內存模型是包含的關系;
- 中間部分是設置線程名稱;
- 最后的 thread->thread.func (thread->thread.data) 語句，調用了用戶最開始傳入的函數并傳遞用戶的 data 參數。
至此，用戶層定義的線程函數 user_thread_func(data) 就得以執行了。
那么，如果 glib 層沒有定義宏 HAVE_SYS_SCHED_GETATTR，那么 Linux 系統中 pthread_create() 接收到的就是 glib 中的第一個線程代理函數 g_thread_proxy。
線程執行的調用關系為：
5. Windows平臺函數調用鏈
先來看一下 Windows 平臺上創建線程時函數調用關系：
在 Windows 平臺上，glib 的線程代理函數是 g_thread_win32_proxy()。
當這個新建的線程被調度執行時，函數調用關系是：
四、總結
實現這樣的線程函數代理設計，關鍵是利用了 C 語言中的結構體類型中，把“父”結構體類型變量強制轉換成“子”結構體類型變量來使用，因為它倆在內存模型中，剛開始部分的空間中，內容是完全一樣的。
最后，我把文中的這些圖合并起來，繪制成下面這 2 張圖，完整的體現了 glib 中的線程設計思路：
Linux 平臺：
Windows 平臺：
本文轉載自微信公眾號「IOT物聯網小鎮」，可以通過以下二維碼關注。轉載本文請聯系IOT物聯網小鎮公眾號。
