Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
2421 Discussions

TBB 3.0 update 1 commercial-aligned release is available...


...on our open source site.
Changes (w.r.t. TBB 3.0 commercial-aligned release):

- Decreased memory fragmentation by allocations bigger than 8K.
- Lazily allocate worker threads, to avoid creating unnecessary stacks.

Bugs fixed:

- TBB allocator used much more memory than malloc (1703) - see above.
- Deadlocks happened in some specific initialization scenarios
of the TBB allocator (1701, 1704).
- Regression in enumerable_thread_specific: excessive requirements
for object constructors.
- A bug in construction of parallel_pipeline filters when body instance
was a temporary object.
- Incorrect usage of memory fences on PowerPC and XBOX360 platforms.
- A subtle issue in task group context binding that could result
in cancelation signal being missed by nested task groups.
- Incorrect construction of concurrent_unordered_map if specified
number of buckets is not power of two.
- Broken count() and equal_range() of concurrent_unordered_map.
- Return type of postfix form of operator++ for hash map's iterators.

Open-source contributions integrated:
- The fix to build examples on system there VS 2010 only is installed.

0 Kudos
4 Replies
Black Belt
"Incorrect usage of memory fences on PowerPC and XBOX360 platforms."
On what platforms have you tested the changed implementation?

(2010-06-19 early comments removed, see #2 instead)
Black Belt
Please make all of the following changes (well, comments and typos are somewhat less critical...):

In build/Makefile.test:
- 123: remove comment about alphabetical order (or reestablish such order)
- 207: move test_atomic to just after test_compiler to get the interesting platform-specific issues earlier

In examples/common/gui/video.h:
- 41: have a "typedef signed char depth_t;" for platforms where char is unsigned
- 46, 102, 127: use it

In examples/common/gui/xvideo.cpp:
- 82: here, too
- see the following longer text...

// TODO: It may happen that the build environment normally supports the shared-memory extension
// (so there's no reason to disable the relevant code by defining X_NOSHMEM),
// but that the program still fails when invoked over a "ssh -X" connection.
// This situation will (ultimately) cause the error handler set by XSetErrorHandler() to be invoked with
// XErrorEvent::minor_code==X_ShmAttach. The code below tries to make such a determination at XShmAttach() time,
// which seems plausible, but unfortunately it has been verified that the error may be reported at a later time instead,
// even after video::init_window() has returned (although it is not clear whether this may happen in that way
// on any environment that also has a local display that supports shared memory, because only "ssh -X" was available).
// A workaround would be to explicitly define X_NOSHMEM in xvideo.cpp (when building from source),
// if the program is always used in a particular way and does not have to detect this at run time,
// and perhaps to introduce an environment variable to affect the same for users using a prebuilt TBB.
// A helpful diagnostic would be to log XErrorEvent::minor_code==X_ShmAttach occurring after XShmAttach() returned,
// and to advise about a workaround.

In examples/parallel_for/tachyon/src/parse.cpp, evaluate the return values of fscanf or cast to void to avoid overwhelming the build with zealous warnings.

In include/tbb/compat/condition_variable, move line 380 up to 376 to #include also on Linux.

In include/tbb/machine/mac_ppc.h, it is not clear where the problem will occur, but I had to get the 64-bit values in and out by reference instead of by value, using extra registers, loads and stores, for things to work at all.

In include/tbb/atomic.h:
- 279: Plaforms
- 292, 304: introduce specialisations for double, which must make use of converter

In include/tbb/tbb_machine.h:
- 66: #elif __powerpc__/#include "machine/mac_ppc.h"/#else/#error Unsupported platform
- 76, 92: #else/#error Unsupported platform
- 572-574: // 2nd and 3rd argument must be identical but may be any value/return __TBB_CompareAndSwap8(const_cast(ptr),42,42);

Black Belt
Would that be "yes" by default? :-)
"Yes" to have a look at all these, and address as appropriate :)
Thanks for the feedback Raf!