Hello,

I'm using parallel_sort and regretfully my comparator needs to use a object that is not thread safe. I can make copies of this object for each thread and then the comparator would just need to use the right copy for the thread it is on, kind of like a thread_local but not global.

I'm looking for some tips on how to achieve this with TBB. I know task_scheduler_observer and enumerable_thread_specific are both options for implementing thread_locals but I'm not sure which is better in my case.

Thanks in advance!

Hi,

Recently I added my custom task scheduler observer. I got the following warning when debugging:

TBB Warning: Leaked 1 observer_proxy objects.

Does anyone know how to get rid of this warning?

My custom observer is pretty simple:

    class PipelineObserver : public tbb::task_scheduler_observer
    {
        ADrawContext& mDC;
        void operator=(const PipelineObserver&);
        PipelineObserver();
    public:
        PipelineObserver(ADrawContext& dc)
            : mDC(dc)
        {
            observe(true);
        }

        ~PipelineObserver()
        {
            observe(false);
        }

        virtual void on_scheduler_entry(bool  /* is_worker */ )
        {
            if(mDC.HasVirtualDevice())
                mDC.VirtualDevice().AcquireLocalOGLContext();
        }
    };

I used the observer as below:

                {
                    // Pipeline scheduler observer. It observes the worker threads entering the 
                    // task arena.
                    PipelineObserver o(dc);

                    // use TBB to execute a parallel while
                    tbb::parallel_while<ApplyIterator> w;
                    ApplyIterator body(*this, iteratorStream, eyePosition, maxCell, &w);
                    w.run(iteratorStream, body);
                }

Thanks!

Changes (w.r.t. Intel TBB 4.3 Update 3):
- Added a C++11 variadic constructor for enumerable_thread_specific.
    The arguments from this constructor are used to construct
    thread-local values.
- Improved exception safety for enumerable_thread_specific.
- Added documentation for tbb::flow::tagged_msg class and
    tbb::flow::output_port function.
- Fixed build errors for systems that do not support dynamic linking.
- C++11 move aware insert and emplace methods have been added to
    concurrent unordered containers.

Preview Features:
- Interface-breaking change: typedefs changed for node predecessor and
    successor lists, affecting copy_predecessors and copy_successors
    methods.
- Added template class composite_node to the flow graph API. It packages
    a subgraph to represent it as a first-class flow graph node.
- make_edge and remove_edge now accept multiport nodes as arguments,
    automatically using the node port with index 0 for an edge.

Open-source contributions integrated:
- Draft code for enumerable_thread_specific constructor with multiple
    arguments (see above) by Adrien Guinet.
- Fix for GCC invocation on IBM* Blue Gene*
    by Jeff Hammond and Raf Schietekat.
- Extended testing with smart pointers for Clang & libc++
    by Raf Schietekat.

I am debugging an issue in my code where I have a concurrent_bounded_queue two producers threads and one consumer thread. The consumer has default thread priority and the producers have low thread priority.

Sometimes I get a deadlock with these stack traces:

Thread 66 (Thread 0x7ffedffff700 (LWP 9126)):

#0  0x00007ffff2025737 in sched_yield () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff7981f4d in pause (this=<synthetic pointer>) at src/tbb/tbb/include/tbb/tbb_machine.h:333
#2  __TBB_LockByte (flag=@0x7ffff1b37b08: 0 '\000') at src/tbb/tbb/include/tbb/tbb_machine.h:846
#3  scoped_lock (m=..., this=<synthetic pointer>) at src/tbb/tbb/include/tbb/internal/../spin_mutex.h:93
#4  tbb::internal::concurrent_monitor::notify_relaxed<tbb::internal::predicate_leq> (this=this@entry=0x7ffff1b37b08, predicate=...) at src/tbb/tbb/src/tbb/concurrent_monitor.h:223
#5  0x00007ffff798177f in notify<tbb::internal::predicate_leq> (predicate=..., this=0x7ffff1b37b08) at src/tbb/tbb/src/tbb/concurrent_monitor.h:181
#6  tbb::internal::concurrent_queue_base_v3::internal_push (this=this@entry=0x145d368, src=src@entry=0x7ffedfffe530) at src/tbb/tbb/src/tbb/concurrent_queue.cpp:403
#7  0x00000000004a0840 in push (source=..., this=0x145d368) at ../src/tbb/tbb/include/tbb/concurrent_queue.h:263
 

Thread 64 (Thread 0x7ffee57fa700 (LWP 9124)):
#0  0x00007ffff2025737 in sched_yield () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff7981f4d in pause (this=<synthetic pointer>) at src/tbb/tbb/include/tbb/tbb_machine.h:333
#2  __TBB_LockByte (flag=@0x7ffff1b37b08: 0 '\000') at src/tbb/tbb/include/tbb/tbb_machine.h:846
#3  scoped_lock (m=..., this=<synthetic pointer>) at src/tbb/tbb/include/tbb/internal/../spin_mutex.h:93
#4  tbb::internal::concurrent_monitor::notify_relaxed<tbb::internal::predicate_leq> (this=this@entry=0x7ffff1b37b08, predicate=...) at src/tbb/tbb/src/tbb/concurrent_monitor.h:223
#5  0x00007ffff798177f in notify<tbb::internal::predicate_leq> (predicate=..., this=0x7ffff1b37b08) at src/tbb/tbb/src/tbb/concurrent_monitor.h:181
#6  tbb::internal::concurrent_queue_base_v3::internal_push (this=this@entry=0x145d368, src=src@entry=0x7ffee57f9530) at src/tbb/tbb/src/tbb/concurrent_queue.cpp:403
#7  0x00000000004a0840 in push (source=..., this=0x145d368) at ../src/tbb/tbb/include/tbb/concurrent_queue.h:263
 

Consumer thread:

Thread 33 (Thread 0x7fff7ffff700 (LWP 9092)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007ffff7981a3b in futex_wait (comparand=2, futex=0x7fff7fffe960) at src/tbb/tbb/include/tbb/machine/linux_common.h:67
#2  P (this=0x7fff7fffe960) at src/tbb/tbb/src/tbb/semaphore.h:212
#3  commit_wait (thr=..., this=<optimized out>) at src/tbb/tbb/src/tbb/concurrent_monitor.h:152
#4  commit_wait (thr=..., this=<optimized out>) at src/tbb/tbb/src/tbb/concurrent_queue.cpp:406
#5  tbb::internal::concurrent_queue_base_v3::internal_pop (this=this@entry=0x145d368, dst=dst@entry=0x7fff7fffea20) at src/tbb/tbb/src/tbb/concurrent_queue.cpp:426
#6  0x00000000004a274b in pop (destination=..., this=<optimized out>) at ../src/tbb/tbb/include/tbb/concurrent_queue.h:269
 

Is this a known bug? Or is the problem likely to be in my code?

I am using TBB 4.1 (6100) on a Linux 64-bit machine.

hello ,
I have built a library(say MYLIB) in which i have used tbb to paralleize. This  MYLIB i am trying to use for one application i am building and when i try to build the application getting following erros :

/usr/include/tbb/internal/_concurrent_unordered_impl.h:146:85: error:   expected a type, got ‘397’
/usr/include/tbb/internal/_concurrent_unordered_impl.h:146:85: error: template argument 2 is invalid
/usr/include/tbb/internal/_concurrent_unordered_impl.h:146:90: error: ‘bool tbb::interface5::internal::operator!=(const int&, const int&)’ must have an argument of class or enumerated type
     friend bool operator!=( const solist_iterator<M,T>& i, const solist_iterator<M,U>& j );

can anyone please help , i am new to tbb .

Hi,

I want to exclude main thread. I have a longrunning work that should run independent of main thread. Also, the longrunning work has to work by splitting it multiple tasks. I have tried to create a root task and enqueue it. Afterwards, the root task spawned the child tasks.

For example,

longtask *root_task = new(task::allocate_root())longtask();

task::enqueue(*root_task);

class longtask

{

         task* execute()

       {

        set_ref_count(m_task_count + 1);

        for(int i = 0; i < m_task_count; ++i)
        {
            spawn(*new(allocate_child())task_func(m_func, m_data, i, m_task_count));
        }

        wait_for_all();

       }

}

Why doesn't it work? It works when I create explicitly worker thread(The worker thread spawns the childs and calls wait_for_all, there is no enqueue). So Main thread or another explicitly created worker thread can spawn childs only?

Hi,

I've been developing a node based editor and figured the TBB Flow Graph would be a perfect fit for my application. However, I can't seem to figure out how to setup the graph. The problem is as follows (I'm also attaching an image to illustrate this):

I have a bunch of nodes, each of which have a varying (not known at compile time) number of input- and output sockets. The nodes that do not have any incoming connections (node 0 and 3 in the attached image) are considered to be root nodes and should be evaluated first. These nodes have edges to the "source_node" node which does N iterations (a run-time value that determines how many times the graph should be evaluated).

The sockets are simply value containers that can either hold an integer, a float, or any other type that is defined by my application (boost::variant)

Node 2 has an additional gray socket, this is simply to indicate that there could be an additional input there, this is not known at compile time.

Now the question is, how do I setup my graph so that each node has access to the values of each of the output ports to which it is connected? So, for example, node 2 needs 3 input values to be able to evaluate successfully. In this case, it needs to grab the values from both Node 0 and Node 3.

I've tried searching for examples, but all that I was able to find were examples dealing with a fixed number of inputs/outputs (e.g. a multifunction_node using a tuple)

Any help would be greatly appreciated!

Thanks,
Martijn

These free technical webinars cover tips and techniques that will help sharpen your development skills to create faster, more reliable applications. Technical experts will cover topics ranging from vectorization, code migration, code optimization, using advanced threading techniques (e.g., OpenMP 4.0, Intel® Cilk™ Plus, Intel® TBB), and error checking. Bring programming questions to the live session for our technical experts to answer. A replay of each webinar will be available shortly after the live session so you can share with those unable to attend the live session.

Times indicated are Pacific time. PST: Standard (UTC/GMT -8 hours), PDT: Daylight Savings (UTC/GMT -7 hours)

Archived Webinars

Upcoming Webinars

The Intel® Threading Building Blocks (Intel® TBB) library provides an alternative way to dynamically allocate memory - Intel TBB scalable allocator (tbbmalloc). Its purpose is to provide better performance and scalability for memory allocation/deallocation operations in multithreaded applications, compared to the default allocator.

There are two general ways to employ Intel TBB scalable allocator in your application:

1. Explicitly specifying TBB scalable allocator in source code, either by using memory allocation routines (like “scalable_malloc”) or by specifying Intel TBB scalable allocator for containers:

#include <tbb/scalable_allocator.h>
std::vector<int, tbb::scalable_allocator <int> >;

1. Automatic replacing of all calls to standard functions for dynamic memory allocation (such as malloc) with the Intel TBB scalable equivalents. This option was introduced in Intel TBB 4.3

One way to do the automatic replacement is to link the main executable file with the Intel TBB malloc proxy library:

clang++ foo.o bar.o -ltbbmalloc_proxy -o a.out

Another way does not even require re-building, so you can provide a new memory allocator to the same binary. This is done by loading the malloc proxy library at an application start time using the DYLD_INSERT_LIBRARIES environment variable:

DYLD_INSERT_LIBRARIES=libtbbmalloc_proxy.dylib

In OS X, simple loading libraries with DYLD_INSERT_LIBRARIESrequires using flat namespaces in order to access the shared library symbols. If an application was built with two-level namespaces, this will not work, and forcing usage of flat namespaces may lead to a crash.

Intel TBB overcomes this problem in a smart way. When libtbbmalloc_proxy library is loaded into the process, its static constructor is called and registers a “malloc zone” for TBB memory allocation routines. This allows redirecting memory allocation routine calls from a standard C++ library into TBB scalable allocator routines. So the application doesn’t need to use TBB malloc library symbols, it continues to call standard “libc” routines, thus there are no problems with name spaces. Also, OS X “malloc zones” mechanism allows applications to have several memory allocators (e.g. used by different libraries) and manage memory correctly. It guarantees that Intel TBB will use the same allocator for allocations and deallocations. It is a safeguard against crashes due to calling a deallocation routine for a memory object allocated from another allocator.

Additional links:

Intel TBB: Memory Allocation
Intel TBB documentation: dynamic memory interface replacement on OS X
Intel TBB documentation: Memory Allocation reference

I have an algorithm that can be parallelised using the divide-and-conquer approach, but requires more than one parallel stage per task. In other wordsk, a given task can be split into several consecutive stages which cannot be done in parallel, but each stage can potentially be split into several parallel tasks. I have implemented this as sketced below.

struct staged_task
  : tbb::task
{
  const int num_stages=2;              ///< total number of parallel stages
  int stage=0;                         ///< stage counter
  staged_task(task_data const&);       ///< constructor
  bool little_work();                  ///< is this task best done serially?
  void serial_execution();             ///< do this task serially
  /// add another child to list of children
  void add_child(int&child_count, tbb::task_list&children, task_data const&data)
  {
    ++child_count;
    children.push_back(*new(allocate_child()) staged_task(data));
  }
  /// create child tasks by calling add_child()
  void make_children(int&child_count, tbb::task_list&children);
  /// execute
  tbb::task*execute() final
  {
    tbb::task*child=nullptr;
    // 1     serial execution
    if(0==stage && little_work())
      serial_execution();
    // 2     next non-empty parallel stage
    else if(stage<num_stages) {
      // 2.1 allocate children, skipping empty stages
      int child_count=0;
      tbb::task_list children;
      for(; stage<num_stages && child_count==0; ++stage)
	make_children(child_count,children);
      // 2.2 prepare for continuation and spawn children
      if(child_count) {
	recycle_as_continuation();
	set_ref_count(child_count);
	child = children.pop_front();
	spawn(children);
      }
    }
    return child;
  }
};

The real code is more complex with different types of staged tasks, but this is the essence. The code appears to work fine, but recently it ran into a problem when the number of active threads dropped to 2 (as judged by command top) and wallclock time was very long (much longer than 2 threads should have needed).

I was wondering whether my code above could be at fault. And/or otherwise how I can debug this issue.

Hi,

Clang supports GCC builtin intrinsics (__sync_*) used for atomics. I tested master branch and Clang 3.5 in Fedora 21 on x86_64 and aarch64 machines. include/clang/Basic/Builtins.def from Clang contained every intrinsic used in TBB. I compiled TBB (current version, tbb43_20150316oss) on x86_64 with Clang with -DTBB_USE_GCC_BUILTINS=1  and it compiled. I seems Clang isn't fully maintained and some tests fail even on x86_64. Similar tests failed on aarch64 (plus one additional).

TBB headers are parsed by C++ interpreter (Cling) and that's there it failed for us on aarch64. Considering that Clang supports needed bits, I would suggest to enable use on GCC builtins in Clang too. Patch below. I enabled it for 3.5, because that's the oldest version I tried.

BTW, I was not able to login to TBB contribution page: The website encountered an unexpected error.

diff --git a/include/tbb/tbb_config.h b/include/tbb/tbb_config.h
index c65976c..567c36a 100644
--- a/include/tbb/tbb_config.h
+++ b/include/tbb/tbb_config.h
@@ -261,7 +261,7 @@
 /* Actually ICC supports gcc __sync_* intrinsics starting 11.1,
  * but 64 bit support for 32 bit target comes in later ones*/
 /* TODO: change the version back to 4.1.2 once macro __TBB_WORD_SIZE become optional */
-#if __TBB_GCC_VERSION >= 40306 || __INTEL_COMPILER >= 1200
+#if __TBB_GCC_VERSION >= 40306 || __INTEL_COMPILER >= 1200 || __TBB_CLANG_VERSION >= 30500
     /** built-in atomics available in GCC since 4.1.2 **/
     #define __TBB_GCC_BUILTIN_ATOMICS_PRESENT 1
 #endif
@@ -542,7 +542,7 @@
     #define __TBB_SSE_STACK_ALIGNMENT_BROKEN 0
 #endif

-#if __GNUC__==4 && __GNUC_MINOR__==3 && __GNUC_PATCHLEVEL__==0
+#if !defined(__clang__) && (__GNUC__==4 && __GNUC_MINOR__==3 && __GNUC_PATCHLEVEL__==0)
     /* GCC of this version may rashly ignore control dependencies */
     #define __TBB_GCC_OPTIMIZER_ORDERING_BROKEN 1
 #endif

Sorry off-topic but I could not find any other forum to post this.

I got file attachments (at least, the sender told me that) from an Intel support, but I do not see any download button or link in the private message thread. Anybody know how to download these files?

Thanks! 

Hi all,

Is it possible to run concurrent, multiple, FlowGraph instances? If so, what would be the best way to execute them? My immediate thought is to spawn 2 threads, then run each flowgraph in a separate thread, checking for termination, etc.

This is a rather weird design case, where I need to parse the same (huge) data stream twice: hence would be buffering to temporary file mid-flow. The two flow graphs would then be pre-file and post-file. Although it is possible to achieve this using a single flow-graph, there are all sorts of issues surrounding the stalling of the graph should all the data not arrive on time: hence why it's desirable to keep things separate.

Any ideas?

Mat

Hi,

We are occasionally experiencing a crash using tbb:parallel_pipeline that I'm hoping someone can help me narrow down.  Any help, or suggestions for additional areas to check, would be greatly appreciated.

#0 0x00007f74b6311425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f74b6314b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f74b6c0cb05 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f74b6c0ac76 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f74b6c0aca3 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f74b6c0b77f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f74ba018672 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x7f7478c18100, parent=..., child=<optimized out>)
at ../../src/tbb/custom_scheduler.h:455
#7 0x00007f74ba014356 in tbb::internal::arena::process (this=0x7f5a1adf0080, s=...) at ../../src/tbb/arena.cpp:106
#8 0x00007f74ba013a7b in tbb::internal::market::process (this=0x7f74b2cf1b00, j=...) at ../../src/tbb/market.cpp:479
#9 0x00007f74ba00fa0f in tbb::internal::rml::private_worker::run (this=0x7f74af81af00) at ../../src/tbb/private_server.cpp:283
#10 0x00007f74ba00fc09 in tbb::internal::rml::private_worker::thread_routine (arg=<optimized out>) at ../../src/tbb/private_server.cpp:240
#11 0x00007f74b8426e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#12 0x00007f74b63ceccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000000000 in ?? ()

The crash is happening when trying to invoke a pure virtual function execute() on a task pointer:

customer_scheduler.h:455:
t_next = t->execute();

We run this pipeline with 4 outstanding tasks and 4 filters.  The first and last filters are very fast, the second filter is the slowest, and the third filter is about 1/5th the second filter.

tbb::parallel_pipeline(4,
     tbb::make_filter<void, long>(tbb::filter::serial_in_order,
        [&] (tbb::flow_control& fc) -> long
        {...}& tbb::make_filter<long, long>(tbb::filter::parallel,
            [&] (long& offset) -> long
        {...}& tbb::make_filter<long, long>(tbb::filter::parallel,
            [&] (long& r) -> long
        {...}& tbb::make_filter<long, void>(tbb::filter::serial_out_of_order,
        [&] (long& count)
        {...}
     );

About 5 million elements are generated from the first pipeline stage.  We've noticed that each time the crash happens, it is always with 4 elements left in the pipeline-- 1 waiting to execute on 3rd stage, 3 waiting to enter 4th stage.  We are of course critically interrogating our filter code, but this common theme of 4 elements remaining lead us to suspect the pipeline.

We are running tbb 4.2.  We have not seen this on 4.3, but we also don't consider our current testing to date on 4.3 conclusive to say that we won't see it on 4.3 in the future.

Below are two additional stacktraces for non-idle tbb threads at this time:

This thread appears to have just finished a task:

#0  0x00007f74b63caee9 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f74ba00f888 in futex_wakeup_one (futex=0x7f74af81a1ac) at ../../include/tbb/machine/linux_common.h:77
#2  V (this=0x7f74af81a1ac) at ../../src/tbb/semaphore.h:225
#3  notify (this=0x7f74af81a1a0) at ../../src/rml/include/../server/thread_monitor.h:250
#4  wake_or_launch (this=0x7f74af81a180) at ../../src/tbb/private_server.cpp:322
#5  tbb::internal::rml::private_server::wake_some (this=<optimized out>, additional_slack=<optimized out>, additional_slack@entry=0) at ../../src/tbb/private_server.cpp:401
#6  0x00007f74ba00fb88 in propagate_chain_reaction (this=<optimized out>) at ../../src/tbb/private_server.cpp:174
#7  tbb::internal::rml::private_worker::run (this=0x7f74af81ac80) at ../../src/tbb/private_server.cpp:291
#8  0x00007f74ba00fc09 in tbb::internal::rml::private_worker::thread_routine (arg=<optimized out>) at ../../src/tbb/private_server.cpp:240
#9  0x00007f74b8426e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007f74b63ceccd in clone () from /lib/x86_64-linux-gnu/libc.so.6

This is the thread calling tbb::parallel_pipeline:

#0  0x00007f74ba00b7f9 in tbb::internal::stage_task::execute (this=0x7f73e88189c0) at ../../src/tbb/pipeline.cpp:363
#1  0x00007f74ba018672 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x7f5a1addc100, parent=..., child=<optimized out>)
    at ../../src/tbb/custom_scheduler.h:455
#2  0x00007f74ba016ad0 in tbb::internal::generic_scheduler::local_spawn_root_and_wait (this=0x7f5a1addc100, first=..., next=@0x7f5a1add6838: 0x7f5a1add69c0) at ../../src/tbb/scheduler.cpp:668
#3  0x00007f74ba00c621 in spawn_root_and_wait (root=...) at ../../include/tbb/task.h:705
#4  tbb::pipeline::run (this=this@entry=0x7f591efde000, max_number_of_live_tokens=max_number_of_live_tokens@entry=4, context=...) at ../../src/tbb/pipeline.cpp:666
#5  0x0000000000ba48a9 in parallel_pipeline (context=..., filter_chain=..., max_number_of_live_tokens=4) at /opt/sfdev-6.28/include/tbb/pipeline.h:654
#6  parallel_pipeline (filter_chain=..., max_number_of_live_tokens=4) at /opt/sfdev-6.28/include/tbb/pipeline.h:660

Thanks!

Jared

I had successfully compiled my code 6 months back with TBB version 3, but now when I try with version 4 or 3, it gives the errors as shown below.
Please help, as I'm stuck with this for 4 days already.

Am using Linux localhost.localdomain 2.6.32-431.el6.x86_64
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)

TBB version 4:
On using /usr/local/tbb43_20150316oss/include
/usr/local/tbb43_20150316oss/lib/intel64/gcc4.4/libtbb.so

g++ -c -g -Iinclude -I../Estimator/include -I/opt/intel/composer_xe_2015.2.164/mkl/include -I/usr/local/tbb43_20150316oss/include -MMD -MP -MF build/Debug/GNU-Linux-x86/source/Group.o.d -o build/Debug/GNU-Linux-x86/source/Group.o source/Group.cpp
In file included from /usr/local/tbb43_20150316oss/include/tbb/concurrent_hash_map.h:47,
from /usr/local/tbb43_20150316oss/include/tbb/tbb.h:42,
from source/Group.cpp:17:
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:270: error: ‘__TBB_FORWARDING_REF’ has not been declared
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:270: error: expected ‘,’ or ‘...’ before ‘t’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:286: error: expected nested-name-specifier before ‘__TBB_PARAMETER_PACK’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:286: error: expected ‘>’ before ‘Args’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: ‘Args’ was not declared in this scope
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: there are no arguments to ‘__TBB_FORWARDING_REF’ that depend on a template parameter, so a declaration of ‘__TBB_FORWARDING_REF’ must be available
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: expected ‘)’ before ‘__TBB_PARAMETER_PACK’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: ISO C++ forbids initialization of member ‘create_node_v’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: making ‘create_node_v’ static
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:287: error: template declaration of ‘tbb::interface5::internal::split_ordered_list::node* tbb::interface5::internal::create_node_v’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h: In member function ‘tbb::interface5::internal::split_ordered_list::node* tbb::interface5::internal::split_ordered_list::create_node(tbb::interface5::internal::sokey_t, int (*)(Arg))’:
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:275: error: ‘forward’ is not a member of ‘tbb::internal’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:275: error: expected primary-expression before ‘>’ token
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:275: error: ‘t’ was not declared in this scope
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h: At global scope:
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: expected primary-expression before ‘)’ token
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: there are no arguments to ‘__TBB_FORWARDING_REF’ that depend on a template parameter, so a declaration of ‘__TBB_FORWARDING_REF’ must be available
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: expected ‘)’ before ‘value’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: expected primary-expression before ‘pnode’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: ISO C++ forbids initialization of member ‘internal_insert’
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: making ‘internal_insert’ static
/usr/local/tbb43_20150316oss/include/tbb/internal/_concurrent_unordered_impl.h:1288: error: template declaration of ‘std::pair::iterator, bool> tbb::interface5::internal::internal_insert’
In file included from /usr/local/tbb43_20150316oss/include/tbb/flow_graph.h:2910,
from /usr/local/tbb43_20150316oss/include/tbb/tbb.h:53,
from source/Group.cpp:17:
/usr/local/tbb43_20150316oss/include/tbb/internal/_flow_graph_indexer_impl.h:37: error: expected ‘>’ before numeric constant
gmake[2]: *** [build/Debug/GNU-Linux-x86/source/Group.o] Error 1
gmake[2]: Leaving directory `/home/nkipe/NetBeansProjects/Assoc'
gmake[1]: *** [.build-conf] Error 2
gmake[1]: Leaving directory `/home/nkipe/NetBeansProjects/Assoc'
gmake: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 9s)

----------------------------------------------------------------------------------------------------------------------------------------

TBB version 3
On trying /usr/local/tbb30_20100406oss/lib/intel64/cc4.1.0_libc2.4_kernel2.6.16.21/libtbb.so and /usr/local/tbb30_20100406oss/include

g++ -o dist/Debug/GNU-Linux-x86/Assoc build/Debug/GNU-Linux-x86/source/AssignmentPair.o build/Debug/GNU-Linux-x86/source/Assoc.o build/Debug/GNU-Linux-x86/source/CoordinateConversion.o build/Debug/GNU-Linux-x86/source/DummyPredictedTrack.o build/Debug/GNU-Linux-x86/source/GateInfo.o build/Debug/GNU-Linux-x86/source/GenerateCostMatrix.o build/Debug/GNU-Linux-x86/source/Group.o build/Debug/GNU-Linux-x86/source/GroupHypo.o build/Debug/GNU-Linux-x86/source/GroupNode.o build/Debug/GNU-Linux-x86/source/Hungarian.o build/Debug/GNU-Linux-x86/source/Hypo.o build/Debug/GNU-Linux-x86/source/LapJv.o build/Debug/GNU-Linux-x86/source/Main.o build/Debug/GNU-Linux-x86/source/Measurement.o build/Debug/GNU-Linux-x86/source/MergeGroup.o build/Debug/GNU-Linux-x86/source/Mht.o build/Debug/GNU-Linux-x86/source/MhtProcessingThread.o build/Debug/GNU-Linux-x86/source/MhtSendThread.o build/Debug/GNU-Linux-x86/source/Murty.o build/Debug/GNU-Linux-x86/source/PlotAsterixDecoder.o build/Debug/GNU-Linux-x86/source/ReceiveData.o build/Debug/GNU-Linux-x86/source/SplitGroup.o build/Debug/GNU-Linux-x86/source/Track.o build/Debug/GNU-Linux-x86/source/TrackAsterix.o build/Debug/GNU-Linux-x86/source/UdpServer_.o ../Estimator/dist/Debug/GNU-Linux-x86/libestimator.a /opt/intel/mkl/lib/intel64/libmkl_rt.so /usr/local/tbb30_20100406oss/lib/intel64/cc4.1.0_libc2.4_kernel2.6.16.21/libtbb.so /usr/local/tbb30_20100406oss/lib/intel64/cc4.1.0_libc2.4_kernel2.6.16.21/libtbbmalloc.so
build/Debug/GNU-Linux-x86/source/Assoc.o: In function `~parallel_do_feeder_impl':
/usr/local/tbb30_20100406oss/include/tbb/parallel_do.h:189: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
build/Debug/GNU-Linux-x86/source/Group.o: In function `~task_group':
/usr/local/tbb30_20100406oss/include/tbb/task_group.h:164: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
/usr/local/tbb30_20100406oss/include/tbb/task_group.h:168: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
build/Debug/GNU-Linux-x86/source/Group.o: In function `~parallel_do_feeder_impl':
/usr/local/tbb30_20100406oss/include/tbb/parallel_do.h:189: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
build/Debug/GNU-Linux-x86/source/Mht.o: In function `~parallel_do_feeder_impl':
/usr/local/tbb30_20100406oss/include/tbb/parallel_do.h:189: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
build/Debug/GNU-Linux-x86/source/Mht.o:/usr/local/tbb30_20100406oss/include/tbb/parallel_do.h:189: more undefined references to `tbb::interface5::internal::task_base::destroy(tbb::task&)' follow
collect2: ld returned 1 exit status
gmake[2]: *** [dist/Debug/GNU-Linux-x86/Assoc] Error 1
gmake[2]: Leaving directory `/home/nkipe/NetBeansProjects/Assoc'
gmake[1]: *** [.build-conf] Error 2
gmake[1]: Leaving directory `/home/nkipe/NetBeansProjects/Assoc'
gmake: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 38s)

This Beta release of the Intel® Parallel Studio XE 2016 introduces a major change to the 'Named-user' licensing scheme (provided as default for the 2016 Beta licenses).  Read below for more details on this new functionality as well as a list of special exceptions.  Following a thorough Beta testing period, implementation will carry forward into the product release.

Description of changes:

The ‘Named-user’ license provisions in the Intel software EULA have changed to only allow the software to be installed on up to three systems.  During the Intel® Parallel Studio XE 2016 Beta program, product licensing will be updated to check for this when it checks for valid licenses, and it will track systems by the system host ID.  The installer will automatically detect the host ID and create the appropriate license.  If your system cannot access the internet during install-time, you will need to manually create a host-specific Beta license.  For more details on how to determine the host ID on your machine, follow the directions in this article.

We would love to get your feedback on this new license scheme. If you reach the allowable number of activations or have other 'Named-user' license problems, please contact us at the Intel® Premier Customer Support website. You will also be asked to complete a Beta survey at the end of the Beta program where you can give some final thoughts on this new functionality.

Limitations:

Using this new 'Named-user' license scheme may not be possible in one of the following cases:

• Doing a distributed cluster install of the Beta software on a cluster with more than 3 nodes
  • NOTE: You will only hit this issue if the directory where the Beta tools are being installed is not NFS-mounted across the cluster and a distributed installation is required
• Installation of the following stand-alone packages:
  • Intel® Advisor XE Beta (Linux*, Windows*)
  • Intel® VTune™ Amplifier XE Beta - OS X* host only
  • NOTE: You will only hit this issue if installing the stand-alone packages.  This does not affect installation of these individual components when done via the Intel Parallel Studio XE 2016 Beta installer.

Workaround:

We expect that the new 'Named-user' license scheme will work in the majority of installation cases.  If you encounter either of the situations described previously, you can easily replace the default 'Named-user' license provided during the Beta with a new license for manual offline installation.

In order to do this, return to the Intel® Parallel Studio XE 2016 Beta registration page and select the first option ("Generate license for manual offline installation") under the Email field:

Enter your email address and select the "Continue" button.  A new license file will be emailed to you.  You do NOT have to download the packages again.