Feature Request: A different dll-naming for the TBB DLLs on Windows platforms

[SergeyKostrov]

This is a Feature Request:

It would be nice to consider a different dll-namingforTBB's DLLs on Windows platforms.

Here is an example for Win32 platforms:

Debug Configuration:

tbb_debug.dll -> tbbd.dll
tbb_debug.dll ( MT ) -> tbbmtd.dll

Release Configuration:

tbb.dll -> tbb.dll
tbb.dll ( MT ) -> tbbmt.dll

and

Here is an example for Win64 platforms:

Debug Configuration:

tbb_debug.dll -> tbb64d.dll
tbb_debug.dll ( MT ) -> tbb64mtd.dll

Release Configuration:

tbb.dll -> tbb64.dll
tbb.dll ( MT ) -> tbb64mt.dll

Note: MT - Multi-Threaded

[RafSchietekat]

OK, I'll bite: what is non-multithreaded TBB?

[SergeyKostrov]

>>...I'll bite...

Sir,

You must definitely watch your language! As an Intel'sBlack Belt Software Developeryour comment is simply NOT appropriate and disrespectful.

I expect that a moderator of the Intel Software Network forum will take some actions.

Thank you in advance.

Best regards,
Sergey

[ARCH_R_Intel]

Raf is not showing any disrespect. He used an idiomatic English expression that roughly means "I don't understand, so here is a clarifying question." I can see where literal translation could be trouble. Natural language is not as regular as C++.

Like Raf, I'm wondering what a non-multithreaded TBB would be. Just single-threaded versions of the algorithms and containers?

[SergeyKostrov]

>>...Just single-threaded versions of the algorithms and containers?..

No. It refers to a C Run-Time library selected for an application or a DLL in case of development with
VS 20xx on Windows platforms.

Here are some technical details:

\Changes

...
TBB 2.2 Update 2 commercial-aligned release

Changes (w.r.t. TBB 2.2 Update 1 commercial-aligned release):

...
- Building TBB with /MT is supported, to avoid dependency on particular
versions of Visual C++* runtime DLLs. TBB DLLs built with /MT
are located in vc_mt directory.
...

and, take a look at a screenshot:

[Vladimir_P_1234567890]

hello all,

The last several versions of visual studio starting version 2005 ship multi-threaded C runtime only. /MT and /MD switches stand for static (.lib) and dynamic (.dll) C runtimerespectively. Earlier there was an option /ML to link with single threaded C runtime statically.

More details can be found herehttp://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(VC.PROJECT.VCCLCOMPILERTOOL.RUNTIMELIBRARY)&rd=true

As far as you can see CHANGES file does not contain MT but /MT only.
So MT in the starting post should be treated as Note: with /MT - using static C runtime.

thank you.
--Vladimir

[Vladimir_P_1234567890]

Quoting Sergey Kostrov

This is a Feature Request:

It would be nice to consider a different dll-namingforTBB's DLLs on Windows platforms.

Hello Sergey,

What is a way in your proposal to avoid oversubcription in case different modules or plug-ins use different versions of TBB? Now it is solved by using the latest one TBB library across all modules in application.

Thanks.
--Vladimir

[SergeyKostrov]

Hi Vladimir,

>>...What is a way in your proposal to avoid oversubcription in case different modules or plug-ins use
>>different versions of TBB?..

My proposal is not related to any internal functionality of TBB. It is related to DLL namingonly and nothing else.

For example,if I work with 'tbb.vcproj' I could compile 4 differentDLLs:

- Debug Configuration - CRT Library -> Multi-Threaded Debug DLL ( /MDd ) - DLL name: tbb_debug.dll
- Debug-MT Configuration -CRT Library -> Multi-Threaded Debug( /MTd ) - DLL name: tbb_debug.dll
-Release Configuration -CRT Library -> Multi-ThreadedDLL ( /MD ) - DLL name: tbb.dll
- Release-MT Configuration -CRT Library -> Multi-Threaded( /MT ) - DLL name: tbb.dll

As you can seeDLL names are the same for Debug and Debug-MT configurations, and for Release and Release-MT configurations.

My proposal is tochangeDLL names to:

- Debug Configuration - CRT Library -> Multi-Threaded Debug DLL ( /MDd ) - DLL name: tbbd.dll
- Debug-MT Configuration -CRT Library -> Multi-Threaded Debug( /MTd ) - DLL name: tbbmtd.dll
-Release Configuration -CRT Library -> Multi-ThreadedDLL ( /MD ) - DLL name: tbb.dll
- Release-MT Configuration - CRT Library -> Multi-Threaded( /MT ) - DLL name: tbbmt.dll

It means, that I'll be able to move these 4 DLLs to one folder, for example:

..\BinWin32\
tbbd.dll
tbbmtd.dll
tbb.dll
tbbmt.dll

For libraries:

..\LibWin32\
tbbd.lib
tbbmtd.lib
tbb.lib
tbbmt.lib

Also, the same rulecould be applied to64-bit DLL & LIBnames.

It will simply eliminate some confusion regarding TBB DLLs & LIBscompiled in two different configurations
that have identical names.

Best regards,
Sergey

[SergeyKostrov]

I missed the 2nd part of the question...

>>...What is a way in your proposal to avoid oversubcription in case different modules or plug-ins use
>>different versions of TBB?..

Ideally,it has to be avoided. I think it is all about versioning of software modules.

Best regards,
Sergey

PS:
In case of our software development environment there is astrict rule:

Only One Version of some DLL must be used all over the projects. No Exceptions.

I know, that in some cases it is hard to achieve, especially if there is a big projectin abig company. It is much easier to achieve with a small software company.

[nagy]

How does this conflict with tbbs existing naming conventions? If you want to have /MT linking, then just build tbb and name it with your proposed extra "m" in the name.

[SergeyKostrov]

>>...How does this conflict with tbbs existing naming conventions?..

Explained in the Post #7.

[Alexey-Kukanov]

I understand the naming confusion, however we will not do renaming of any kind, at least not in any near future. We want TBB to be a process-wide singleton, andto our knowledge the only reliable and secure way to approach that on Windows is to use a DLL. Naming DLLs differently (in any way - including version, bitness, dependence on VC, etc) would open a door to have multiple different TBB copies in the same process, just because different application modules (incl. 3rd party libraries, plugins etc.) might use differently named TBB DLLs. Maybe in the futureif we find a non-DLL-based way to implement a reliable and secure singleton we will considerchanging the naming schema.