Modern Operating Systems by Herbert Bos ...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Showing 115-117 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 115
ruining the file system.
You can also do the experiment safely in a virtual machine.
: Do not try this on a shared system without first getting permission from the sys-
tem administrator. The consequences will be instantly obvious so you are likely to be
caught and sanctions may follow.
Examine and try to interpret the contents of a UNIX-like or Windows directory with a
tool like the UNIX
program. (
: How you do this will depend upon what the OS
allows. One trick that may work is to create a directory on a USB stick with one oper-
ating system and then read the raw device data using a different operating system that
allows such access.)

Page 116
We are now about to embark on a detailed study of how operating systems are
designed and constructed. The most central concept in any operating system is the
: an abstraction of a running program. Everything else hinges on this con-
cept, and the operating system designer (and student) should have a thorough un-
derstanding of what a process is as early as possible.
Processes are one of the oldest and most important abstractions that operating
systems provide. They support the ability to have (pseudo) concurrent operation
even when there is only one CPU available. They turn a single CPU into multiple
virtual CPUs.
Without the process abstraction, modern computing could not exist.
In this chapter we will go into considerable detail about processes and their first
cousins, threads.
All modern computers often do several things at the same time. People used to
working with computers may not be fully aware of this fact, so a few examples
may make the point clearer. First consider a Web server.
Requests come in from
all over asking for Web pages. When a request comes in, the server checks to see if
the page needed is in the cache.
If it is, it is sent back; if it is not, a disk request is
started to fetch it. However, from the CPU’s perspective, disk requests take eter-
While waiting for a disk request to complete, many more requests may come

Page 117
in. If there are multiple disks present, some or all of the newer ones may be fired
off to other disks long before the first request is satisfied. Clearly some way is
needed to model and control this concurrency. Processes (and especially threads)
can help here.
Now consider a user PC.
When the system is booted, many processes are se-
cretly started, often unknown to the user. For example, a process may be started up
to wait for incoming email.
Another process may run on behalf of the antivirus
program to check periodically if any new virus definitions are available. In addi-
tion, explicit user processes may be running, printing files and backing up the
user’s photos on a USB stick, all while the user is surfing the Web. All this activity
has to be managed, and a multiprogramming system supporting multiple processes
comes in very handy here.
In any multiprogramming system, the CPU switches from process to process
quickly, running each for tens or hundreds of milliseconds. While, strictly speak-
ing, at any one instant the CPU is running only one process, in the course of 1 sec-
ond it may work on several of them, giving the illusion of parallelism. Sometimes
people speak of
in this context, to contrast it with the true hard-
ware parallelism of
systems (which have two or more CPUs shar-
ing the same physical memory).
Keeping track of multiple, parallel activities is
hard for people to do. Therefore, operating system designers over the years have
evolved a conceptual model (sequential processes) that makes parallelism easier to
deal with. That model, its uses, and some of its consequences form the subject of
this chapter.
2.1.1 The Process Model
In this model, all the runnable software on the computer, sometimes including
the operating system, is organized into a number of
sequential processes
, or just
for short.
A process is just an instance of an executing program, includ-
ing the current values of the program counter, registers, and variables. Con-
ceptually, each process has its own virtual CPU.
In reality, of course, the real CPU
switches back and forth from process to process, but to understand the system, it is
much easier to think about a collection of processes running in (pseudo) parallel
than to try to keep track of how the CPU switches from program to program. This
rapid switching back and forth is called
, as we saw in Chap.
In Fig. 2-1(a) we see a computer multiprogramming four programs in memory.
In Fig. 2-1(b) we see four processes, each with its own flow of control (i.e., its own
logical program counter), and each one running independently of the other ones.
Of course, there is only one physical program counter, so when each process runs,
its logical program counter is loaded into the real program counter. When it is fin-
ished (for the time being), the physical program counter is saved in the process’
stored logical program counter in memory.
In Fig. 2-1(c) we see that, viewed over

Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades

Students also viewed documents