Do threads have their own stack?

[John E]

Or alternatively, is the stack safe in a multithreaded app (yes, I guess it must be but here's what I'm getting at - consider the following code)

int some_func()
{
static int x;

      x = call_some_other_func();

      return x;
}

I appreciate that if the above function was getting called from 2 different threads (without any thread synchronisation) it'd be a recipe for disaster because there's only one copy of 'x' being shared between two unsynchronised threads. But what if 'x' was a local variable...?

int some_func()
{
int x;

      x = call_some_other_func();

      return x;
}

Assuming that 'call_some_other_func()' was thread safe, is it safe to call the above function from two unsynchronised threads? Does each of them see a different copy of x?

[Access_Denied]

Threads share memory, and there's only one stack, so I would say the answer to your question is yes. I think you might run into problems with the static variable, but not the member variable. Threads all share the same program stack, but they keep track of what variables on the stack are theirs. So if you have 10 threads of the same function that all create a local variable 'x', there will be 10 'x' variables on the stack.

But as I said, I only think you'll run into problems with a static variable. It's very possible that you might not.

[Peter_B]

Threads share memory, and there's only one stack, so I would say the answer to your question is yes. I think you might run into problems with the static variable, but not the member variable. Threads all share the same program stack, but they keep track of what variables on the stack are theirs. So if you have 10 threads of the same function that all create a local variable 'x', there will be 10 'x' variables on the stack.

But as I said, I only think you'll run into problems with a static variable. It's very possible that you might not.

Where on earth did you hear this? Each thread has it's own stack - if it didn't you would lose the benefits of stack based allocation (i.e. last in, first out) and also where would the function call return points be stored?

Threads do share the heap though, at least typically (though someone out there may know otherwise in some instances )

[Paul McKenzie]

int some_func()
{
    int x;
    x = call_some_other_func();
    return x;
}

Assuming that 'call_some_other_func()' was thread safe, is it safe to call the above function from two unsynchronised threads?

It is safe to call. Local variables are thread safe.

Regards,

Paul McKenzie

[Codeplug]

I like the mental model of "one stack per context of execution": http://cboard.cprogramming.com/cplus...ml#post1084354

gg

[ovidiucucu]

There is clearly stated: each thread has its own stack.
So, if have a local non-static variable, we can look at it as to a different object in different fnction calls from different threads.
As Paul already said, normally there is no synchronization problem in ths case.

A static variable (we can include here the global ones) is not on the stack, then may be possible to have problems if accessing it from different threads.

Besides well known synchronization mechanisms like critical section and so on, in Windows we can use:

• InterlockedXyz functions which prevent simultaneously use of a variable (see MSDN: Interlocked Variable Access.
• __declspec(thread) forces each thread to have its own copy of the static data.

[Igor Vartanov]

But what if 'x' was a local variable...?

int some_func()
{
int x;

      x = call_some_other_func();

      return x;
}

Assuming that 'call_some_other_func()' was thread safe, is it safe to call the above function from two unsynchronised threads? Does each of them see a different copy of x?

Considering the fact that after some_func scope is left local x is invalid and unreachable, and only returned copy remains on the stack... than yes, it is thread safe to be used in multithreaded app, as the return value exists only in the scope of a caller, and therefore no other thread is able to access it.

[ovidiucucu]

All after all, I think it's not very clear what a stak is.