Well, since TBB is already on windows, linux and mac, and with rumors of at least solaris in the offing, sounds like the best approach might be to close the gap on the platforms not in this list. And since for linux and other unix-like OSes TBB uses p-threads as the underlying thread interface, the effort to port MUCH of the code might be pretty straightforward. Regarding the options you speculate about:

using #ifdefs. If this is to differentiate single threaded code from TBB threaded code, that might be a very fast way to get started, though it means HW thread scaling on some platforms but not others (assuming TBB is the only threading vehicle).

port TBB to Qt threads. A quick glance suggests that Qt Threads is yet another wrapper around system dependent low level threading libraries. Since TBB already has a p-threads base, porting to Qt threads may be more work than just porting to the unsupported platforms. Moreover, while TBB is designed to interoperate fairly in conjunction with other threading libraries, there's always the risk of oversubscription, especially if you have multiple levels of forks in your code.

create a threadless version of TBB. It already exists (sort of). If you create your task_scheduler_init object with a count of 1, you'll get single-threaded behavior such as you describe, though linking may be an issue if you don't have the p-threads or other system call libraries needed to complete the link.

Hope this helps.

There are three major parts in porting TBB to a system that's not yet supported:

1. Hardware specific layer that implements atomic operations such as compare-and-swap. At the very least, 4- and 8-byte compare-and-swap should be implemented. Currently, we provide full implementations for IA-32, IA-64, Intel 64 and compatible architectures, and the minimal layer for 64-bit Power G5.


2. Underlying threading package as well as some other OS-specific calls such as sched_yield; but since we already use POSIX threads and UNIX specification compatible calls for Linux and Mac OS X implementations, I believe the same could be used for other UNIX family systems.


3. Compiler-specific set of parameters to build the library and its tests. Again, as we support g++, enabling it for a new system where g++ works should be quite trivial. If you use vendor-provided compilers, it might take some efforts, but still shouldn't be too hard.

With that said, I think porting to Qt threads is not an option, because it would only solve 2) that should be easy anyway. As 3) is less a problem (I would bet you choose GCC for your cross-platform development :)), you need a solution that either provides the required HW layer or makes it unnecessary. Considering a threadless solution: the described way of using TBB pre-built single threaded behavior would be okay on a system with supported processors, but it would not solve 1) for unsupported HW, as so far the TBB task scheduler is not customized to avoid atomic operations in single-threaded case. So if you decide that threadless version is the optimal solution for you at the moment, and your target HW is not supported, then you better customize parallel_for and other algorithms like you said.

And basically I agree with Robert that making the actual port seems the best approach.

A fake threadless TBB is something that we considered from time to time, but never had time to write. So yes, wemight be interested in it as a contribution. I suggest starting a separate discussion string on the technical details and scope. E.g., just doing threadless variants of the parallel algorithms (and not attempting a threadless task scheduler) might suffice for most people.

Section 4.1.2 of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2104.pdfhas the code for a threadless parallel_for.