8ba
Subj : Re: CondVar on Windows : what to do when a consumer thread is killed
To   : comp.programming.threads
From : Pavel Lebedinsky
Date : Fri Jul 01 2005 03:02 pm

Alexander Terekhov wrote:

> > During the singleton destruction, a special message is posted to this
> > queue to signal the worker thread to stop, and posting to the queue
> > implies calling pthread_cond_broadcast.
> > The problem is that, since the singelton is a static object, it's
> > destructor runs during CRT termination cleanup, *after* the system has
> > forcibly killed all worker threads --> deadlock  :-(
>
> So what's the point in calling pthread_cond_broadcast() at process
> termination time in the last thread ("uncontrolled" evaporation of
> other threads resulting in broken shared state aside for a moment)?
>
> "Doctor, it hurts when I do this. Doctor: Don't do that." ;-)

Note also that there are severe restrictions on what you can do
in a static destructor:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp

<quote>
If your DLL is linked with the C run-time library (CRT), the entry
point provided by the CRT calls the constructors and destructors for
global and static C++ objects. Therefore, these restrictions for
DllMain also apply to constructors and destructors and any code that is
called from them.
</quote>

Additionally, you should not return from main() while you still
have worker threads running. ExitProcess docs mention this:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/exitprocess.asp

<quote>
Therefore, if you do not know the state of all threads in your process,
it is better to call TerminateProcess than ExitProcess. Note that
returning from the main function of an application results in a call to
ExitProcess.
</quote>

In a non-trivial app, knowing the state of all threads in the process
is virtually impossible because various system and 3rd party components
often create their own threads. In this case you should gracefully
shutdown the threads that you do own, and explicitly uninitialize
external components (e.g. if you use COM, call CoUninitialize) before
you return from main.

.

0