I'm willing to bet this has been answered many time in many forms but I could't find anything that helped me, neither in the documentation nor by searching this forum.
The TBB docs are written from the perspective of a single-threaded program entering parallelizable sections (possibly nested) and emerging from them again. There's language about the requirement that each thread entering a TBB parallel construct initializing a task_sceduler_init object but nothing about what effect that has.
I've got a couple of situations that don't exactly fit the paradigm. Take the more general one: a library that may be called from a multithreaded program and wants to use TBB internally. We may be called from a thread with an existing task scheduler but from outside any TBB task, we may be called from inside a tbb task, and we may be called on a thread that's never heard of TBB before.
Further complicating matters, I'm working in Windows where all threads are not created equal. There's a faily hideous matrix of things that have per-thread initialization and periodic maintenance obligations.
I know, use the source, Luke. What I'm hoping for here isn't so much an insight into the TBB mechanism as the phrase that whacks my head into alignment with the authors' heads.
Specific issues:
If two independent user threads call into a module that uses TBB internally, will the tasks created by the called entry points be sceduled against each other? If so, is there any direct way to influence how they are scheduled?
If there's any notion of worker thread initialization hooks, I didn't see it. Should there be? Is there an idiom for it?
We're considering implementing a structure where we wrap the tbb::parallel_foo templates with versions that pass their parameters from whatever user thread they were invoked on into a TBB thread pool. The task trees so created are meant to have arbitrarily overlapping lifetimes and no direct interaction with one another. What if any gotchas do I need to be looking out for.
thank you,
-swn
I had similar questions about how to use task_scheduler_init in a DLL in this thread: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65576/. I ended up creating a task_scheduler_init instance in the DllMain() on process connect and terminate it on process detach. Then in each DLL function call that uses TBB, create a local task_scheduler_init instance (that will automatically destruct at the end of the call) in-case a background thread is calling it (should be a very cheap call).
I have no idea how to control the scheduling of tasks dispatched from different threads that may be running concurrently. Considering a 4 core machine, the first task_scheduler_init will create 3 worker threads. If the main thread and a background thread each dispatch a block of tasks, then they will fight for the 3 worker threads probably based on who dispatched first, but the main/bg threads will still have their own independent thread priorities. So, I guess you have a fractional control based on the disptcher thread's priority.
Peter
