Incompatible versions of TBB with third party software

[romko]

Hi,

My application is lonked against TBB version 2.2. In one usage scenario my application is called from third party app via in-process COM interface. Unfortunately this third party software uses TBB version 2.1, which is binary incompatible with 2.2. As result, communication via COM fails and my application won't load. My application _have_ to be called in-process (if it were out-of-process, no conflict would arise).

Currently I use commercially aligned release.

Do I have any other options, then getting TBB Source and to rebuild TBB's DLLs and LIBs under anothor name and relink the whole application against it? Will I have problems when TBB machinery will be initialized twice in a same Process?


Thanks!

[romko]

It seems that the discussion is related to the same problem:

http://stackoverflow.com/questions/315285/can-i-use-two-incompatible-versions-of-the-same-dll-in-the-same-process

Still looking for the best solution ...

[Vladimir_P_1234567890]

can both application use tbb 2.2? tbb is backward binary compatible.

--Vladimir

[romko]

The problem is, that caller (third party software which I cannot change) uses 2.1, and I use 2.2 (or 3.x in later releases). So the process loads 2.1 first and then my application via in-process COM which uses version > 2.1.

[Customer__Intel6]

I have had similar issues with other third party C++ libraries (boost, ACE). I have not had a similar issue with tbb yet.

ACE being more multiplatform and the oldest had the cleanest workaround. The libraries are built wth version numbers in their names (similar strategy as Microsoft with their C Runtimes). In addition for compile time compatibility, the namespace used is defined in a macro that can be renamed and aliased globally. You need both these steps so that the symbol names for the two versions are separate and are found in separate DLLs and they can both co-exist in the same process.

I think tbb should provide similar override mechanisms -- update the makefiles to generate the library version numbers in the DLL/so names and additionally make the namespace globally configurable.

[Alexey-Kukanov]

We do not want multiple TBB copies to be used in the same process. Multiple copies mean multiple thread pools, task pools, memory pools - and so significantly worse composability. For a DLL that manages global resources, such as TBB, it is important to have just one copy.

Generally, our answer is backward compatibility: if one can make sure that the most recent version of TBB is loaded first, it should"just work" even if some client modules depend on an earlier version. For incompatible implementation changes, we use symbol versioning too, including versioned namespaces. But old symbols are still available and work.

I understand however that it's not always possible to make sure the most recent TBB is loaded. We provide some support to identify such a situation, e.g TBB_runtime_interface_version() function can be used to retrieve the version of the TBB DLL, and do some dispatching. Unfortunately, that might not work as well.

We are working on providing programmers with more control over which TBB DLL is used, but it's not yet available. For now, I can suggest following approaches:
1) simple - switch back to TBB 2.1;
2) complex - don't make your main module to depend on TBB, except maybefor TBB_runtime_interface_version() which should be satisfied by TBB 2.1 (at least starting from a certain update). Encapsulate all work with TBB in a separate DLL that you could load at runtime using LoadLibrary. Your main module then detects whether the TBB version in the process address space satisfies the requirements, and if yes it loads the TBB dependent module to do the job, otherwise it can fall back to a sequential implementation, or fail gracefully. Also for LoadLibraryExyou can specify a flag to look for all DLL dependencies next to the DLL itself, which possibly can help to load the appropriate version of TBB.