Of course anything can be dangerous if you just blindly toss api function calls at your program with no thought.
Well, he's "blind" and has no thought, because he's a complete rookie with multithreading. How is he supposed to know this fact? Which is why I warned him about it.CreateThread() works great in multithreaded environments. I have used it many many times over the past 10 years in MFC programs with Visual Studio compilers. There has never ever been a problem with it.
You've been doing it wrong for about 10 years. A program doesn't crash doesn't mean it's working "great".
Win32 Q&A (Microsoft systems journal), July 1999:
An enquirer:I have been writing Win32®-based applications for years now and have always created my threads by calling the CreateThread function. Recently a coworker told me that I should not call CreateThread, but to use _beginthreadex instead. So far my apps have all worked just fine with CreateThread. Can you explain what all this is about?
Jeffrey Richter: Well, first, I must tell you that your coworker is correct. If you are writing Win32-based applications using C or C++, you should create threads using the _beginthreadex function and not use CreateThread.
Link to the Q&A: http://www.microsoft.com/msj/0799/Win32/Win320799.aspx
Take a look at the Remarks section of the documentation for CWinThread .
MFC maintains per thread handle maps, and it relies totally on calls to the MFC thread functions to do it correctly. By not using the MFC thread functions and calling something like CreateThread(), this mechanism is totally bypassed! While you will get away if not using MFC functions within the thread, if you have call an MFC function within the thread in the future, you've opened up a new fatal bug introduced by a call to CreateThread(). Simply by choosing the right call, you can totally avoid this.
You could verify all this by viewing the MFC source code. Explaining this in great detail here is impossible. I don't feel like doing it to prove it to somebody. Check with Windows via C/C++, in which Jeffrey Richter has explained this in great detail and you'll know who of us is right on this.
I'm not sure that is even relevant to the issue. Why would I want to initialize the CRT just to do some number crunching in another thread? The CRT has already been initialized on program startup by the main thread.
This is just crude! If the program was using the single threaded version of the CRT (the program would have compiled, because a call to CreateThread was made instead of _beginthreadex and the compiler couldn't stop you). Now the thread is going to mess up the CRT in ways you least expect. But, a call to _beginthreadex instead of CreateThread will take care of this! It's also explained in the Microsoft Win32 Q&A I linked you to earlier.It depends -- CreateThread() works ok in MFC if the new thread will not be interacting with MFC objects, such as the new thread can not create new MFC windows.
That's an extremely hideous programming practice - to call CreateThread() and to remember all the time not to call MFC functions within the thread function. When AfxBeginThread is the correct way to do it, I see absolutely no reason to CreateThread while using MFC - not to mention you'll bypass the entire MFC mechanism which sets up and manage the internal states of each different thread.
I have no desire to continue this conversation for argument's sake. I've written all this for the benefit of the OP, who is a newbie. And if you still think it's a great idea to use CreateThread in an MFC program and and suggest it to a noob as well, you may check this up: The n Habits of Highly Defective Programs , refer to books - Windows via C/C++ and Windows Internals. All of them have discussed my points in detail.