task_scheduler_observer::on_scheduler_exit not called

[romko]

Hi all,

I have a strange problem with using task_scheduler_observer: on_scheduler_entry function gets called for a worker thread, but not the on_scheduler_exit. Observer objects lives in a DLL as global variable.

Background: I am experimenting with usage of Thread Local Storage in my system (boost::thread_specific_ptr) and had a problem, that a deleter won't get called for my thread specific object which was created on demand from TBBs worker thread. So I decided to try to investivage things using task_scheduler_observer, but the problem is that observer's function is not being called as well :( Observer lives longer then worker thread. I have the feeling that my problems with TLS are somehow related/similar to task_scheduler_observer, but what could be the reason? I've tried explicit and implicit task scheduler initialization, but it didn't help.

Environment: MS Visual Studio 2008 , Tbb 2.2, Visa, Program consists of number of statically and dynamically linked DLLs

Thanks!

Edit 07.10.2009: Seems to be a problem only with TBB worker threads, thread doesn't even visit DllMain/DLL_THREAD_DETACH on process shutdown. If I start a thread explicitly - initialization and deinitialization in DllMainruns as expected (of course without calls to task_scheduler_observer). Maybe it is the way worker threads are started/finished?

[romko]

Quoting - romko

Hi all,

I have a strange problem with using task_scheduler_observer: on_scheduler_entry function gets called for a worker thread, but not the on_scheduler_exit. Observer objects lives in a DLL as global variable.

Background: I am experimenting with usage of Thread Local Storage in my system (boost::thread_specific_ptr) and had a problem, that a deleter won't get called for my thread specific object which was created on demand from TBBs worker thread. So I decided to try to investivage things using task_scheduler_observer, but the problem is that observer's function is not being called as well :( Observer lives longer then worker thread. I have the feeling that my problems with TLS are somehow related/similar to task_scheduler_observer, but what could be the reason? I've tried explicit and implicit task scheduler initialization, but it didn't help.

Environment: MS Visual Studio 2008 , Tbb 2.2, Visa, Program consists of number of statically and dynamically linked DLLs

Thanks!

Edit 07.10.2009: Seems to be a problem only with TBB worker threads, thread doesn't even visit DllMain/DLL_THREAD_DETACH on process shutdown. If I start a thread explicitly - initialization and deinitialization in DllMainruns as expected (of course without calls to task_scheduler_observer). Maybe it is the way worker threads are started/finished?

Edit2 07.10.2009: After further research I see that worker threads never get freed by scheduler, they are just killedduring process exit (this explains why resources get leaked).

[Andrey_Marochko]

All threads that are still running at the moment when the main thread finishes (e.g. when return from main() is performed) are killed by Windows. To receive correct shutdown notifications in the TBB threads you need to deinitialize TBB scheduler before returning from main() or WinMain().

[Alexey-Kukanov · Accepted solution]

Quoting - Andrey Marochko (Intel)

All threads that are still running at the moment when the main thread finishes (e.g. when return from main() is performed) are killed by Windows. To receive correct shutdown notifications in the TBB threads you need to deinitialize TBB scheduler before returning from main() or WinMain().

Actually, even that is not quite enough. TBB worker threads are detached, i.e. the main thread does not wait for their completion (we used to, but had to stop it due to loader-lock-inflicted deadlocks in several usagescenarios). Thus worker threads might get killed in the middle of shutdown even when task_scheduler_init is used.

Suspending the main thread for little after task_scheduler_init destruction (but before exiting), if acceptable, should be a workaround (an ugly one, I agree beforehand). Waiting until on_scheduler_exit is called could be another possible workaround (and I can imagine why it could also be ugly).