The question is very vague, but, most likely, it means that your problem is related to understanding of
multiprocessing, which is, in modern systems, is also related to
multithreading.
The basic idea is: consider you have many processes each running either one thread or more threads, and only one CPU with only one CPU core. The generalization of this situation is having more CPUs or cores, but it won't add much to understanding of the basics. The threads of all those processes are still executed in parallel. This is achieved by giving each thread some resources, first of all, some memory, essentially, the
stack (please see the reference below), CPU and other resources. The thread can use those resources exclusively, but, to let other threads work independently, the current thread can be interrupted, switched off, and the resources will be given to some other thread. While threads retain they stack and part of other memory (on modern systems, this is way more complex than that because of the independent part of architecture called
virtual memory, but this mechanism is fully transparent for a thread and a process, so you can consider that allocated memory belongs to each process exclusively), and, notably, the CPU and its registers. To avoid interference between threads, the states of the CPU and all its registers is stored when a thread is switched off, and fully restored then the same thread is switched for execution again. In many CPUs this thread switching is comprehensively supported by its
instruction-set and, due it hardware nature of such implementations, is very fast.
In top it this mechanism, thread switching described above can be causes by different reasons. It can be "called" directly by some application code (this is not exactly a "call", because there is no return). Such mechanisms are used in
cooperative multitasking. In modern system,
preemptive multitasking is used. In this case, the thread switching mechanism is invoked on hardware interrupts, typically, in non-realtime system, by the timer interrupt. Each thread works exclusively during some
time slice and then is switched out. It is said to be
preempted. Note that in
realtime systems this mechanism can be highly specialized. (Let's say this topic is well beyond the topic of this question.)
And only on top all of the above,
scheduling is required. The mechanisms described above are very low-level, but the scheduler is the most high-level code. It simply have the collection of all the threads in the system and has to answer the question: "who's next?". Actually, when it comes to
preemption described above, the thread is not preempted by the thread of some other application. In fact, it is preempted by some code (in modern system, the code in the OS
kernel) which eventually calls the scheduler, get the answer to this question and then switches to some other thread according to it. Actually, the algorithm of answering to this "who's next question" can be very complex and include many factors: actual time of execution, states and properties of other threads waiting for their time slices, actual times of waiting (in a special
wait state related to the use of
thread synchronization primitive or not), priorities of processes and threads, and so on.
Please see:
http://en.wikipedia.org/wiki/Multiprocessing[
^],
http://en.wikipedia.org/wiki/Multithreading_%28software%29#Multithreading[
^],
http://en.wikipedia.org/wiki/Call_stack[
^],
http://en.wikipedia.org/wiki/Cooperative_multitasking[
^],
http://en.wikipedia.org/wiki/Preemptive_multitasking#Preemptive_multitasking[
^],
http://en.wikipedia.org/wiki/Time_slice#Time_slice[
^],
http://en.wikipedia.org/wiki/Scheduling_%28computing%29[
^],
http://en.wikipedia.org/wiki/OS_kernel[
^],
http://en.wikipedia.org/wiki/Real-time_computing[
^].
—SA
Submit an article or tip