What is the difference between CreateThread and beginThreadex

I noticed some code examples use _beginthreadex or beginthread.
I have been using CreateThread All this time.

What is the difference between the 2 ?

Code:

---

uintptr_t _beginthread(
  void( *start_address )( void * ),
  unsigned stack_size,
  void *arglist
);
uintptr_t _beginthreadex(
  void *security,
  unsigned stack_size,
  unsigned ( *start_address )( void * ),
  void *arglist,
  unsigned initflag,
  unsigned *thrdaddr
);

And


        m_hThread = CreateThread(0,
                                  0,
                                  ThreadFunc,
                                  (void *)whatever,
                                  0,
                                  &m_dwThreadID);

---

Thanks
Stev

More or less, main difference is, that CreateThread() is closer to WinNT style of threads than _beginthread() - it allows you to provide security descriptor and other NT-specific characteristics of thread. As such, it's the "thread starter" to use e.g. in NT services (it's not true, that you can't use _beginthread() in service, but CreateThread() is safer, and typically removes some problems that might appear with _beginthread() and that are very hard to track down and debug).

_beginthreadex() is virtually the same as CreateThread() since Win2K. The difference is more or less only in the style - CreateThread() is looking more WinAPI-like (returning handle, ...), while _beginthreadex() has more "pure-C" feel to it. Of course, both are platform specific.

In an ordinary application, all three of these are typically interchangeable, unless you need stuff like higher priority or higher user rights.

One more small difference - _endthread() closes the thread handle (whereas _endthreadex() and ExitThread() does not, you have to call CloseHandle()).
For an executable file linked with LIBCMT.LIB, do not call the ExitThread(); this prevents the run-time system from reclaiming allocated resources. _endthread() and _endthreadex() reclaim allocated thread resources and then call ExitThread().

for more info, see MSDN:
_beginthread() and _beginthreadex()
CreateThread()

previous thread on this topic:
_beginthread vs CreateThread

If you read through the link that JustChecking provided, you'll notice that it is recommended to use _beginthreadex over CreateThread.

Quote:

---

Originally Posted by Arjay

If you read through the link that JustChecking provided, you'll notice that it is recommended to use _beginthreadex over CreateThread.

---

Well, i didn't want to point this out from the thread, because it's not that much true anyways...
If you look at CRT sources (file threadex.c) in VS6, 2003.NET or 2005, _beginthreadex() is internally calling CreateThread(), after it allocates "thread parameters"... but this is typically done before by user, or user doesn't need them...

Actually, IMO, CreateThread() is best suited if programming using WinAPI, while _beginthreadex() is for the rest (takes care of some stuff, that is otherwise taken care of by WinAPI)...
But, to be honest, i never really ran into any thoubles with either of them, so - it's your choice! :D

Probably the main reason for this whole mess is, that CRT just "had to exist" before WinAPI was complete, so now we have both functions, where one is using the other.

Thanks I see that kind of reference.

I found this when I searched the net

---------------

In microsoft.public.vc.mfc they could have told you that

AfxBeginThread sets up MFC stuff, then calls
_beginthreadex which sets up CRT stuff, then calls
::CreateThread, which is a Win32 API and really creates the thread.

MFC has all kinds of data structures which need to be switched on a per-
thread basis. AfxBeginThread takes care of setting this up. If you call
::CreateThread "behind the back" of MFC, things will not work.

------------------------

Stev

Here's my take on it. In MFC if you are creating a secondary UI thread, you should use AfxCreateThread. If you are creating worker threads, then use _beginthreadex. Since it is generally the accepted practice to keep all UI components in the same main thread and only spawn worker threads, prefer to use _beginthreadex. Personally, I find that using AfxCreateThread takes more work and doesn't add anything when creating worker threads.

Quote:

---

Originally Posted by JustChecking

after it allocates "thread parameters"... but this is typically done before by user, or user doesn't need them...

---

The thread params that _beginthread(ex) initializes aren't the user's data. It is the TLS data that CRT itself uses for it's multithreaded versions of the functions. Quite a few of CRT functions touch upon this TLS data. That is why it is important to use the CRT thread creation function if your thread proc happens to call CRT functions that could be thread sensitive.

Quote:

---

Originally Posted by kirants

The thread params that _beginthread(ex) initializes aren't the user's data. It is the TLS data that CRT itself uses for it's multithreaded versions of the functions. Quite a few of CRT functions touch upon this TLS data. That is why it is important to use the CRT thread creation function if your thread proc happens to call CRT functions that could be thread sensitive.

---

ohhh... thanks for pointing that out!
i never ran into any troubles with that, so never had need to dig deeper into real meaning of it, plus never saw it documented anywhere, so i expected it to be what it is typically described as in documentation...

cheers! :)

Jeffery Richter book - 'Programming Applications for Microsoft Windows' has a whole page dedicated to this. It is a good read. Basically, the reasons are same as the ones pointed to by kirants.

Plus the main MSDN entry - http://msdn2.microsoft.com/en-us/lib...cb(VS.71).aspx, has bunch of other differences between beginthread and beginthreadex (and endthread and endthrex and ExitThread - gotta remember that as well).

Quote:

---

Originally Posted by UnderDog

Jeffery Richter book - 'Programming Applications for Microsoft Windows' has a whole page dedicated to this. It is a good read. Basically, the reasons are same as the ones pointed to by kirants.

---

Thanks for pointing it out. It was refreshing to read the minute details again :) Well worth the read :thumb:

Richter is indeed da Man. :thumb: