class TBBWrapperThanks,
{
myClass* m_pClass;
JobLists m_jobs;
public:
void operator()( const blocked_range< size_t >& r ) const
{
int nb = m_jobs.size();
for (size_t i=r.begin(); i!=r.end(); ++i )
m_pClass->CallFunction( m_jobs );
}
TBBWrapper( myClass* instance, JobLists jobs ) :
m_jobs( jobs ), m_pClass(instance) {}
};
Link Copied
The only thing TBB requires from a foreign thread is creating a task_scheduler_init object before calling any TBB algorithm or spawning a task. But it sounds like you did that.
Do you reproduce the issue if you use native threads instead of Qt threads? If no, I think your guess is probably correct and some Qt context may not exist in TBB worker threads. To resolve that, you might try using task_scheduler_observer functionality: inherit your own class from task_scheduler_observer, override its virtual methods to set necessary Qt contexts, and create an instance of the class. It is guaranteed that each TBB worker thread will call the overridden methods for this object before it executes its next stolen task; so the object is created before the very first task_scheduler_init object, necessary contexts should be set up in a worker thread before it starts doing any parallel work.
Your approach to pass class context is just right; I would prefer passing by reference rather than by pointer, but that's just stylistic difference. Of course, the method(s) of the class called from operator() should be thread-safe.
You are right that generally only the low-level part of TBB should be ported toa particular HW platform. And in fact we have some basic low-level implementation for PowerPC; see include/tbb/machine/mac_ppc.h. This mean, TBB should in theory work on PPC-basedmachines running Mac OS X. So I suggest you make it a try, and tell us the results. We will be glad to improve portability and fix issues if any, though our testing & debugging possibilities are somewhat limited for platforms not compatible with Intel architectures, and we do not provide commercial TBB versions for those.
Commercial-aligned releases are there for customers who want exactly the same bits in open-source that we released as the commercial product. The license for those is still the same, i.e. GPL with runtime exception. Current com-aligned releases are aligned with TBB 2.0 updates which are kept rather conservative to changes and mostly contain bug fixes.
Stable releases, in contrast, contain all the work in progress to the next TBB version. So if you are interested in new features, you better take a stable release, or might be even a developer update if you are not afraid of building TBB by yourself and keeping after frequent updates.
As for statical linkage, TBB does not support it and we have a lot of solid reasons not to support, listed somewhere on TBB FAQ pages; I think you will find the corresponding note there, also there was a thread at the forum where I put the link. The main reason is that it is very easy to end up with two instances of TBB being loaded into an application process and conflicting for resources which causes CPU oversubscription and other bad consequences. So if you decide to go static, you are on your own, though probably you wouldn't want to thank us for _that_ :)
For more complete information about compiler optimizations, see our Optimization Notice.