6
$\begingroup$

We know that operating system is responsible for handling memory allocation, process management etc. CPU can perform only one task at a time(assuming it to be single core). Suppose an operating system has allocated a CPU cycle to some user initiated process and CPU is executing that. Now where is operating system running? If some other process is using the CPU, then, is operating system not running for that moment? as OS itself must need CPU to run. If in case OS is not running, then who is handling process management, device management etc for that period?

This question was previously asked on Stack Overflow by vish. I answered it, and so did Martin James, and our answers feel partly contradictory.

Improve this question
$\endgroup$
1
  • $\begingroup$ 1. What research have you done? Have you tried reading standard OS textbooks? I expect you to do some research on your own before asking, and to tell us in the question what you tried and where you looked. 2. I don't feel like re-asking the same question a second time is helpful. I would expect you to make more effort in the question to tell us what specifically you find contradictory, what research you have done to try to study the subject more deeply, etc. So, what exactly is your question? Please try to formulate a specific question. $\endgroup$
    – D.W. ♦
    Sep 12, 2014 at 0:00

2 Answers 2

Reset to default
8
$\begingroup$

The question is mixing up who's in control of the memory and who's in control of the CPU. The wording “running” is imprecise: on a single CPU, a single task is running at any given time in the sense that the processor is executing its instructions; but many tasks are executing in the sense that their state is stored in memory and their execution can resume at any time.

While a process is executing on the CPU, the kernel is not executing. Its state is saved in memory. The execution of the kernel can resume:

  • if the process code makes a jump into kernel code — this is called a system call.
  • if an interrupt occurs.

If the operating system provides preemptive multitasking, it will schedule an interrupt to happen after an interval of time (called a time slice). On a non-preemptive operating system, the process will run forever if it doesn't yield the CPU. See How do modern operating systems like linux handle multitasking? for an explanation of how preemption works.

Tasks such as process management and device management are triggered by some event. If the event is a request by the process, the request will take the form of a system call, which executes kernel code. If the event is triggered from hardware, it will take the form of an interrupt, which executes kernel code.

(Note: in this answer, I use “CPU” and “processor” synonymously, to mean a single execution thread: a single core, or whatever the hardware architecture is.)

Improve this answer
$\endgroup$
6
  • 1
    $\begingroup$ Just a small clarification: Can't the OS schedule in tasks of it's own? In that case, kernel code is running without a System Call or an Interrupt (the two options you mentioned). $\endgroup$
    – Philipp Murry
    Aug 27, 2014 at 10:56
  • 1
    $\begingroup$ @PhilippMurry When the OS “schedules tasks of its own”, that means that it arranges for the task to be on the list of tasks to schedule. Switching to the task will always require a transition by an interrupt, system call (or some similar mechanism, e.g. hypervisor call, or even a plain jump on architectures without memory separation between tasks). Generally whatever mechanism triggers a context switch will cause the scheduler component of the kernel to run, but something has to cause the kernel code to run. $\endgroup$
    – Gilles 'SO- stop being evil'
    Aug 27, 2014 at 11:42
  • 1
    $\begingroup$ @Gilles Well, I agree that the kernel can only gain control via a Sys Call or an interrupt handler. To me it was just a bit misleading, because it sounded as if only the kernel code of a Sys Call or an interrupt handler will be able to run again. Nevermind. $\endgroup$
    – Philipp Murry
    Aug 27, 2014 at 12:19
  • $\begingroup$ @D.W. I'd forgotten about the SO duplicate when I suggested migrating this question to CS, but even then, I can't think of a better way to handle this. I think my answer is suitable for both sites, and that it's better than the other answers on SO or CS, so I'm not going to delete either (I wouldn't be able to anyway since both are accepted). If you have specific suggestions on how to make either answer fit their respective site better, I'm all ears. If you wish to suggest removing either answer or removing or moving either question, please initiate a discussion on meta. $\endgroup$
    – Gilles 'SO- stop being evil'
    Sep 12, 2014 at 6:26
  • 1
    $\begingroup$ @D.W. Actually the question is being closed as off-topic on SO and it's not too old to migrate, so I'll request to have it migrated here and merged with this thread, and then obviously I'll delete the spare copy of my answer. $\endgroup$
    – Gilles 'SO- stop being evil'
    Sep 12, 2014 at 6:34
1
$\begingroup$

I think OP was asking whether the OS needs to run all the time on the CPU (to manage processes and other things). Therefore, I think the second answer fits best: The OS doesn't need to run all the time. Eventually it will run again due to the timer interrupt.

Your answer seems a bit more complicated because you're mostly referring to main memory (which OP didn't ask for imo).

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ "Now where is operating system running? If some other process is using the CPU, then, is operating system not running for that moment?" - this is a pretty obvious question to me. it mentions the CPU, not main memory. Gilles answer (which you accepted) implies the same. $\endgroup$
    – Philipp Murry
    Aug 27, 2014 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.