_beginthreadex VS CreateThread in vc 7.1

[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

 

[Carl Daniel [VC++ MVP]]

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 ?

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

 

[William DePalo [MVP VC++]]

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 ?

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

 

[Carl Daniel [VC++ MVP]]

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.

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

 

[William DePalo [MVP VC++]]

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.

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

 

[Jan Bares]

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.

(they have different type of the start function)

Not to mension AfxBeginThread()

Jan