0

I know that a single-CPU system can run only one process at any instant. My doubt is, how does OS being itself a separate process runs on the CPU mean while managing to schedule some other process aswell simultaneously (which is not possible,as only one process can be run on a single-CPU system).

In other words,if another process is consuming the CPU at any time does the OS be context switched ?? or where does the OS runs(as it has to be active always to monitor) ??

I even don't know whether its an appropriate question... but kindly let me know if you have an answer. OR correct me if I am wrong !!

Thanks in Advance !!

Legolas
  • 805
  • 1
  • 11
  • 24
  • 1
    A process is scheduled to run after the current running process yields the CPU. The scheduler routine is provoked and a process is picked. **Process A --> Scheduler --> Process X**. – Tony Tannous Oct 09 '17 at 07:19
  • 'My doubt is, how does OS being itself a separate process' - where did you read that? – Martin James Oct 09 '17 at 11:44
  • @MartinJames . that was my understanding. but thanks for pointing out another link..which exactly cleared my query. – Legolas Oct 09 '17 at 12:01
  • @Aravind.A no problem! Just beware that the accepted, and highly-upvoted, answer, is misleading. Preemptive multitaskers, with their problems of synchronization, exclusion, mutex, semaphores, events etc,. are not in use because of the programmable timer interrupt. - they are used to achieve good performance upon I/O completion when threads/processes can be made ready/running 'immediately' when data becomes available for them from peripherals like KB, mouse, disk, NIC etc. – Martin James Oct 09 '17 at 12:14

1 Answers1

0

In a modern operating system the kernel, the core of the OS, in complete control of how much time it allocates to the various user processes it's managing. It can interrupt the execution of a user process through various mechanisms provided by the CPU itself. This is called preempting the process and can be done on a schedule, like executing a user process for a particular number of nanoseconds before automatically interrupting it.

In older operating systems, like DOS and Windows 1.0 through 3.11, macOS 9 and earier, plus many others, they employ a different mode where the user process is responsible for yielding control. If the process doesn't yield there may be little recourse to reassert control of the system. This can lead to crashes or lock-ups, a frequent problem with non-preemptive operating systems of all stripes.

Even then there is often hardware support for things like hardware timers that can trigger a particular chunk of code on a regular basis which can be used to rescue the system from a run-away process. Just because a bit of code is running is no guarantee that it will continue to run indefinitely, without interruption.

A modern CPU is a fantastically complicated piece of equipment. Those with support for things like CPU virtualization can make the single physical CPU behave as if it's a number of virtual CPUs all sharing the same hardware. Each of these virtual CPUs is free to do whatever it wants, including dividing up its time using either a pre-emptive or cooparative model, as well as splitting itself into even more virtual CPUs.

The long and the short of it here is to not assume that the kernel must be actively executing to be in control. It has a number of tools at its disposal to wrest control of the CPU back from any process that might be running.

tadman
  • 208,517
  • 23
  • 234
  • 262