Looking for help with the Tbb_task_scheduler

[ndepalma]

Hi, we're having trouble with the tbb_task_scheduler. We're receiving the exception in tbb_debug "cleaning up master with missing TaskPool" when we destruct the tbb_task_scheduler. What could possibly create this problem?

This is task.cpp::1987

Thanks a bunch!

[robert-reed]

Can you be more descriptive of your scheduler configuration? Are you creating more than one task_scheduler_init object at a time? The only way I can see this ASSERT being triggered is if on the last call to terminate (hitting zero in the reference count), the task pool allocated to the scheduler has already gone away. That's not a behavior you should ever see with a simple, single task_scheduler_init object living in the scope of main, so your code must be doing something funky. Any hints at what that might be will help us try to figure out how your code is landing in this unexpected trap.

And, oh, as a lark you might try the latest stable TBB release in the unlikely case this is running into some old bug. The ASSERT you mention occurs on line 3201 of my copy of task.cpp, so I think there have been a lot of changes since the version you appear to be using.

[ndepalma]

I'm a bit concerned that I won't be able to fully describe the environment, but I'll try my best to give you an idea of the dynamics and maybe you'll have some potential possibilities. TBB is being used inside of a plugin that is implemented as a dll. It's a highly threaded environment and since the scheduler users a TLS entry, we create a scheduler_init for each thread to ensure that the scheduler is initialized, but to also ensure that tbb isn't loaded/unloaded, we thread off one tbb_scheduler to reduce latency. This could potentially create a problem if the refcount inside the scheduler is not thread safe. (?) The current crash we've traced to an unload of the DLL. Since everything is serialized in a DllMain, we're initializing this separate thread inside a separate DLL that won't be serialized while posting a shutdown of the thread. When we unload the DLL, we post this shutdown message to the separate DLL and let it shutdown concurrently.

... In writing this, maybe we should see if we could explicitly lock the scheduler and test this theory.

Any thoughts or advice?

[ndepalma]

Ok. It was a bug of course. Lesson of the story - don't pass scheduler_init from one thread to another for "holding". ... initialize it in the thread you destroy it!