Whenever the bootloader loads the operating system there is presumably only ONE program flow active, right? This would mean, one processor holds the instruction pointer and executes the commands it founds at the position the EIP register points to. At which point and how does the system start to exploit more processes and/or threads (no userland threads, but cpu threads)?
+3
A:
One of the first things a (multithreaded) OS has to start is the scheduler which is responsible for managing multiple processes (and therefore also manages multiple CPU threads eg. on multicore machines).
The first process started by this scheduler is typically some sort of "init" process which in turn is responsible for loading the other programs/processes subsequently.
MartinStettner
2009-04-12 13:25:26
+4
A:
Correct, during the boot process there is only one execution thread. Usually this is the case until the OS has initialized to the point where low-level memory management, scheduler etc. are functional.
This is even the case in multi-CPU systems - one core is the "master processor" handling the early startup until the infrastructure is there to kickstart the other cores.
In the end it's highly OS-specific; the Intel Architecture Software Developer's Manuals have the details of the hardware specs. (Assuming you're talking about Intel architecture; other architectures might differ wildly.)
DevSolar
2009-04-12 13:27:01
+4
A:
The OS will boot (after the BIOS and the bootloader are done) in a special role - as the first program to run it will have direct access to all the CPUs commands.
So it will setup various parts of the system - like setting up Interrupt Handlers (or Interrupt Service Routines). Having done this it has the ability to create a "scheduler".
The actual "process/thread" handling will be done by this scheduler. It decides, which threads will be run. Also it manages all the active threads. The CPU is unaware of all these things.
Once the scheduler's main-executive decides to execute Thread (or "Process") A, it copys the processes data into the registers (and stores the registers into the recently running thread's InfoBlock). It will tell the CPU / a timer to cause an interrupt in n microseconds (or other timeunit). Then it will tell the cpu to run the "program" (the only thing the CPU knows about) in the non-OS mode (so that it may not modify critical data or register own Interrupt Handlers without permission).
While Thread A is executing now, the hardware timer will run. Once it hits the desired time-offset, it will cause an Interrupt. The hardware will then stop execution of the current program, and will invoke the registred Interrupt Handler instead which. This handler will be a method of the scheduler (the main-executive again, to be precise).
This method will then again reevaluate which Thread should be scheduled and so the scheduling continues.
Marcel J.
2009-04-12 13:42:09
Thank you for your explanation. Can you tell me how this picture changes when several independent processors/cores are involved?
prinzdezibel
2009-04-12 14:07:19
Most multicores have at least some "master" processor (see other answers) - L1+ caches wouldn't work without some central management. The scheduler will just have to address the desired processor for each register-operation. Everything else keeps the same (fixed-interval timers).
Marcel J.
2009-04-12 14:18:14
@prinzdezible: The OS scheduler generally runs on each CPU core when the current thread is stopped via interrupt or by making a system call. In order to be scalable to many cores it will not look at all the threads, but only threads assigned to that CPU. If it is too busy it will push threads to other CPUs. If it is not busy it will pull threads from other CPUs. Every so often by time or some counter, the scheduler will load balance tasks over all CPUs (this is slow, so not often)
Zan Lynx
2010-07-08 19:06:58