_beginthreadex和CreateThread

为什么要用C运行时库的_beginthreadex代替操作系统的CreateThread来创建线程?

来源自自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。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值