Provide thread private preallocated buffer to a parallelized for() loop? - c++

Question

My program contains a for() loop that processes some raw image data, line by line, which I want to parallelize using OpenMP like this:
...
#if defined(_OPENMP)
int const threads = 8;
omp_set_num_threads( threads );
omp_set_dynamic( threads );
#endif
int line = 0;
#pragma omp parallel private( line )
{
// tell the compiler to parallelize the next for() loop using static
// scheduling (i.e. balance workload evenly among threads),
// while letting each thread process exactly one line in a single run
#pragma omp for schedule( static, 1 )
for( line = 0 ; line < max; ++line ) {
// some processing-heavy code in need of a buffer
}
} // end of parallel section
....
The question is this:
Is it possible to provide an individual (preallocated) buffer (pointer) to each thread of the team executing my loop using a standard OpenMP pragma/function (thus eliminating the need to allocate a fresh buffer with each loop)?
Thanks in advance.
Bjoern

Answer 1

I may be understanding you wrong, but I think this should do it:
#pragma omp parallel
{
unsigned char buffer[1024]; // private
// while letting each thread process exactly one line in a single run
#pragma omp for // ... etc
for(int line = 0; line < max; ++line ) {
//...
}
}
If you really meant you want to share the same buffer for different parallell blocks, you'll have to resort to thread-local storage. (Boost as well as C++11 have facilities for making that easier to do (more portably too) than directly using TlsAlloc and friends).
Note that this approach replaces some of the thread-safety checking burden back on the programmer because it is perfectly possible to have different omp parallel sections running at the same time, especially when they are being nested.
Consider that parallel blocks could be nesting at runtime, even though they are not lexically nested. In practice that is usually not good style - and often results in poor performance. However, it is something you need to be aware of when doing this).

Answer 2

There is threadprivate: http://msdn.microsoft.com/en-us/library/2z1788dd
static int buffer[BUFSIZE];
#pragma omp threadprivate(buffer)
This pragma works on a global/static variable, so you don't need to worry about the stack overflow. (In such a stack-overflow case, it's not a bad idea at all to increase the stack size by tweaking linker option.)
Note that compilers may have different implementation details for threadprivate. For example, VS 2010 compiler can't do make threadprivate if the variable has a constructor. However, Intel C/C++ compiler does this job greatly.
Using separate omp parallel and omp for is also good idea as sehe showed it. However, using threadprivate allows you to use omp parallel for directly.
FYI: Even if you need to allocate your own thread-local storage, in many case you don't actually need to call an OS-specific function call such as TlsAlloc. You may simply allocate an array of N of the data structures. And, then access them by using omp_get_thread_num that gives thread ID from 0 to N-1. Of course, you must consider false sharing by inserting a padding to ensure each data structure should be aligned to a different cache line (mostly modern CPU caches have 64-byte cache line).