Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
2477 Discussions

task_scheduler_observer::on_scheduler_exit not called

romko
Beginner
838 Views
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?
0 Kudos
1 Solution
Alexey-Kukanov
Employee
838 Views
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).

View solution in original post

0 Kudos
3 Replies
romko
Beginner
838 Views
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).
0 Kudos
Andrey_Marochko
New Contributor III
838 Views
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().
0 Kudos
Alexey-Kukanov
Employee
839 Views
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).
0 Kudos
Reply