_beginthreadex VS CreateThread in vc 7.1

  • Thread starter Thread starter Vinayak Raghuvamshi
  • Start date Start date
V

Vinayak Raghuvamshi

Threads created using the CreateThread API used to leak memory if you
accesed any crt methods within the thread proc. we used to use
_beginthread to work around this issue.

Does anyone know if this has been fixed ?

-Vinayak
 
Vinayak said:
Threads created using the CreateThread API used to leak memory if you
accesed any crt methods within the thread proc. we used to use
_beginthread to work around this issue.

Does anyone know if this has been fixed ?
Click to expand...

The situation has not changed, nor will it ever (on Win32 at least). The
problem fundamentally is that there's no way to register a fully reliable
"atexit" mechanism that always works regardless of how the process ends,
except by using a DLL.

Under VC7.1, as was the case with previous versions of VC++, if you use the
DLL version of the CRT, your resources will in fact be reclaimed when the
CRT DLL is unloaded. If you use the static CRT, unless your program shuts
down normally, CRT resources will be leaked. In practice, there's little
consequence to this, since the OS will reclaim the resources anyway. It's
possible though that unflushed I/O buffers will be lost, etc.

In any case, using _beginthread{ex} is still the recommended procedure.

-cd
 
Vinayak Raghuvamshi said:
Threads created using the CreateThread API used to leak memory if you
accesed any crt methods within the thread proc. we used to use
_beginthread to work around this issue.

Does anyone know if this has been fixed ?
Click to expand...

I think that there are other considerations besides the issue of leaks.

The C runtime dates back to the dark ages before it was common to have more
than a single thread of execution in a process. Some functions of the
runtime, like strtok(), for example use static data in non-thread-safe ways.
The runtime's thread creator - _beginthreadex() - insures that such data is
"instanced" for each thread. CreateThread(), because it is language neutral,
can't do that.

Of course those old string handling functions are not of much use in a
modern C++ application but if you use the runtime to create threads then you
don't have to worry about obscure problems in dark corners.

Regards,
Will
 
William said:
I think that there are other considerations besides the issue of
leaks.

The C runtime dates back to the dark ages before it was common to
have more than a single thread of execution in a process. Some
functions of the runtime, like strtok(), for example use static data
in non-thread-safe ways. The runtime's thread creator -
_beginthreadex() - insures that such data is "instanced" for each
thread.
Click to expand...

This instancing also happens in the CRT DLL's DllMain(DLL_THREAD_ATTACH) so
if you're using the DLL CRT you get the proper instances created even if you
use CreateThread.

-cd
 
Carl Daniel said:
This instancing also happens in the CRT DLL's DllMain(DLL_THREAD_ATTACH) so
if you're using the DLL CRT you get the proper instances created even if you
use CreateThread.
Click to expand...

Yup, it does, right where God intended DLLs to be initialized (to the extent
that DLLs are ever initialized). :-)

It is a side effect to be sure but favoring the CRT's _beginthreadex() over
Win32's CreateThread() keeps one who has to ask the question from hurting
himself. Naively, one might think that one could handle all of the (visible)
thread synchronization issues oneself and use CreateThread() with the singly
threaded version of the CRT. But unless one looks deep inside the runtime,
one can't be sure anything is safe.

I guess I have just never seen this issue as a bug but rather an issue of
misplaced expectations. Now, why there is a _beginthread() and a
_beginthreadex()? Well, that's something else. :-)

Regards,
Will
 
I guess I have just never seen this issue as a bug but rather an issue of
misplaced expectations. Now, why there is a _beginthread() and a
_beginthreadex()? Well, that's something else. :-)
Click to expand...

(they have different type of the start function)

Not to mension AfxBeginThread() :-)

Jan
 
Back
Top