What's an optimal use of storage duration specifier with TBB ?

[bp]

Hi,

I was wondering how the internals of TBB work and how I can optimize the storage duration of my code.

Assuming that I'm coding in C++11 and I'm using a lot of parallel_* constructs like parallel_for or parallel_for_each, how TBB handles the same object accessed by multiple threads and how it avoids cache misses, it's a good idea to make thread_local anything I'll pass through TBB functions ?

for example imagine that I have a function foo() that gives me a pseudo-random int everytime it's called, inside foo there are 2 main objects like the mersenne standard implementation std::mt19937 and the std::uniform_int_distribution, It's good to use thread_local here ? It's better to use something else ? How about a data race or cache misses in TBB ?

[jimdempseyatthecove]

Pseudo random number generators are problematic in multi-threaded implimentations. These generators are typically written for use by single threaded applictions. Multi-threaded modifications to these generators typically involved adding a critical section. While this fixes potential corruption of seed, it will not resolve the issue that sequence that the threads enter the critical section is the same on every run. Thus the individual threads may receive different sequences each time you run the program. This issue is compounded when you call any of the "standard" distribution libraries. As they do not and canno assure sequence of entering the RNG.

Using a thread private modifiec RNG (to hold seed/last random number), is not a good fix because the sequence experienced in serial run will not be the same for parallel run. Your best bet here is to insert a section of code in front of the parallel region, whereby the master thread creates a list of random numbers to be used by all subsequent team members for their portion of the work. This is rather difficult to do in TBB, less so difficult to do in OpenMP.

Jim Dempsey

[bp]

jimdempseyatthecove wrote:

Pseudo random number generators are problematic in multi-threaded implimentations. These generators are typically written for use by single threaded applictions. Multi-threaded modifications to these generators typically involved adding a critical section. While this fixes potential corruption of seed, it will not resolve the issue that sequence that the threads enter the critical section is the same on every run. Thus the individual threads may receive different sequences each time you run the program. This issue is compounded when you call any of the "standard" distribution libraries. As they do not and canno assure sequence of entering the RNG.

Using a thread private modifiec RNG (to hold seed/last random number), is not a good fix because the sequence experienced in serial run will not be the same for parallel run. Your best bet here is to insert a section of code in front of the parallel region, whereby the master thread creates a list of random numbers to be used by all subsequent team members for their portion of the work. This is rather difficult to do in TBB, less so difficult to do in OpenMP.

Jim Dempsey

I understand what you are saying here, if I feed my PRNG function to 4 threads I basically get 4 different behaviours and the overall result it's not what I should expect and it's not consistent.

But I would like to keep this as a starting example, I'm interested more in how to treat generic methods or variables and how to be sure that they are managed the right way from the memory model.