I only know the basics about the core of program's and operating systems so at the moment I can't really see how this is do-able.

I understand that program's are compiled to binary instructions and when run are loaded into ram, and the clock address starts at the top of the program and follows it down executing each instruction.
I understand that an operating system is just another program and when other program's are ran on top of this the OS sets the start of the program in a variable or registry somewhere and while the program is running it uses virtual address offset from its start point.

I could understand that on OS could hand full control over to a program and then regain control after by jumping to the program and when the program end it returns to the OS from the address plaed in stack on the jump

But how is an OS capable of loading a program in to be executed while also continuing to be executed itself, and possible other programs/threads too?


I've had a good think and a good look and can't come up with much.
Thanks

http://en.wikipedia.org/wiki/Preemption_(computing)#Preemptive_multitasking

It's also instructive to know about processor interrupts. Without them, your computer would just be a really expensive box that generates warm air.

http://en.wikipedia.org/wiki/Interrupt

To really understand how it all works you'd need to know more detail about how microprocessors in general work. I'll try to give a brief overview. Some of this info may be quite dated and obsolete (I'm an old fart and haven't delved into assembly programming in quite some time), but the basic principals are still valid.

Your microprocessor contains several registers which hold information about it's current operating state. Among these are pointers to the current instruction of the currently executing program, a pointer to the memory stack of the current program (where variables, function call addresses and suchlike are kept), and other stuff that's relevant only to the currently running program.

Your OS kernel is the primary program running on your computer. It manages running multiple other programs, seemingly simultaneously, by first, storing all the processor state info relevant to it's only operation, then loading in the processor state info for say an application that is running, then the applications instructions run for a while, oblivious to the OS kernel and any other program running.

How control gets switched back to the OS is generally handled through what is called an interrupt. An interrupt is basically a way for something (usually a hardware trigger for something external to the processor itself) to interrupt the main processor's current program. When an interrupt occurs, the processor saves its own state off, and jumps to a small program that has been loaded into memory called an interrupt handler. These interrupt handlers are usually supplied by your OS and loaded into memory when you boot up.

Things that commonly generate processor interrupts are any input device (your keyboard generates one every time you press or release a key) or certain other chips on your motherboard like the UART chip which contains the system clock that ticks off an interrupt every microsecond or so.

One of the interrupt handlers that your OS sets up is tied to the system clock and is designed to interrupt any running program after a short span of time and return control to the main kernel. The kernel can then let another program run for a bit.

This series of program switching happens very fast. Because processors are so much faster, it appears to us to be simultaneous, but it's really just an incredibly complex juggling act going on and most people don't have the slightest clue about the amount of pure genius that went in to making their phone work.

Don't know if this made any sense... It's really late for me.

That made perfect sense, thanks a lot... I will also read up on the links you sent as well as soon as I can.

My best guess (knowing of interrupts existing but not knowing how they're used) was that possibly the OS is capable of scanning the upcoming code of a program and choosing somewhere after let's say the closest to 100 cycles and a safe position, not on a jump or a variable, etc. then copy the upcoming code into a local position to the OS and executing it.
This is rather ill-thought and inefficient for time, memory and security to me though.

Anyways what you said about on an interrupt the CPU saves it's current state, I would imagine that the OS is able to specify where to save the state on next interrupt (say when you open a new process you don't want this writing over the state of another process on interrupt) and also which state to load from?

EDIT: Also the behaviour of the CPU on interrupt (unless you're going to make me do some searching/reading), I know it may be different for different CPU but generally do CPUs tend to finish a half complete instruction on interrupt? Let's say the processor has read an ADD and receives an interrupt signal when it should be readying the first address. At a guess I'd expect the current operation to finish and be in a "safe" state?

I would imagine that the OS is able to specify where to save the state on next interrupt

I am not an expert but according to:

http://www.cs.toronto.edu/~demke/469F.06/Lectures/Lecture6.pdf

"Interrupted process state is saved in process structure". If I understood well, the state is saved within the running process' memory. My guess is that should be done automatically by the hardware: the interrupt handler needs access to the CPU's registers for its own use, so the CPU must free those automatically.

When loaded into memory, every process has a fixed "memory window" in which it can write. I am fairly certain that on modern hardware, this is enforced in hardware. So, if the above slides are correct, CPU state is saved into the memory of the original process, which in turn is constrained to a certain memory window and cannot overwrite other process' states.

Some processes have unlimited access to memory, and those can clearly overwrite the state of other tasks. That is indeed done by the kernel of your system. Such "omnipotent" processes are, I believe, marked with a special flag (kept in a register on most modern hardware, according to http://en.wikipedia.org/wiki/Protection_ring ). That flag is the "ring" of the process. "Ring 0" processes are the omnipotent ones that can mess with the memory/state of other processes.

Apologies if any of the above is incorrect, feel free to point out any mistakes you see.

If I understood well, the state is saved within the running process' memory.

No, context goes in kernel memory.

My guess is that should be done automatically by the hardware: the interrupt handler needs access to the CPU's registers for its own use, so the CPU must free those automatically.

Context switches are performed manually by the interrupt handler. Not sure where the PC goes, though. Maybe that's pushed.

Back in the DOS days (when I actually screwed around with this stuff) interrupt handlers were basically responsible for ensuring that they didn't trash anything else and saved/restored whatever state info it felt necessary to execute and return to the running program without stepping on its toes. For example, if an interrupt handler didn't do anything which affects the CX or DX registers, then it wouldn't bother saving them at all. It would just leave them alone, do it's business, then restore the registers that it did save off and return. I don't know if modern protected mode systems are still this haphazard. I doubt it, there could be some serious security problems and exploits if it did.