CHAPTER 1 OPERATING SYSTEM FUNDAMENTALS
10
3. The page table for the process is updated so that the requested page is mapped
to the allocated frame.
4. Control returns to the calling process.
The calling process re-executes the instruction that caused the fault, but this time around, the CPU
finds a mapping for the requested page in the page table and the instruction completes successfully.
An understanding of virtual memory and paging is essential for kernel developers. Although the
kernel handles requests on behalf of user applications, it also has an address space of its own, so
parameters often need to be copied or mapped from a process’s address space to the kernel’s address
space. In addition, kernel code that interfaces to hardware devices often needs to obtain the physical
address of memory. Consider a disk driver that is handling a read request for a user process. The
destination for the data read from disk is a buffer that resides in the address space of the user process. As
with the CPU, the hardware controlled by the driver can write only to an address in main memory, and
not to a destination in the backing store. Therefore, to handle the read request, the driver needs to
ensure that the user buffer is swapped into main memory and remains in main memory for the duration
of the read operation. Finally, the driver needs to translate the address of the destination buffer from a
virtual address into a physical address that the hardware can access. We describe this in further detail in
Chapter 6.
It’s worth noting that although iOS provides a page table for each process, it does not support a
backing store. At first, it may seem that this completely defeats the purpose of paging. However, it serves
two very important purposes. First, it provides each process with the view that it has sole access to
memory. Second, it avoids problems caused by the fragmentation of physical memory.
Scheduling
Another resource that is under high contention in a computer system is the CPU. Each process requires
access to the CPU in order to execute, but typically, there are more active processes wanting access to
the CPU than there are CPU cores on the system. The operating system must therefore share the CPU
cores among the running processes and ensure that each process is provided regular access to the CPU
so that it can execute.
We have seen that processes run independent of each other and are given their own address spaces
to prevent one process from affecting the behavior of any other process. However, in many applications,
it is useful to allow two independent execution paths to run simultaneously, without the restriction of
having each path run within its own address space. This unit of execution is known as a “thread.”
Multiple threads all execute code from the same program code and are run within the same process (and
hence share the same address space), but otherwise run independently.
To the operating system, a thread is the basic unit of scheduling; the operating system scheduler
needs to look at only the active threads on the system when considering what to schedule next on the
CPU. For a process to execute, it must contain at least one thread; the operating system automatically
creates the initial thread for a new process when it begins running.
The goal of the scheduler is twofold: to prevent the CPU from becoming idle, since otherwise a
valuable hardware component is being wasted, and to provide all threads with access to the CPU in a
manner that is fair so that a single thread cannot monopolize the CPU and starve other threads from
running. To do this, a thread is scheduled on an available CPU core until one of two events occurs:
• A certain amount of time has elapsed, known as the time quantum, at which point
the thread is preempted by the operating system and another thread is scheduled.
On Mac OS X, the default time quantum is 10 milliseconds.
剩余472页未读，继续阅读
