c++ child threads terminating on main() parent thread exit?

Question

VS2013, C++ I just release dll application. One of dll app function run thread by _beginthread. In normal software flow I use mutex and control threads. Before unregister dll from main application I wait for thread terminating and close handlers.

However there is one case that main application could close without release resources in correct way I mean without waiting for child thread terminating and without close of handlers.

Is there any risk if main application force exit? Is there any risk if I run application and threads again after exit? Is there any risk for OS? Are all threads terminating after main exit?

I know that it is "dirty" solution but for some reason I can't change that.

Thank you in advance for advices.

Answer 1

According to Raymond Chen - in Windows systems - if the main thread terminates, your application hangs while all your threads end. This means, no your solution will not work, your thread will freeze your application in the closing state. Also even if your thread would be forcefully terminated on exit, it would not be uninitialized, and - since we are talking about MFC threads here - it would cause your application to leak resources, so pretty please don't do that!

Answer 2

Is there any risk if main application force exit?

Yes! Since thread can have started consistence-sensitive processes.

Is there any risk if I run application and threads again after exit?

Yes! May be previous shutdown crushed the data structure and now you cannot even load data correctly

Is there any risk for OS?

It depends on your business. May be you create a soft for disk-optimization and you are moving clusters while emergency shutdown?

Are all threads terminating after main exit?

Yes! You need foreseen special "join" code that waits accomplishment of threads.

Answer 3

I would say, the behavior is undefined. Too many things may happen, when the application is terminated without having the chance to clean up. This SO question may give some ideas.

This MS article describes TerminateThread function and also lists some implication of unexpectedly terminating the threads (which is probably happened on calling exit):

• If the target thread owns a critical section, the critical section will not be released.
• If the target thread is allocating memory from the heap, the heap lock will not be released.
• If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
• If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

So looks like there is a risk even for the OS

kernel32 state for the thread's process could be inconsistent