...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.
- 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.
On what platforms have you tested the changed implementation?
(2010-06-19 early comments removed, see #2 instead)
- 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
- 41: have a "typedef signed char depth_t;" for platforms where char is unsigned
- 46, 102, 127: use it
- 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
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.
- 279: Pla
- 292, 304: introduce specialisations for double, which must make use of converter
- 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