Roland wrote:
Quote
Hello All
CWinThread has one memeber m_nAutoDelete . Does it mean that I don't
have to delete the objecct of CWinThread.
e.g.
CMyThread *pThread = new CMyThread()
pThread->CreateThread();
Supppose ,I allocated the object of CMyThread ( derived from
CWinThread ) on heap and set m_bAutoDelete=TRUE in constructor on
CMyThread. When my thread exited , Does it require to call delete
pThread or CWinThread automatically delete it ? In above case ,
Should I call delete pThread when thread is exited ?
A newly created CWinThread always has m_bAutoDelete set to true, and yes,
this means it will delete itself when the thread has ended. Sounds neat,
huh? It isn't. Below are some excerpts from previous messages I've written
about this.
About safely using CWinThread:
To safely use CWinThread, you must start the thread suspended and set the
CWinThread object's m_bAutoDelete member to false or DuplicateHandle a copy
of its m_hThread member. Only then should you resume the thread. This avoids
the race condition resulting from the default auto-delete behavior, allowing
you to wait on the thread handle. It's even worse than that. According to
the current WaitForSingleObject documentation, it's undefined for a handle
to be closed while you're waiting on it. Thus, all code which waits on a
CWinThread m_hThread member while the CWinThread auto-deletes itself is
undefined. If you set m_bAutoDelete to false, you assume the responsibility
for deleting the CWinThread, while if you dup m_hThread, you will have to
close the duped handle when you're done with it. I find it easier to change
m_bAutoDelete.
About why you should join with your threads before exiting your app:
In general, it's a bad idea to allow secondary threads to continue executing
as the application is shutting down, static duration objects are being
destroyed, the CRT is being taken down, etc, until the CRT finally calls
ExitProcess and kills them all, assuming the secondary threads haven't
deadlocked with the CRT shutting down in the primary thread or crashed in
the meantime, say, due to objects they're using being destroyed. To avoid
this and achieve an orderly shutdown, you have to join with all your threads
before exiting your app, and that means being able to wait on their handles.
But you can't wait on their handles if they auto-delete themselves, because
according to MSDN, it's undefined to close a handle being used in a Wait
function, and it's the secondary thread that closes the CWinThread handle
before auto-deleting and terminating, the latter being the thing which would
cause the handle to become signaled, if only it hadn't been closed already!
This whole auto-deletion concept as applied to threads is pretty much a bad
idea, with limited utility.
--
Doug Harrison
Microsoft MVP - Visual C++
-
