C++ local variables and threads (not thread_local)

Question

What are the C++98 and C++11 memory models for local arrays and interactions with threads?

I'm not referring to the C++11 thread_local keyword, which pertains to global and static variables.

Instead, I'd like to find out what is the guaranteed behavior of threads for arrays that are allocated at compile-time. By compile-time I mean "int array[100]", which is different to allocation using the new[] keyword. I do not mean static variables.

For example, let's say I have the following struct/class:

struct xyz { int array[100]; };

and the following function:

void fn(int x) {
  xyz dog;
  for(int i=0; i<100; ++i)  { dog.array[i] = x; }
  // do something else with dog.array, eg. call another function with dog as parameter
  }

Is it safe to call fn() from multiple threads? It seems that the C++ memory model is: all local non-static variables and arrays are allocated on the stack, and that each thread has its own stack. Is this true (ie. is this officially part of the standard) ?

Answer 1

Such variables are allocated on the stack, and since each thread has its own stack, it is perfectly safe to use local arrays. They are not different from eg local int s.

Answer 2

C++98 didn't say anything about threads. Programs otherwise written to C++98 but which use threads do not have a meaning that is defined by C++98. Of course, it's sensible for threading extensions to provide stable, private local variables to threads, and they usually do. But there can exist threads for which this is not the case: for instance processes created by vfork on some Unix systems, whereby the parent and child will execute in the same stack frame, since the v in vfork means not to clone the address space, and vfork does not redirect the new process to a different function, either.

In C++11, there is threading support. Local variables in separate activation chains in separate C++11 threads do not interfere. But if you go outside the language and whip out vfork or anything resembling it, then all bets are off, like before.

But here is something. C++ has closures now. What if two threads both invoke the same closure? Then you have two threads sharing the same local variables. A closure is like an object and its captured local variables are like members. If two or more threads call the same closure, then you have a de facto multi-threaded object whose members (ie captured lexical variables) are shared.

A thread can also simply pass the address of its local variables to another thread, thereby causing them to become shared.