Static and global variable in memory

Question

1. Are static variables stored on the stack itself similar to globals? If so, how are they protected to allow for only local class access?

2. In a multi threaded context, is the fear that this memory can be directly accessed by other threads/ kernel? or why cant we use static/global in multi process/ thread enviornment?

Solution 1

Variables stored on the stack are temporal in nature. They belong to a function, etc and when the function returns and the corresponding stack frame is popped off, the stack variables disappear with it. Since globals are designed to be accessible everywhere, they must not go out of context and thus are stored on the heap (or in a special data section of the binary) instead of on the stack. The same goes for static variables; since they must hold their value between invocations of a function, they cannot disappear when the function returns thus they cannot be allocated on the stack.

As far as protection of static variables goes, IIRC this is mainly done by the compiler. Even though the variable is on the heap, your compiler knows the limited context in which that variable is valid and any attempt to access the static from outside that context will result in an "unknown identifier" or similar error. The only other way to access the heap variable incorrectly is if you know the address of the static and you blindly de-reference a pointer to it. This should result in a run-time memory access error.

In a multi-threaded environment, it is still okay to use globals and static variables. However, you have to be a lot more careful. You must guarantee that only one thread can access the variable at a time (typically through some kind of locking mechanism such as a mutex). In the case of static local variables inside a function, you must ensure that your function will still function as expected if it is called from multiple threads sequentially (that is, called from thread 1, then from thread 2, then thread 1, then thread 2, etc etc). This is generally harder to do and many functions that rely on static member variables are not thread-safe because of this (strtok is a notable example).

Solution 2

Static variables have static storage duration, so they're not normally placed on the stack. The only "protection" for them is that their name has local visibility at compile time. Passing the address of a static variable gives access it it.

Using static/globals in a multithreaded situation has the problem that if one thread modifies a the variable at the same time as another attempts to read it (just for one example) what gets read may be bad data.

Solution 3

Are static variables stored on the stack itself similar to globals? If so, how are they protected to allow for only local class access?

Generally they are stored in memory along with globals. however the visibility of the variable names limits access.

In a multi threaded context, is the fear that this memory can be directly accessed by other threads/ kernel? or why cant we use static/global in multi process/ thread environment?

The problem is that there's only one copy of a static, so if multiple threads are modifying the variable, one thread may cause another thread's change to be lost if there aren't safeguards (critical sections) to prevent this.

Solution 4

Are static variables stored on the stack itself similar to globals? If so, how are they protected to allow for only local class access?

No, static refers to storage duration only -- they may be global or have local scope. Globals have static storage.

In a multi threaded context, is the fear that this memory can be directly accessed by other threads/ kernel? or why cant we use static/global in multi process/ thread enviornment?

Multiple writers will introduce ambiguity. You need to protect shared resources using a mutex or some such locking mechanism.

View more solutions

Comments

[Swapna]

So static variables and globals are in heap memory?

[Swapna]

what if it is a thread specific static data? it is not explicitly visible to other threads, and the only way to access it would be through direct memory addressing, correct?

[Steve Jessop]

Not necessarily. The standard does not define either "stack" or "heap", so it's not correct to assume that all memory belongs to one or the other. Typically globals are stored in a data section associated with the program (and the process). From the OS's point of view this was probably allocated off the heap, but then again from the OS's point of view, the stack was quite possibly allocated off the heap.

[Michael Burr]

If you mean it in thread local storage, then there's no problem (unless you pass the address on to something else). If it's scoped to a thread procedure (for example), there might still be a problem - it's possible for multiple thread instances to be executing the same thread procedure (or other functions called from it). If your threadproc will only ever run a single thread then you don't have to worry about protecting statics local to that threadproc.

[bubble]

Can you cite any link for the support of "static variables cannot be allocated on the stack and that they are stored on the heap"