0

Summary of my understanding:
The top memory addresses are used for the? (I initially thought there was only one call stack) stack, and the? stack grows downwards (What and where are the stack and heap?)

However, each thread gets it's own stack allocated, so there should be multiple call stacks in memory (https://stackoverflow.com/a/80113/2415178)

Applications can share threads (e.g, the key application is using the main thread), but several threads can be running at the same time.

There is a CPU register called sp that tracks the stack pointer, the current stack frame of a call stack.

So here's my confusion:
Do all of the call stacks necessary for an application (if this is even possible to know) get allocated when the application gets launched? Or do call stacks get allocated/de-allocated dynamically as applications spin off new threads? And if that is the case, (I know stacks have a fixed size), do the new stacks just get allocated right below the previous stacks-- So you would end up with a stack of stacks in the top addresses of memory? Or am I just fundamentally misunderstanding how call stacks are being created/used?

I am an OS X application developer, so my visual reference for how call stacks are created come from Xcode's stack debugger:
enter image description here

Now I realize that how things are here are more than likely unique to OS X, but I was hoping that conventions would be similar across operating systems.
It appears that each application can execute code on multiple threads, and even spin off new worker threads that belong to the application-- and every thread needs a call stack to keep track of the stack frames.

Which leads me to my last question: How does the sp register work if there are multiple call stacks? Is it only used for the main call stack? (Presumably the top-most call stack in memory, and associated with the main thread of the OS) [https://stackoverflow.com/a/1213360/2415178]

Community
  • 1
  • 1
A O
  • 5,516
  • 3
  • 33
  • 68

2 Answers2

1

There is no such thing as the "main thread of the OS". Every process has its own set of threads, and those threads are specific to that process, not shared. Typically, at any given point in time, most threads on a system will be suspended awaiting input.

Every thread in a process has its own stack, which is allocated when the thread is created. Most operating systems will leave some space between each stack to allow them to grow if needed, and to prevent them from colliding with each other.

Every thread also has its own set of CPU registers, including a stack pointer (pointing to a location in that thread's stack).

  • Thanks for your answer! In this case, if you had a hundred applications opened, would there potentially be thousands of threads just sitting around with call stacks in memory-- effectively blocked? – A O Nov 16 '15 at 17:49
  • Not all in the same address space, but yes, absolutely. `top` reports that my computer currently has about 1700 threads active, for instance. –  Nov 16 '15 at 20:07
  • @AO Note that "memory" here means *virtual* memory, not necessarily RAM. – David Schwartz Nov 16 '15 at 21:59
1

Do all of the call stacks necessary for an application (if this is even possible to know) get allocated when the application gets launched?

No. Typically, each thread's stack is allocated when that thread is created.

Or do call stacks get allocated/de-allocated dynamically as applications spin off new threads?

Yes.

And if that is the case, (I know stacks have a fixed size), do the new stacks just get allocated right below the previous stacks-- So you would end up with a stack of stacks in the top addresses of memory? Or am I just fundamentally misunderstanding how call stacks are being created/used?

It varies. But the stack just has to be at the top of a large enough chunk of available address space in the memory map for that particular process. It doesn't have to be at the very top. If you need 1MB for the stack, and you have 1MB, you can just reserve that 1MB and have the stack start at the top of it.

How does the sp register work if there are multiple call stacks? Is it only used for the main call stack?

A CPU has as many register sets as threads that can run at a time. When the running thread is switched, the leaving thread's stack pointer is saved and the new thread's stack pointer is restored -- just like all other registers.

There is no "main thread of the OS". There are some kernel threads that do only kernel tasks, but also user-space threads also run in kernel space to run the OS code. Pure kernel threads have their own stacks somewhere in kernel memory. But just like normal threads, it doesn't have to be at the very top, the stack pointer just has to start at the highest address in the chunk used for that stack.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • So then each thread has it's own "register set", and when that thread is executing on a processing unit, that processing unit's registers will be set with the current thread's "register set"? So in a 4-core CPU, each processing unit holds one "register set" at a time, and swaps them out when the threads they are executing swap? – A O Nov 16 '15 at 21:33
  • @AO Yes, that's correct. If a CPU can run four threads at a time (for example, because it has four physical cores) then it also has four sets of registers. When the OS switches threads, it saves the leaving thread's context (including its registers) and loads the newly-running thread's context. – David Schwartz Nov 16 '15 at 21:35
  • That is a mind-boggling amount of processing that must happen. Thanks for your answer! This helps me understand a lot – A O Nov 16 '15 at 21:37
  • Interestingly, that's not really why switching threads is expensive on modern CPUs. Switching threads is expensive primarily because all the core's caches have the code and data the old thread was using and the new thread will have to "warm the caches back up again". – David Schwartz Nov 16 '15 at 22:02
  • Makes sense. Would you happen to have a resource (blog, article, etc) on the subject that you found particularly interesting? – A O Nov 16 '15 at 22:54