First testing of TBB

[Alexandre_J_]

Hi Everybody,

I just stepped into this library after many years of manual threading with thread, mutex, wait conditions, etc.
All the concepts seems really great and it's really true that such abstraction layer will simplifly a lot development.
After a first look on TBB ( and reading of the associated o'reilly book ), I was pretty happy to try it in the code.

Now the issues. It seems that making collaborate two kind of threading systems is not that simple.
I'm using Qt and qt threading ( not qt concurrent yet even if I checked it ... seems a really lightweight tbb which some special issues not revelant here ).
Anyway. I made a test program to check TBB : it works for once thread, but not for more than one ( the crash can be anywhere in the code ). The code is really simple :
- a single parallel_for.
- it calls a member function of a class ( through an indirect call of a function whose arguments are this and function arguments ).

My questions :
- what should I check first ? It seems that it's more a contextual issue which some atomic Qt functions that perhaps cannot determine the threading context created by TBB ?
- I made this check : the same code crash inside a new qt Thread ( with local task_scheduler_init) the or in the main qt thread.
- how to you pass to arguments ( class context for example ) to the function that should be called by TBB ? Is there a standard way of doing that ? Here's my approach :

class TBBWrapper
{
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) {}
};

Thanks,
Alexandre

[Alexey-Kukanov]

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.

[Alexandre_J_]

Yes, I did create the task_scheduler_init on each thread.

"Do you reproduce the issue if you use native threads instead of Qt threads?" I didn't try to do that.
I will try the task_scheduler_observer too. It seems to be the right way to do that.
For parameter passing, I agree, it's really stylistic, sometimes I do this way, sometimes the other ( I like changing ). I wrote that quickly to have a sample to show.

Another question : It seems that such a package is really general and except some low end part like the number of cpu / core detection, cache evaluation, etc, everything is pretty standard, right ? I've read somewhere that it could quite work on G5 processors too. I know it's not your business, but may it comes in the future or not ? I'm really concerned about cross-platform ( win, mac, linux only ) ( that's why we use Qt ) and that's why I asked for that.
Or another idea : could a dummy interface to TBB be created which does nothing except a linear queue calls on unsupported plateform.

[Alexey-Kukanov]

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.

[Alexandre_J_]

Well, I wasn't aware of the source code because I used the commercial verison.
But apparently, there is one which is in fact open source, and that's really great because we will be able to try it even on G4/G5 processors.
BTW : apart availability of binary release, what's the aim of commercial version ? Perhaps was the binary release optimized ? Legal stuff ? Licensing ? I didn't found that on the website.

Hum ... reading kind of releases in the tbb download part.
- Commercially aligned release ... Seems that the code is quite the same, but just not packaged at the same time as standard release, right ?
- If I had to choose just one source code stable version, which one should I take, commercially aligned or stable release ?

I'm really happy the source code is available, because I hate working with dll and prefer to work statically linked :)
Thanks for that, really.

[Alexey-Kukanov]

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_ :)