Are the local variables in global function shared among different threads?

[timminn]

If a global function is invoked concurrently by many task objects, then are the local variables in global function shared among different threads, which isa good chance for race problem?

If the answer is no, please expain in detail.

How about the local variables in a member function [NOT data member] of a task object? If there are several task objects invoking the same member function of theirs, is here any race prolem about the local variables?

[robert-reed]

Functions, whether global, static or member, all have local variables that by default are in the automatic storage class, which means they have a lifetime that runs the duration of the function call: they are created on a stack when the function is called and go away when the function exits. As such, they are private to the function. If that function is called simultaneously in several threads, each will have its own copy of the variables so it is unlikely they would be culprits in some race condition. If you change the storage class of a local variable (by declaring it static, for example), you can change the lifetime and the scope of the variable and may well make it available for races between threads.

This should be true whether you use pthreads, Win32/COM threads, or .NET System.Threading. The only place you might run into race problems with function local variables is if the parallelism is injected as part of the function, say an OpenMP parallel for construct. There you might have local function variables that are referenced in the code that makes use of an OpenMP thread team. You can fix that for OpenMP by declaring those variables as private within the OpenMP construct.

However, this is the Intel TBB Forum, and you'll notice that this is the first time in this post that I've mentioned TBB. The comments I made above have general application and TBB being a regular C++ library, abides by those rules just like any other library.