CODEWITHSUNDEEP
c++multithreadingwinapi
Jim Fell
Jim Fell

Reputation: 14256

Cleanup on Thread Exit

When my thread exits its handle needs to be closed and reset to NULL. Rather than doing this upon the thread-closure event (e.g. ::WaitForSingleObject( s_hMyThread, TIMEOUT );), would it be valid to close the handle and reset it as the very last thing in the thread, before it returns, like this?

DWORD MyThread( LPVOID pParam )
{
    // Does something...

    ::CloseHandle( s_hMyThread );
    s_hMyThread = NULL;

    return 0;
}

Upvotes: 1

Views: 3059

Answers (4)

Damon
Damon

Reputation: 70106

After reading your comment to Lior Kogan's answer ("The thread in question is designed as a single-shot to handle some stuff that would otherwise lock up the application, so once it's done it's done."), it appears to me that you are not interested in that handle at all.

Why do you not CloseHandle(CreateThread(...)); then? This is perfectly allowed.

Or better yet, use _beginthread and _endthread. That will work even if you do have some interest in that thread and for example want to wait for it to finish.
From the docs: "_endthread automatically closes the thread handle (whereas _endthreadex does not). Therefore, when using _beginthread and _endthread, do not explicitly close the thread handle by calling the Win32 CloseHandle API."

No need to worry about closing anything, and it has the additional benefit of not leaking with broken CRT implementations.

Upvotes: 0

Serge Dundich
Serge Dundich

Reputation: 4429

Technically it is valid. You can close that handle just like any other handle - in any thread you like.

But closing thread's handle like you did in your example is not very good idea - it is generally pointless and it may be unsafe because there is no proper synchronization when accessing s_hMyThread variable. Of course you might do proper synchronization of your s_hMyThread variable but it would be too much hard-to-support code with no real purpose actually. There is no purpose in closing thread's handle from this very thread because the only reason of keeping thread's handle open is waiting somewhere this thread to complete that naturally implies that the handle should still be open when the thread completes.

Usually good practice is (1) if you don't have to wait until thread completes then you close its handle next line after its creation (next call after CreateThread), (2) if you do have to wait this thread's completion then you close thread's handle when you know thread's object is signalled (i.e. thread completed). I see no other usages when you really need thread's handle.

Upvotes: 0

Lior Kogan
Lior Kogan

Reputation: 20608

You can do it.

Closing a thread handle does not terminate the associated thread or remove the thread object. The thread object remains in the system until the thread has terminated and all handles to it have been closed through a call to CloseHandle.

However, if you'll do it, you'll lose to ability to check from the main thread of your application if the thread is still running, therefore, you won't be able to safely exit your application. One more thing: if your thread terminates in an unexpected way, you won't release the handle.

Upvotes: 4

Steve Townsend
Steve Townsend

Reputation: 54128

It's not clear to me that this will leave the thread object in a state where anybody waiting on it can determine what's going on. Per the docs:

When a thread terminates, the thread object attains a signaled state, satisfying any threads that were waiting on the object.

It's suspect to me that you would get a thread handle returned from CreateThread, but have the created thread close that handle. Seems counter to the intent of the API design, no? Regardless of whether it works, I would not do this unless it's essential to your design.

Upvotes: 0

Related Questions