CreateThread vs. _beginthreadex
-
I posted this question in the forums but I was trying to get a quicker response. What is the prefered method, if any, for starting a new thread from a COM object. CreateThread or _beginthreadex? I seem to remember the CreateThread was prefered but a wo-worker is argueing for _beginthreadex, which calls CreateThread anyway.
-
I posted this question in the forums but I was trying to get a quicker response. What is the prefered method, if any, for starting a new thread from a COM object. CreateThread or _beginthreadex? I seem to remember the CreateThread was prefered but a wo-worker is argueing for _beginthreadex, which calls CreateThread anyway.
beginethread If you are writing Win32-based applications using C or C++, you should create threads using the _beginthreadex function and not use CreateThread. Now Jeffrey Richter'll tell you why. MSJ July 1999 Cheers Ghazi
-
beginethread If you are writing Win32-based applications using C or C++, you should create threads using the _beginthreadex function and not use CreateThread. Now Jeffrey Richter'll tell you why. MSJ July 1999 Cheers Ghazi
Actually Jeffrey Richter's book was what the co-worker was referencing, but it also says that _beginthreadex calls CreateThread. Again I remember something about using CreateThread in COM over _beginthreadex. If _beginthreadex is better than CreateThread that raises the question of what's the reason for CreateThread in the first place.
-
Actually Jeffrey Richter's book was what the co-worker was referencing, but it also says that _beginthreadex calls CreateThread. Again I remember something about using CreateThread in COM over _beginthreadex. If _beginthreadex is better than CreateThread that raises the question of what's the reason for CreateThread in the first place.
From what I've seen/remember, _beginthreadex is the proper call. Bounds Checker used to flag warnings about resources not being freed with CreateThread (something to do with the runtime libraries) and I believe this is where this issue arises from. I ran into and read this a few years ago- I've been using _beginthreadex since. Mike
-
From what I've seen/remember, _beginthreadex is the proper call. Bounds Checker used to flag warnings about resources not being freed with CreateThread (something to do with the runtime libraries) and I believe this is where this issue arises from. I ran into and read this a few years ago- I've been using _beginthreadex since. Mike
Since you mentioned BoundsChecker, have you ever used Insure++? We were just trying to compare the two.
-
Actually Jeffrey Richter's book was what the co-worker was referencing, but it also says that _beginthreadex calls CreateThread. Again I remember something about using CreateThread in COM over _beginthreadex. If _beginthreadex is better than CreateThread that raises the question of what's the reason for CreateThread in the first place.
_beginthread is the C run time library routine which includes startup and shutdown code needed by the C run time library. CreateThread is the actual OS routine that creates the thread. Why have CreateThread, because the world doesn't revolve around 'C'. Because of some really stupid things K&R did back in the old days with such things as errno and functions which wrote to global memory, the C run time library doesn't work well in multithreaded environments. Thus the kludges to make things like errno work. These kludges require that _beginthread is invoked. Do a search of the C include files for errno. You will find that when compiled multithreaded, it is actually a function and not a variable. (Actually, to be 100% correct, _beginthread doesn't need to be called if you are linking to the DLL version of CRTL.) Tim Smith Descartes Systems Sciences, Inc.
-
Since you mentioned BoundsChecker, have you ever used Insure++? We were just trying to compare the two.
-
_beginthread is the C run time library routine which includes startup and shutdown code needed by the C run time library. CreateThread is the actual OS routine that creates the thread. Why have CreateThread, because the world doesn't revolve around 'C'. Because of some really stupid things K&R did back in the old days with such things as errno and functions which wrote to global memory, the C run time library doesn't work well in multithreaded environments. Thus the kludges to make things like errno work. These kludges require that _beginthread is invoked. Do a search of the C include files for errno. You will find that when compiled multithreaded, it is actually a function and not a variable. (Actually, to be 100% correct, _beginthread doesn't need to be called if you are linking to the DLL version of CRTL.) Tim Smith Descartes Systems Sciences, Inc.
because the world doesn't revolve around 'C':) Want to work here? Sometimes I wonder if some of the developers around here learned the alphabet beyond C.;)
-
because the world doesn't revolve around 'C':) Want to work here? Sometimes I wonder if some of the developers around here learned the alphabet beyond C.;)
-
LOL, we are a C shop too. But my point was that CreateThread was the OS method of starting a thread that EVERYONE calls sooner or later. Either directly or via a language specific routine. Tim Smith Descartes Systems Sciences, Inc.
_beginthread(ex) isn't a language specific routine, it's a library specific routine. You can also safely call CreateThread within C programs (including COM programs), you just may leak memory if you don't know precisely what you're doing. Some C routines allocate TLS data in order to make some re-entrant routines thread safe (strtok and errno are great examples of this). If you don't use _beginthread(ex) to start threads that call these routines then the TLS data *may* be leaked (the rules for when and why are too complex to give here). However, if you never call any of those routines you are sure that you won't leak and you can safely use CreateThread. One should note that MFC has the exact same issue and MFC applications should always use AfxBeginThread() instead of either _beginthread(ex) or CreateThread. William E. Kempf
-
_beginthread(ex) isn't a language specific routine, it's a library specific routine. You can also safely call CreateThread within C programs (including COM programs), you just may leak memory if you don't know precisely what you're doing. Some C routines allocate TLS data in order to make some re-entrant routines thread safe (strtok and errno are great examples of this). If you don't use _beginthread(ex) to start threads that call these routines then the TLS data *may* be leaked (the rules for when and why are too complex to give here). However, if you never call any of those routines you are sure that you won't leak and you can safely use CreateThread. One should note that MFC has the exact same issue and MFC applications should always use AfxBeginThread() instead of either _beginthread(ex) or CreateThread. William E. Kempf