How to create threads in VC++

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Pugal - 07 Jul 2006 06:24 GMT

Hi

is it any build in class that used for creation of threads in VC++, is it
is possible to do it in C++ using APIs..

Thanks in advance..

-Pugal.G

Reply to this Message

Jochen Kalmbach [MVP] - 07 Jul 2006 07:00 GMT

Hi Pugal!

> is it any build in class that used for creation of threads in VC++, is it
> is possible to do it in C++ using APIs..

WinAPI: CreateThread
CRT: _beginthread(ex)
MFC: AfxBeginThread
.NET: new Thread(new ThreadStart(ThreadProc));

Greetings
Jochen

PS: WinAPI also supports fibers!

Reply to this Message

Bruno van Dooren - 07 Jul 2006 07:03 GMT

> is it any build in class that used for creation of threads in VC++, is
> it
> is possible to do it in C++ using APIs..

you can use _beginthreadex to do that.
Do not use CreateThread. it is not safe.

<quote from http://www.microsoft.com/msj/0797/multithreading.aspx >
Finally, beginthreadex does some thread local storage initialization so you
can use the multithreaded C runtime library functions. CreateThread doesn't
and is, therefore, incompatible with C runtime calls.
</quote>

Or if you use MFC you could use CWinThread.
With .NET you can use the Thread class.

Signature

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Reply to this Message

Jochen Kalmbach [MVP] - 07 Jul 2006 07:57 GMT

Hi Bruno!

> you can use _beginthreadex to do that.
> Do not use CreateThread. it is not safe.
[quoted text clipped - 4 lines]
> and is, therefore, incompatible with C runtime calls.
> </quote>

This is not true... The problem is *not* the initialization of the TLS
for the CRT, the problem is just the freeing of this TLS in the
"wrapper" around your thread function, if you use _beginthread(ex).

TLS will be initialized the first time a CRT-function (which uses TLS)
is called from a thread, which was not yet initialized. SO
initialization will occur correctly, even if you have used CreateThread.

And this will also never change in the CRT, because there are many
situations in which you have *no* control over the thread-creation (for
example "multithreaded COM").

The problem is just the release of TLS after the thread is not used
anymore. A safe solution is to call "_endthread" even if you have
created the thread with "CreateThread".

Greetings
Jochen

Reply to this Message

Bruno van Dooren - 07 Jul 2006 08:43 GMT

> The problem is just the release of TLS after the thread is not used
> anymore. A safe solution is to call "_endthread" even if you have created
> the thread with "CreateThread".

Hi Jochen,

In that case I personally still prefer to use _beginthreadex because
_endthreadex will be called automatically when the thread ends.

And there are other reasons for not using CreateThread.
See
http://www.microsoft.com/msj/1099/win32/win321099.aspx

It costs no extra time to use one over the other, and microsoft themselves
warn that CreateThread has a number of possibly serious issues.
That is reason enough to always use _beginthreadex.

Signature

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Reply to this Message

Jochen Kalmbach [MVP] - 07 Jul 2006 10:15 GMT

Hi Bruno!

>> The problem is just the release of TLS after the thread is not used
>> anymore. A safe solution is to call "_endthread" even if you have created
>> the thread with "CreateThread".
>
> In that case I personally still prefer to use _beginthreadex because
> _endthreadex will be called automatically when the thread ends.

Yes. I totally agree.

Just wanted to say that only the "freeing" is the problem, not the
allocating of th eTLS, as your quoted text said...

Greetings
Jochen

Reply to this Message

Kim Gräsman - 09 Jul 2006 09:37 GMT

Hi Jochen and Bruno,

>>> The problem is just the release of TLS after the thread is not used
>>> anymore. A safe solution is to call "_endthread" even if you have
>>> created the thread with "CreateThread".
>>>
>> In that case I personally still prefer to use _beginthreadex because
>> _endthreadex will be called automatically when the thread ends.

I've been mulling over this lately, especially what happens if you use the
CRT on OS thread-pool threads (as used by QueueUserWorkItem, for example).

I've found a couple of newsgroup discussions covering this, and it seems
the general consensus is that it is safe if you link with the DLL version
of the CRT, because it has the cleanup code in its DLL_THREAD_DETACH handler
in DllMain.

So, I would venture to guess that if you link with the DLL CRT, none of this
is a problem. Does that ring true to you?

--
Best Regards,
Kim Gräsman

Reply to this Message

Bruno van Dooren - 09 Jul 2006 11:16 GMT

>>>> The problem is just the release of TLS after the thread is not used
>>>> anymore. A safe solution is to call "_endthread" even if you have
[quoted text clipped - 13 lines]
> So, I would venture to guess that if you link with the DLL CRT, none of
> this is a problem. Does that ring true to you?

From MSDN
"To use thread pooling, the work items and all the functions they call must
be thread-pool safe. A safe function does not assume that thread executing
it is a dedicated or persistent thread. In general, you should avoid using
thread local storage and queuing asynchronous calls that require a
persistent thread, such as the RegNotifyChangeKeyValue function. However,
such functions can be queued to a persistent worker thread using
QueueUserWorkItem with the WT_EXECUTEINPERSISTENTTHREAD option."

If you follow this guideline, you won't have issues with your own code
because there will be no TLS to cleanup.
There is no mention of the CRT, so it should not matter either way (static
or dynamic) or it should have been mentioned along with the above
restrictions.

Could you post a link to the discussions you found regarding this? I'll take
a closer look.

Signature

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Reply to this Message

Kim Gräsman - 09 Jul 2006 11:51 GMT

Hi Bruno,

> There is no mention of the CRT, so it should not matter either way
> (static or dynamic) or it should have been mentioned along with the
> above restrictions.

Yes, one would hope so :-)
Unfortunately, it doesn't seem to be the case, and the statically linked
CRT is indeed a problem, because we are not in control of thread creation/destruction.

> Could you post a link to the discussions you found regarding this?
> I'll take a closer look.

This is the one I was thinking of, Skywing's second response, more specifically:
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_f
rm/thread/5f72f7a937feb169

While searching for that, I came up with a new reference, this time from
Bobby Mattappally of Microsoft:
http://groups.google.com/group/microsoft.public.vc.language/browse_frm/thread/10
1597aad6adcd23

Here are a couple of other threads on the same theme, with various solutions:
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_f
rm/thread/2801ec76f0b1900a
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_f
rm/thread/2c1d13dfd809c65

--
Best Regards,
Kim Gräsman

Reply to this Message

Bruno van Dooren - 09 Jul 2006 14:50 GMT

>> There is no mention of the CRT, so it should not matter either way
>> (static or dynamic) or it should have been mentioned along with the above
[quoted text clipped - 3 lines]
> and the statically linked CRT is indeed a problem, because we are not in
> control of thread creation/destruction.

I just read the post you pointed to and you are right. using CRT in those
cases is not safe unless you are using the dynamic CRT.
This is sort of implied by the text I quoted earlier, since the CRT itself
uses TLS.
It is just not mentioned explicitly, which is a pity because it is easy to
overlook, as I did the first time.

Signature

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Reply to this Message

Bronek Kozicki - 09 Jul 2006 22:22 GMT

> you can use _beginthreadex to do that.
> Do not use CreateThread. it is not safe.

the problem is not in API function, but in static runtime. There are no leaks
in dynamic runtime.

> Or if you use MFC you could use CWinThread.

do not do that.

B.

Reply to this Message

Pugal - 07 Jul 2006 07:33 GMT

hi Jochen and Bruno van Dooren

Thank you for your speedy help, right now I able convert my project into
multithreaded one..

Greetings
-Pugal

> Hi
>
[quoted text clipped - 4 lines]
>
> -Pugal.G

Reply to this Message

How to create threads in VC++

Free Magazines