Sign in with
Sign up | Sign in
Your question

How does multitasking really work?

Last response: in CPUs
Share
July 30, 2010 9:19:04 PM



I have a question that I belive is more connected to the CPU hardware than to operating system software, so I will try in the CPU forum.

We all know that when doing multitasking in a modern operating system there is really not all processes running at the same time but very quick switching between processes/threads creating the illusion of many simultaneous programs.

In the old days with MSDOS there were no problem since there was only singletasking going on. On early Windows systems like 3.x there was only "cooperative multitasking" where the processes had to voluntarely give up the CPU time to other processes (one hang process = hang system).

On the modern Windows operating systems (Windows NT and forward) the multitasking system is "preemptive", i.e. the operating system is in charge and can stop any process at any time and give the CPU to any other arbitrary process.

I belive that this support is being done with the OS together with CPU hardware, starting from the Intel 80386, (which also added protected mode, virtual memory and many other things.)

Now comes my question. :)  Does anyone know how this is really done? If a certaing process, let us call it process A, is running at a certain point in time, how is it possible for the operating system, which also is just code that has to be run at the processor, to be able to intervene at all? (Let us also assume that the CPU is a single core with no hyperthreading.)

If no operating system code is running, how can it be working and preempt anything? What keeps process A from running forever and what it is that makes it possible for the operating system scheduler, which also is just a process/thread, to run at all and then assign the CPU to process B for example?

More about : multitasking work

a b à CPUs
July 30, 2010 9:56:21 PM

> If a certain process, let us call it process A, is running at a certain point in time, how is it possible for the operating system, which also is just code that has to be run at the processor, to be able to intervene at all?

You need to read up on "vectored interrupts" and
the general concept of hardware interrupts aka "IRQ".

All executing processes are subjected to "interrupts"
for a variety of reasons.

A most common interrupt is the real-time clock:
on super minicomputers that I worked on back
in the 1980s, each process normally received a
time slice of one-third of a second.

It is the real-time clock which actually "interrupted"
an executing process when its time-slice had
come to an end.

Similarly, XP's Task Manager has the ability to
issue an interrupt at the request of the User.
See the "Processes" tab in Windows Task Manager:
at the lower right, see "End Process".

There are actually lots of different ways to accomplish
what you inquire about: thus, there are several different
answers to your question.


MRFS
m
0
l
Related resources
July 30, 2010 10:22:06 PM



jefe323 said:
this might answer some of your questions:

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


Thanks, but the article does mostly descripe the workings in general terms, but not specifically to the x86 platform.


MRFS said:

You need to read up on "vectored interrupts" and
the general concept of hardware interrupts aka "IRQ".

All executing processes are subjected to "interrupts"
for a variety of reasons.


Yes, it is natural that there is hardware interrupts in a PC computer. Just moving the mouse arounds generates lots of interrupts, but that is also initiated by the hardware itself. My question is how the software OS control system works.

I have been wondering if the OS scheduling is done by some timed interrupt, like in the OS is putting a timer that in e.g. 10 ms from now there should be a interrupt being fired which should place the scheduler code back for execution. Are you saying that this is what is happening?

MRFS said:

Similarly, XP's Task Manager has the ability to
issue an interrupt at the request of the User.
See the "Processes" tab in Windows Task Manager:
at the lower right, see "End Process".


Since almost everything the user does is also causes an interrupt I guess that could be said to be correct, but the termination of processes is not really what my question was about. Instead it was how the ongoing switching between hundreds of threads per second is being done and how the OS controls this when not able to execute code itself?
m
0
l
July 31, 2010 1:05:31 AM

ricno said:
I have been wondering if the OS scheduling is done by some timed interrupt, like in the OS is putting a timer that in e.g. 10 ms from now there should be a interrupt being fired which should place the scheduler code back for execution. Are you saying that this is what is happening?


Yes. In Linux it's typically every millisecond, I've no idea about Windows; each time the interrupt goes off the OS picks the highest priority active threads and assigns one to each CPU core.

Quote:
Instead it was how the ongoing switching between hundreds of threads per second is being done and how the OS controls this when not able to execute code itself?


Note that you'll very rarely have hundreds of active threads in a single second. The OS may have a few hundred threads but most will be waiting for something to happen before they're woken up.
m
0
l
July 31, 2010 11:20:15 AM

MarkG said:
Yes. In Linux it's typically every millisecond, I've no idea about Windows; each time the interrupt goes off the OS picks the highest priority active threads and assigns one to each CPU core.


Thanks for your reply. That was very interesting. So Linux preempts the running task every millisecond and could possible assign another thread to run. It seems to be very many times (1000 per second) to save away all CPU register values and load the OS scheduler code. It is likely a well thought out value, but there must be a cost with this context switch and the running of the scheduler which should execute 1000 times each second.

I wonder how often a modern Windows does this. I read a long time ago that the Windows server products used somewhat longer timeslices than the desktop ones, due to the lower need for "responsiveness."


MarkG said:

Note that you'll very rarely have hundreds of active threads in a single second. The OS may have a few hundred threads but most will be waiting for something to happen before they're woken up.


That is true. I have 612 threads running on this old Windows XP systems, most of them from many open browser windows, but certainly most of them is inactive and does not need to be scheduled to the CPU at all.

But also, since there is often less active threads running, why should the OS scheduler need to look over the situation as many as 1000 times each second? If doing changes so often for quite few active threads it seems like there could be a risk that you could lose time/performance for the scheduler overhead?

Just interesting to reason about! :) 
m
0
l
July 31, 2010 2:56:48 PM

You may want to go to msdn.microsoft.com and search for "time slice". It returned over 1400 hits, many of which seem to discuss Windows task scheduling.
m
0
l
!