2

I recently read this question How to statically link to TBB? and I still don't really understand the problems with using tbb as a statically linked library (which is possible with their makefile if you do make extra_inc=big_iron.inc tbb)

The answer seems to say that the problem is that there can be multiple singletons in a single program, all (most?) implementations of a singletons don't let that happen. I don't understand the reasoning behind this.

Is the problem that when you fork() another process the singleton becomes two separate singletons in two separate processes? Is that what they mean by "program"? Also if thats the case why can they not mmap() shared memory and use that as the communication medium?

Also doesn't dynamically linking only mean that the library itself is shared in memory, i.e. the code segment?

Thanks!

Community
  • 1
  • 1
Curious
  • 20,870
  • 8
  • 61
  • 146

1 Answers1

7

No, the singleton explanation refers to a single process, not the multiple processes case (though, it has some of the same issues with oversubscription and load balancing).

Dynamic linker makes sure there is only one global data section exists for the library and calls global constructors exactly once implementing singleton.

With statically linked TBB library, one can end up with multiple instances of TBB thread pool working in the same process simultaneously, which come from different components of an application. This causes the issue of over-subscription or even worse if somehow a memory or some object being allocated and registered in one instance of the scheduler gets used in another instance of the scheduler. This is especially easy to achieve because of thread-local storage that is heavily used by TBB scheduler. Each instance of the scheduler would use separate TLS breaking rules of nested parallelism up to deadlock and enabling memory leaks and segfaults because tasks allocated in one scheduler might end up being returned to another scheduler. Thus, this situation might not be obvious for developers who don't even intend to pass objects between module boundaries.

Sometimes, such a situation happens even with dynamic linkage when e.g. TBB shared library is renamed for one of application components. TBB team is working to solve this issue.

Anton
  • 6,349
  • 1
  • 25
  • 53
  • "This is especially easy to achieve because of thread-local storage that is heavily used by TBB scheduler." I don't think running a library that is meant for efficient multithreaded access should have problems running in multithreaded environments. Could you give an example of what you mean? – Curious Mar 07 '17 at 03:34
  • A task can be executing in context of one scheduler but calling a function from another module which accesses different TLS and it provokes another instance of the scheduler to consider this thread as user thread and thus apply different rules than for TBB worker, it can result in the issues up to deadlock – Anton Mar 07 '17 at 03:44
  • The issue is still not clear, how will using tbb in the form of a shared library help with this? – Curious Mar 07 '17 at 04:32
  • When you use shared library, the loader usually helps to ensure tbb symbols are resolved to the only instance of the library and the scheduler respectively implwmenting singleton, only one TLS is used by the only instance of scheduler shared between all the modules of application – Anton Mar 07 '17 at 04:40
  • That is only a problem when you have multiple libraries that are both linked to tbb and then those libraries are linked together, this problem does not exist when you link tbb with a bunch of object files once. – Curious Mar 07 '17 at 04:49
  • Why again? Yes, if you controll all the components of your application and link tbb once, there should not be problems – Anton Mar 07 '17 at 04:53
  • Could you explain how the dynamic linker prevents multiple TLS instances for the same library? I will accept this answer then – Curious Mar 07 '17 at 05:38
  • 1
    It makes sure there is only one global data section exists for the library and calls global constructors exactly once implementing singleton – Anton Mar 07 '17 at 05:46
  • Sorry, I meant could you include it in the answer? – Curious Mar 07 '17 at 05:47