Does the improper use of createthread cause internal leakage? Createthread and _ beginthreadex are different.

Http://www.cnblogs.com/lgxqf/archive/2009/02/10/1387480.html

InWin32 APIThe basic function for creating a thread isCreatethread, And_ Beginthread (Ex)Yes
C ++Function of the running database. Why are there two? BecauseC ++Some functions in the Runtime Library use the global
Quantity, if you useCreatethreadUse theseC ++When you run the database functions, security issues may occur.
. While_ BeginthreadexProcesses these global variables so that each thread has an independent
Of"Global"Quantity.

Therefore, if your program only callsWin32 API/SDK, You can use it with confidence.CreatethreadIf you want to use
C ++Run Time library, you must use_ BeginthreadexAnd selectUse
Multithread lib/DLL.

C ++The runtime database has two functions for creating threads, and the other is_ Beginthread, Please
View by yourselfMsdn:

Generally, their explanation is that this may cause memory leakage. This explanation is correct, but it is not fully explained. Fine. So that many new users blindly trust that sentence, where it is used_ BeginthreadexFunction, or pretend not to see the useCreatethreadFunction. Once For a while, I am also confused about this problem. I don't know which one is right. Because more than once I have been in a lot of authoritativeCodeSeeCreatethreadDirectly call a function. Isn't it Is the Authority wrong ?? With a skeptical attitude, I found a lot of materials and books and finally figured out the key to this problem. Here I would like to explain it as a perfect example.

About _ Beginthreadex And Createthread I will not explain the difference.   Easy to find. We only need to know one problem: _ Beginthreadex Is C Functions of the Runtime library, Createthread Is a system API Letter   Number, _ Beginthreadex Internal call Createthread . Only because all books emphasize the memory leakage problem _ Beginthreadex Function Creation   A heap structure is allocated during thread creation and associated with the thread itself. We call this structure Tiddata Structure, is through the Thread Local Memory TLS Associated with the thread itself. The   The thread entry function is saved in this structure. Tiddata In addition to saving the thread function entry address : C Some functions in the Runtime Library need to use this structure   Save and obtain some data, such Errno Global variables of threads. This is the most important thing.

When a thread calls a requestTiddataWhen the database function is used to run the structure, the following situations occur:

Runtime Library Function attemptsTlsgetvAlueObtain the address of the thread data block. if the address is not obtained, the function will Allocate one on-siteTiddataStructure, and associated with the thread, so the problem occurs, if not passed_ EndthreadexIf the function is used to terminate the thread, the structure will not be abolished, and memory leakage will occur. Now. But in general, we do not recommend_ EndthreadexFunction to end the thread, because it containsExitthreadCall.

Find out the specific cause of Memory leakage, we can say: as long as there are no requirements in the created threadTiddataStructure of the Runtime library function, our memory is safe. Therefore, the above sentence should be completed in this way:

"Never call the built-inCreatethreadFunction to create a new thread, instead of using_ BeginthreadexUnless you do not need it in your threadTiddataStructure Runtime library functions"

This needTiddataThe structure function is a little troublesome 《Win32MultithreadingProgramDesign:

"If you perform operations in any thread except the main thread, you should use the multi-threaded versionC Runtime library,And use_ BeginthreadexAnd_ Endthreadex:

1UseMalloc ()AndFree (), OrNewAndDelete

2UseStdio. hOrIo. hAny function declared in

3Use floating-point variables or floating-point functions

4Call anyRuntimeFunction, such: Asctime (), strtok ()OrRand ()

 

Addition info please refer

Http://support.microsoft.com/kb/104641/en-us

The http://msdn.microsoft.com/en-us/library/ms682453 (vs.85). aspx