Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

DLL hell

jogshy
New Contributor I
727 Views
Please, name the TBB's DLLs as:

{name=tbb}-{debug flag}-{versionMajor}.{versionMinor}.{versionRevision}-{VisualStudioVersion}-{CRC64 hash}.dll
( for instance, tbb-debug-3.0.1-VC9-BAADCAFEDEADBEEF.dll )

as Microsoft does with the WinSxS, as .NET performs versioning for its assemblies or as linux names the libraries by default. In that way we can skip the DLL hell and to perform versioning-resistant deployment properly:

http://en.wikipedia.org/wiki/DLL_hell

0 Kudos
5 Replies
smasherprog
Beginner
727 Views
This has been something I wished that tbb would embrace. I have had a few mixups with the dlls because the names are the same. I dont see why new releases could be changed in this manner, and leave the older versions untouched. Doesnt seem like there could be any issuess.
0 Kudos
RafSchietekat
Valued Contributor III
727 Views
The big issue is that this would cause multiple schedulers (etc.?) to be instantiated and used, and even if your code happened to not interfere to crash the program you would still face oversubscription issues (too many threads adversely affecting performance).
0 Kudos
Alexey-Kukanov
Employee
727 Views
We don't do name versioning for the same reasons why we don't provide static libraries - we believe it is better to avoid having several versions of TBB in the same process, which would happen easily if there were differently named DLLs, or static libraries.

As TBB is nota system-wide DLL neither does it require any system-wide settings (registry etc), for most apps it is sufficient to place it next to the executable, and have no DLL hell issues. In terms of the mentioned Wikipedia article, TBB is best used as"private library" and is suitable for "stand-alone" and "portable" applications.

For libraries or plug-ins, which developersby definition cannot control the whole app, problems can arise at runtime if the host application (or another module of it) has first loaded an older version of TBB into the process. Loading a newer version first should be OK because we take care for backward compatibility of TBB binaries. However at least in the Windows world, a certain effort of *application developers* can help to minimize or avoid issues. For dynamically opened libraries/plug-ins, there is a way to tell the loader that search for the library dependencies should start next to the library itself. So if an application loads its plug-ins that way, then all dependency DLLs including TBB can reside next to the main plugin DLL, much like a standalone application. For libraries loaded at application startup, the app developers can make sure that the most advanced version of TBB will be available.

Meanwhile we are working on a solution that will provide some additional control on which version of TBB to use.
0 Kudos
jogshy
New Contributor I
727 Views
Even when the TBB's dynamic libraries are designed to be used as private assembly, it should be good to name as I indicate just to avoid problems ( for instance, to avoid a possible confusion copying them to my app's folder or to overwrite them properly ). In that way you'll have all more sorted and clean.
0 Kudos
Alexey-Kukanov
Employee
727 Views
To repeat, we think it's bad to name as you indicated because it potentially creates resource usage/performance problems for customers and undermines some of TBB value proposition.
0 Kudos
Reply