andeb wrote:Thanks for the info. I wasn't really aware of the stack and heap so I read about it. Interesting!
I am glad that what I wrote was of some help.
Christian understand using C++ and OpenMP very well. He has been doing it for years and is greatly responsible for most of the C++ enhancements being made to OpenMP Version 3.
In there, it is explained that a function can be thread-safe only if it uses variables from the stack. Does it mean I can't dynamically allocate my arrays & objects? Actually, my parralelized loop has an embedded function that declares a slew of pointers
of c++ objetcts ...
In the article above, it is also says that
"Using pointers you can get access to everything – but that is not allowed by the OpenMP specification and therefore the behavior is undefined"
Not totally true. Shared variables can be used in thread-safe routines with restrictions. You can read shared variables without any problem. However, if any routine updates a shared variable, then all accesses have to be "protected". By "protected" I mean you have to use critical, atom, or locks. Your routines can also update different sections of a shared array without any problem.
C++ objects however, can be a problem. For example, if you have a list object. Internal to the list implementation, information is kept about the number of elements in the list (for example). If two routines both try and update the list, then depending on the implementation, it might not work. The problem is, that to do the update correctly, a lock has to be added around the update to the number of items in the list. For serial programs, this is added overhead that most people don't want. For parallel programs, it is a necessity. So, if you have a shared object, to be thread-safe, you are most likely going to have to "protect" the list update.
As for the statement about using pointers, the OpenMP specification does limit their behavior. However, an implementation of OpenMP most likely doesn't. The problem is, that from a user's perspective, we want to say that private data (data declared in a private clause) is private to a thread (or task). However, the user could use a pointer to update it from a different thread - because the base languages allow this (since the language really doesn't know anything about OpenMP). The statement is really there to make sure that the user thinks about what they are doing (if you are going to play with fire you might get burned and we can't help that).
andeb wrote:Do you agree with that statement? Can a loop be parallelized if there is usage of pointers of objects?
Should I rather create a separate executable with that function and call that executable in the parallelized loop. (in which case the memory would be released without burden)
So the answer is, that you can parallelize loops with pointers or objects. You just have to be careful and you might not get as much benefit as you were hoping for.