How to create threads in VC++

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
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..
Click to expand...

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

Greetings
Jochen

PS: WinAPI also supports fibers!
 
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..
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
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 Bruno!
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>
Click to expand...

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
 
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".
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Hi Bruno!
In that case I personally still prefer to use _beginthreadex because
_endthreadex will be called automatically when the thread ends.
Click to expand...

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
 
Hi Jochen and Bruno,

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?
 
The problem is just the release of TLS after the thread is not used
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?
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
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.
Click to expand...

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.
Click to expand...

This is the one I was thinking of, Skywing's second response, more specifically:
http://groups.google.com/group/micr...mer.kernel/browse_frm/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/101597aad6adcd23

Here are a couple of other threads on the same theme, with various solutions:
http://groups.google.com/group/micr...mer.kernel/browse_frm/thread/2801ec76f0b1900a
http://groups.google.com/group/micr...mmer.kernel/browse_frm/thread/2c1d13dfd809c65
 
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.
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno said:
you can use _beginthreadex to do that.
Do not use CreateThread. it is not safe.
Click to expand...

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.
Click to expand...

do not do that.


B.
 
Back
Top