來源自自1999年7月MSJ雜志的《Win32 Q&A》欄目
你也許會說我一直用CreateThread來創建線程，一直都工作得好好的，為什么要用_beginthreadex來代替CreateThread，下面讓我來告訴你為什么。
回答一個問題可以有兩種方式，一種是簡單的，一種是復雜的。
如果你不愿意看下面的長篇大論，那我可以告訴你簡單的答案：_beginthreadex在內部調用了CreateThread，在調用之前_beginthreadex做了很多的工作，從而使得它比CreateThread更安全。
為什么我們需要兩個幾乎相同的庫來分別對待單線程和多線程程序？說起來也很簡單，兩個字——效率。讓我們從頭說起，標準CRT庫出現于1970年左右，那時，線程的概念尚未出現在任何一個操作系統上。但是，線程畢竟是出現了，那好，讓我們來看看下面這個例子，在這個例子中我們使用了CRT的全局變量 errno：
BOOL fFailure = (system("NOTEPAD.EXE README.TXT") == -1);
if (fFailure) {
switch (errno) {
case E2BIG: // Argument list or environment too big
break;
case ENOENT: // Command interpreter cannot be found
break;
case ENOEXEC: // Command interpreter has bad format
break;
case ENOMEM: // Insufficient memory to run command
break;
}
}
設想這樣的情況，當上面的代碼執行到system函數之后，if聲明之前的時候，操作系統打斷了它，而轉去執行進程中的另一個線程，而這個線程正好使用了會設置errno的某個CRT函數......于是，問題就出現了。
為了解決這個問題，每個線程需要自己的errno全局變量，而且還需要一些機制來使得它們使用它們自己的errno變量，而不是其他線程的。當然， errno只是“多線程不服癥”的其中一個受害者，其他受害者還有：_doserrno, strtok, _wcstok, strerror, _strerror, tmpnam, tmpfile, asctime, _wasctime, gmtime, _ecvt, _fcvt。
于是，為了讓C和C++程序能夠正常工作，必須創建一個數據結構，并把它與每一個線程關連起來，只有這樣才能調用CRT庫時不至于誤入“他線程家園”。
那么系統怎么知道在創建一個新線程時分配這個數據塊呢？回答是系統不知道，這一切責任都在你，只有你才能確保所有的事情正常完成。
是不是有點重任在肩的感覺？呵呵，不要緊，其你要做的和標題所說的一樣，只需要調用_beginthreadex函數即可：
unsigned long _beginthreadex(void *security,
unsigned stack_size,
unsigned (*start_address)(void *), void *arglist,
unsigned initflag, unsigned *thrdaddr);
_beginthreadex的參數列表與CreateThread一模一樣，只是參數名與類型有少許差異罷了。這是因為Microsoft覺得CRT函數不應該對Windows的數據類型有任何依賴。兩者返回的東西也是一樣的，所以即使你使用了CreateThread函數，要替換成_beginthreadex也是一件很容易的事情。
因為兩者的數據類型不完全一致，所以我們需要作一些轉換來避免編譯器的抱怨，為了簡化這項工作，你可以使用我所寫的這個宏：
typedef unsigned (__stdcall * PTHREAD_START) (void *);
#define chBEGINTHREADEX(psa, cbStack, pfnStartAddr, \ pvParam, fdwCreate, pdwThreadID) \
((HANDLE) _beginthreadex( \
(void *) (psa), \
(unsigned) (cbStack), \
(PTHREAD_START) (pfnStartAddr),\
(void *) (pvParam),\
(unsigned) (fdwCreate), \
(unsigned *) (pdwThreadID)))
注意_beginthreadex函數只存在于CRT庫的多線程版本中，如果你鏈接到了一個單線程運行時庫，鏈接器會毫不客氣地報告 “unresolved external symbol”錯誤。另外，還需要注意的是VS在創建新項目時默認選擇的是單線程庫，所以需要記得修改設置。
說了這么多，只是說了一些概念，至于_beginthreadex為什么要比CreateThread更好，還是需要事實來說話的，當然，程序員所說的事實，就是代碼了，代碼之前，了無秘密，所以下面讓我們來看看CRT庫的代碼是怎樣的。首先，自然是主角人物_beginthreadex（你可以在THREADEX.C中找到它），因為沒必要在這里重復寫出源代碼，所以我只給出偽代碼版本的_beginthreadex：
unsigned long __cdecl _beginthreadex (
void *psa,
unsigned cbStack,
unsigned (__stdcall * pfnStartAddr) (void *),
void * pvParam,
unsigned fdwCreate,
unsigned *pdwThreadID)
{
_ptiddata ptd; // Pointer to thread's data block
unsigned long thdl; // Thread's handle
// Allocate data block for the new thread
if ((ptd = calloccrt(1, sizeof(struct tiddata))) == NULL)
goto errorreturn;
// Initialize the data block
initptd(ptd);
// Save the desired thread function and the parameter
// we want it to get in the data block
ptd->_initaddr = (void *) pfnStartAddr;
ptd->_initarg = pvParam;
// Create the new thread
thdl = (unsigned long) CreateThread(psa, cbStack,_threadstartex, (PVOID) ptd, fdwCreate, pdwThreadID);
if (thdl == NULL) {
// Thread couldn't be created, cleanup and return failure
goto error_return;
}
// Create created OK, return the handle
return(thdl);
error_return:
// Error: data block or thread couldn't be created
_free_crt(ptd);
return((unsigned long)0L);
}
_beginthreadex的代碼中有幾個地方需要重點注意：
(1)首先每個線程會從CRT的堆上獲得真正屬于它自己的tiddata內存塊。 tiddata數據結構你可以在MTDLL.H中找到。傳遞給_beginthreadex的線程函數的地址被保存在tiddata內存塊中。要傳遞給該線程函數的參數也被保存在這里。_beginthreadex接下來調用CreateThread，注意，這時CreateThread在新線程中執行的并不是pfnStartAddr函數，而是一個名為_threadstartex的函數。同時，傳遞給線程函數的參數也不是pvParam，而是 tiddata結構的地址。最后，如果一切順利將返回線程句柄，如果任何一個操作失敗，將返回NULL。
現在，tiddata結構已經被分配并初始化完成，下面來看看該結構是如何關聯到線程的。這次的對象是_threadstartex，同樣也在THREADEX.C中，同樣也給出偽代碼：
static unsigned long WINAPI _threadstartex (void* ptd) {
// Note: ptd is the address of this thread's tiddata block
// Associate the tiddata block with this thread
TlsSetValue(__tlsindex, ptd);
// Save this thread ID in the tiddata block
((_ptiddata) ptd)->_tid = GetCurrentThreadId();
// Initialize floating-point support (code not shown)
// Wrap desired thread function in SEH frame to
// handle runtime errors and signal support
__try {
// Call desired thread function passing it the desired parameter
// Pass threads exit code value to _endthreadex
_endthreadex(
( (unsigned (WINAPI *)(void *))(((_ptiddata)ptd)->_initaddr) )
( ((_ptiddata)ptd)->_initarg ) ) ;
}
__except(_XcptFilter(GetExceptionCode(), GetExceptionInformation()){
// The C-Runtime's exception handler deals with runtime errors
// and signal support, we should never get it here.
_exit(GetExceptionCode());
}
// We never get here, the thread dies in this function
return(0L);
}
_threadstartex同樣也有一些東西需要我們注意。新線程開始時會執行BaseThreadStart（位于Kernel32.DLL 中），然后跳到_threadstartex。_threadstartex的唯一參數就是新線程的tiddata內存塊地址。TlsSetValue完成了將tiddata結構與線程關聯起來的目的（這里的tiddata結構被稱為線程本地存儲，TLS，顧名思義，就是屬于每個線程自己的數據）。
在事實上的線程函數周圍放置了一個結構化異常處理體（A structured exception handling frame）。這個處理體主要負責處理與運行時庫有關的很多東西，比如運行時錯誤（像拋出但卻沒有被捕獲的C++異常這類東西）和CRT的signal函數。這很重要，如果你使用CreateThread創建了線程，然后又調用了CRT的signal函數，那么signal函數將無法正常工作。
注意，這時還不能返回到BaseThreadStart，如果這樣做，線程會死掉，退出碼會正常設置，但tiddata內存塊不會被銷毀，這就會造成內存泄漏。為了防止泄漏，需要調用_endthreadex，并且將退出碼傳遞給它。
_endthreadex同樣也在THREADEX.C中，同樣也給出偽代碼：
void __cdecl _endthreadex (unsigned retcode) {
_ptiddata ptd; // Pointer to thread's data block
// Cleanup floating-point support (code not shown)
// Get the address of this thread's tiddata block
ptd = _getptd();
// Free the tiddata block
_freeptd(ptd);
// Terminate the thread
ExitThread(retcode);
}
注意CRT的_getptd函數在內部調用了系統的TlsGetValue函數來獲取對應線程的tiddata內存塊地址，然后釋放該內存塊，最后調用ExitThread來真正銷毀線程，當然是用上面所提到的退出碼來調用。
我強烈建議你絕不要調用ExitThread來中止你的線程。最好也是最簡單的辦法就是讓線程自己返回即可，讓它自生自滅。ExitThread不僅徒增復雜，而且還會造成tiddata內存塊泄漏。
Microsoft Visual C++項目組發現人們總是喜歡調用ExitThread，他們希望能盡可能的做到讓程序不泄漏內存。所以如果你真的想要明確地退出線程，你也最好使用_endthreadex，雖然這也不太好。
OK，目前為止你應該對誰更好些的問題有了深入的了解，但是為什么調用CreateThread的程序仍然可以經年累月的正常運行呢？當線程調用一個需要 tiddata結構的CRT函數時（大多數CRT函數是線程安全的，并不需要該結構），首先CRT函數試圖獲取線程的數據塊的地址（通過調用 TlsGetValue），然后，如果返回NULL，說明調用線程沒有相關聯的tiddata塊，那么CRT函數馬上為調用線程分配并初始化一個 tiddata塊，并將該內存塊關聯到線程（通過TlsSetValue），這樣，該CRT函數以及其他CRT函數都可以使用該線程的tiddata塊了（此即所謂“前人栽樹后人乘涼”了，^_^）。
當然，如果說你的線程運行的時候一直沒有問題是幾乎不可能的。事實上，的確有一些問題需要說說。如果線程使用了CRT的signal函數，整個進程都會被中止，因為結構化異常處理體尚未準備好。同樣，如果不調用_endthreadex來中止線程就會造成內存泄漏，如果使用_beginthreadex，當然會容易想到_endthreadex，但如果你習慣了使用CreateThread，是否還會想起_endthreadex，我表示極大的懷疑，而且CreateThread/_endthreadex的組合怎么看怎么讓人別扭。
不要忘記開始的問題，接下來讓我們再來看看效率問題。CRT庫的多線程版本在某些函數里面放置了同步原語，比如malloc，為了保證堆不會被同時調用的 malloc函數破壞，這不可避免地會對效率造成影響，C/C++的哲學我們不應忘記，“決不為自己沒有用到的付出代價”，自然，我們無權要求單線程程序為多線程程序付出它們不該付出的代價，所以，開頭的問題也有了答案。
上面所說的都是靜態鏈接的CRT庫，而CRT庫的動態鏈接版本則被編寫得更加通用，以便能夠被任何運行的程序和DLL共享。正是基于這個原因，這個版本的庫只存在多線程版本。因為CRT庫是以DLL形式提供的，程序和DLL不需要包含CRT庫的任何代碼，自然尺寸也就更小。同時，如果Microsoft修正了CRT庫DLL中的Bug，程序也就自然受益了。
終于該結束了，還是來幾句總結吧：首先，如果你調用_beginthreadex，你會獲得線程的句柄，句柄當然需要關閉，但_endthreadex并沒有這么做。通常是調用_beginthreadex的線程（很可能是主線程）來調用CloseHandle關閉不再需要的新線程的句柄。其次，如果你使用CRT函數，你只需要使用_beginthreadex即可。如果不使用，那么你可以只使用CreateThread。同樣，如果只有一個線程（主線程）使用 CRT，你也可以使用CreateThread；如果新創建的線程不使用CRT，那么你也不需要_beginthreadex和多線程CRT。