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?

Answer 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?

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).