What are the four major resource manager in typical operating system?

Answer 1

I don't think there are four resource managers in a typical OS. Usually a kernel will have:

1. A process scheduler, which will determine when which process runs on what CPU or core and for how long based on various rules often hardcoded into it. Usually how it works is based on priorities of each process (How 'important' the process is, rather, how much CPU time the process really needs every quantum.), preemption (Interrupting a process whenever an interrupt occurs.), and blocking (When a process pauses itself when it makes a request to the operating system, usually involving I/O operations, via system call or message passing.). The scheduler also handles most of the decisions on when a process is created or destroyed, since it'll need to make that call based on its own queue.

2. A memory manager, which in most operating systems will provide virtual memory and paging. It's job is to set up a protected memory system, which means no process should even see another process's memory, let alone write to it. Virtual memory is the best way to do this, as it means that every process will see a "simulated world" for itself in memory and nothing else. The operating system, and often the hardware, will transparently handle translating a process's addressing to real physical addresses in system RAM. This keeps even the buggiest of userspace programs from affecting any other process or even the running kernel itself should it misbehave. Paging is a mechanism where these little virtual memory spaces are broken up into little pieces of equal length, allowing a program to be allocated memory even in non-contiguous spaces in memory. Further, swap relies on paging support, allowing pieces of a processes memory to be stored on the hard disk when not needed if physical RAM runs low. As a memory manager is meant to protect processes from each other and the operating system from its processes, if a programtries to access memory in a way that isn't allowed, the operating system can quickly terminate the process.

3. There is also the I/O scheduler. It is also like the process scheduler in that it has to make quick on-the-fly decisions on what process gets use of something. In this case hardware, usually a disk.

4. Interprocess communication mechanisms: As a process cannot access another process in memory, the kernel does need to provide at least one avenue for processes to tell other processes what they need from each other. Usually there will be something in userspace that actually handles these transactions through the kernel.

5. Finally, driver support. All kernels need to provide some way for drivers, programs that provide communication and control of the hardware, to get the kernel to talk to the hardware. Kernels usually come in two flavors: Monolithic and micro, and one of the most importatnt and fundamental differences between the two is how their drivers work. A monolithic kernel will generally allow all drivers to become a part of it, either compiled right in or, more commonly, as loadable kernel modules. This allows drivers to talk to the kernel and their hardware directly. Microkernels, on the other hand, have only a basic process scheduler, memory manager, and IPC mechanism, and rely on userspace to provide the rest of the system, including drivers. Drivers have no direct line to the kernel but will have to end up making system calls like any user space program. This design, needless to say, is not efficient. There are also "hybrid" kernels, but generally they are still monolithic in design, but have a component or two in userspace. Drivers will almost certainly still be loadable kernel modules or part of the kernel, as most operating system designers agree, performance is better served when device drivers do not have to compete with userspace processes for kernel services.