4

I'm used to work with good old WinAPI call CreateThread(), and check thread's status using the waiting function, e.g WaitForSingleObject(), Once thread thread is signaled with WAIT_OBJECT_0, i close it using CloseHandle().

Recently I've decided to move to beginthread and somehow avoid the risks of uninitialized crt and accidental memory leaks that may happen.

Doing that got me confused.

  1. What's the exact purpose of endthread()? why when i call CloseHandle() in the main function, after thread's execution, CloseHandle() crashes with invalid handle?
  2. Should i ever close the handle returned by beginthread?
  3. endthread, As i understood is invoked automatically by the thread once my function goes out of scope, so should i call it anyway just before i get out of scope?
  4. According to msdn, endthread already calls CloseHandle() 1.From where does the thread obtain a reference / instance to its handle. 2. If i do insist on using endthread(), should it be the last command in the thread?

thanks

EDIT: MSDN paper describing the leaks, here.

igal k
  • 1,883
  • 2
  • 28
  • 57
  • 1
    You are free to use `CreateThread`. The dangers of uninitialized CRT were removed a long time ago. As for what's wrong with your code, only you can see it. You forgot to attach an MCVE. – David Heffernan Jul 06 '15 at 11:00
  • @DavidHeffernan So you consider an 80 byte leak acceptable do you! ;) – Jonathan Potter Jul 06 '15 at 11:05
  • @JonathanPotter I don't see why calling `CreateThread` leads to a leak. Could you enlighten me? – David Heffernan Jul 06 '15 at 11:11
  • @DavidHeffernan The MSDN page of CreateThread (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx, some lines above the Requirements section) still lists this issue (not in detail, but still). Do you have some reliable source that it´s fixed? – deviantfan Jul 06 '15 at 11:19
  • 3
    @deviantfan Hans Passant has stated it many times here. As he always says, if this issue had not been long since fixed, how could the system threadpool be accessible from MSVC? For example: http://stackoverflow.com/questions/2100589/beginthread-vs-createthread – David Heffernan Jul 06 '15 at 11:21
  • I've edited the post and attached MSDN's source – igal k Jul 06 '15 at 11:22
  • That article says: *This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.* You are worrying about a problem that does not exist. – David Heffernan Jul 06 '15 at 11:25
  • @DavidHeffernan, alright then, what about the other issues which i stated? – igal k Jul 06 '15 at 11:34
  • What issues? You can revert to your code that uses `CreateThread` and works correctly. – David Heffernan Jul 06 '15 at 11:36
  • 1
    Whichever call you choose, just don't ever use `_beginthread`, if you need to operate on the returned handle. This is fairly well explained in the documentation for [_beginthread, _beginthreadex](https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx). – IInspectable Jul 06 '15 at 11:38
  • @DavidHeffernan Leak is detailed [here](https://support.microsoft.com/en-us/kb/104641/en-us), also `signal` doesn't work. But my comment was mostly tongue-in-cheek. – Jonathan Potter Jul 06 '15 at 11:46
  • @JonathanPotter Yes, the leak is long gone. `signal`? Perhaps that still needs `_beginthreadex`. I don't know. It's a shame that MSDN doesn't clear this up once and for all. – David Heffernan Jul 06 '15 at 11:49
  • @DavidHeffernan The threadpool is an interesting issue, I hadn't thought of that. Agreed, would be nice if MSDN could clarify. – Jonathan Potter Jul 06 '15 at 11:53
  • @JonathanPotter I think Hans really is the expert here. If he says that the issues with CreateThread and the CRT are long gone, then I am inclined to trust him. – David Heffernan Jul 06 '15 at 11:55
  • 2
    The one case where per thread data can leak is an executable linked with the static version of the CRT run under Windows XP (or earlier). There's no leak with anything linked with the DLL version of the CRT, DLLs linked with the static version of the CRT, or when running under Server 2003 or Vista or newer. – Ross Ridge Jul 06 '15 at 18:29

1 Answers1

7

As stated in the comments by David Hefferman you can simply change your code back to using CreateThread. The Visual C++ runtime (CRT) will automatically initialize the CRT's per thread data the first time you use a function that uses the per thread data.

The CRT will also automatically free the per thread data when a thread ends, so using CreateThread won't cause memory leaks. There is one exception, if all of the following conditions are true then per thread data isn't automatically freed:

  • You're building an executable, not a DLL
  • You're linking against the static version of the CRT library (LIBCMT.LIB) instead of the DLL version (MSVCRT.LIB)
  • The executable you built is run under Windows XP (or an earlier version of Windows).

Note that even if all this true in your case, the memory leak isn't going to be significant unless you're creating a long lived application that creates and destroys hundreds of thousands of threads over its life time.

If you still want to use the CRTs thread creation functions (_beginthread/_beginthreadex) you should follow these guidelines:

  • Never use the handle returned by _beginthread. With _beginthread the thread handle is automatically closed when the thread exits, which can potentially happen before _beginthread even returns. You can't use it with WaitForSingleObject safely because the thread might have already exited before you call this function. If you want to use the thread handle for anything use _beginthreadex instead.
  • You should never close the handle returned by _beginthread. The CRT will do it automatically, and as described in the previous point, may do so before you have chance to.
  • You should always close the handle returned by _beginthreadex when you no longer need it. The CRT won't do this automatically for you, so it's your own responsibility.
  • Don't call _endthread or _endthreadex unless you want to quickly and abnormally terminate the thread. While the CRT will free its own per thread data, none of the C++ destructors for any of the thread's objects will be called. It behaves similarly to how _exit ends the process without calling destructors.
  • The normal means of ending a thread should be by returning from the function passed as an argument to _beginthread or _beginthreadex. This will result in C++ destructors being called as a normal part of the function return.
Ross Ridge
  • 38,414
  • 7
  • 81
  • 112