Platform Technologies Module 2

Republic of the Philippines
Mountain Province State Polytechnic College

Bontoc, Mountain Province
OPERATING SYSTEM STRUCTURES
Module 2 of 4
PLATFORM TECHNOLOGIES
Brueckner B. Aswigue
Information Technology Department
1st Semester, SY 2020-2021

CP #: 0947-3621-495
bbaswigue@yahoo.com
INTRODUCTION
This module have three lessons: operating system structures, process concepts,
and threads. The operating system structures discuss the general structure of computer
systems. It may be a good idea to review the basic concepts of machine organization and
assembly language programming. Operating system structures elaborate the following
components, such as: concepts of memory, CPU, registers, I/O, interrupts, instructions,
and the instruction execution cycle. Since the operating system is the interface between
the hardware and user programs, a good understanding of operating systems requires
an understanding of both hardware and programs.
The overview of the process concepts will discuss at lesson two. This will
introduce the concepts of a process and concurrent execution where at the very heart
of modern operating systems. It will show the process execution in a modern time-
sharing system and introduce the notion of a thread (lightweight process) and
interprocess communication (IPC).
The last lesson of this module is threads. The threads will introduces many
concepts associated with multithreaded computer systems and covers how to use Java
to create and manipulate threads. We have found it especially useful to discuss how a
Java thread maps to the thread model of the host operating system.
If you want to know more interesting facts about this module, visit the following:
Operating system. http://www.wiley.com/college and clicking “Who’s my rep?” and
Operating System. http://www.os-book.com. The ebook and powerpoint presentation
will be given for you as additional references to elaborate some of the topics.
The number of hours allotted for this module shall be 8 hours. You are expected
to finish the module in three weeks.
LEARNING OUTCOMES
At the end of the module, you should be able to:

1. classify thoroughly the various components of operating system structures;
2. distinguish comprehensively how process concepts works in modern operating
systems; and,
3. discuss accurately the threads model in the host operating system.
PRE-TEST
The following questions cover general areas of this module. You may not know
the answers to all questions, but please attempt to answer them without asking
others or referring to books.
Choose the best answer for each question and write the letter of your choice
after the number.
1. The user interface take several for such as.
a. Graphical user interface and external execution
b. Graphical user interface and command-line interface
c. Graphical user interface and file system
d. All of the above
1
2. A running program requires Input/Output (I/O)?
a. True
b. False
3. Does the program always ends its execution normally?

a. True
b. False
4. Communication that via shared memory and message passing.

a. Packet
b. Efficient
c. Resource
d. Implemented
5. This needs to be detecting and correcting errors constantly under error detection.
a. Resource allocation
b. User interface
c. Communication
d. Operating System
6. used as record keeping for billing purposes and accumulating usage statistics.
a. Math
b. Statistic
c. Accounting
d. Information Technology
7. It allows direct command entry.

a. Command line Interface
b. Accounting
c. GUI
d. Microsoft
8. An interface that the user employs a mouse-based windows and menu system.
a. Graphical user interface
b. Mouse user interface
c. Line interface
d. On-line interface
9. An interface that does not need a mouse and virtual keyboard.

a. Graphical user interface
b. Touch screen user interface
c. CLI
d. Mouse interface
10. It provides an interface to the services made available by an operating system.

a. System calls
b. Source file
c. CLI
d. None of the above
LESSON 1: Operating System Structures
Objectives:
At the end of the lesson, you should be able to:
1. describe thoroughly the services an operating system provides to users,
processes, and other systems; and,
2. discuss comprehensively the various ways of structuring an operating system;
and,
3. explain accurately how operating systems are installed and customized and
how they boot.
2
Let’s Engage.
An operating system provides the environment within which programs are
executed. Internally, operating systems vary greatly in their makeup, since they are
organized along many different lines. The design of a new operating system is a major
task. It is important that the goals of the system be well defined before the design begins.
These goals form the basis for choices among various algorithms and strategies.
We can view an operating system from several vantage points. One view focuses
on the services that the system provides; another, on the interface that it makes
available to users and programmers; a third, on its components and their
interconnections.
The more complex the operating system is, the more it is expected to do on behalf
of its users. Although its main concern is the execution of user programs, it also needs
to take care of various system tasks that are better left outside the kernel itself. A system
therefore consists of a collection of processes: operating system processes executing
system code and user processes executing user code. Potentially, all these processes
can execute concurrently, with the CPU (or CPUs) multiplexed among them. By
switching the CPU between processes, the operating system can make the computer
more productive. In lesson 2, you will read about what processes are and how they work.
Operating systems are those programs that interface the machine with the
applications programs like Microsoft Office, Google and programming languages
software. The main function of these systems is to dynamically allocate the shared
system resources to the executing programs. As such, research in this area is clearly
concerned with the management and scheduling of memory, processes, and other
devices. But the interface with adjacent levels continues to shift with time. Functions
that were originally part of the operating system have migrated to the hardware. On the
other side, programmed functions extraneous to the problems being solved by the
application programs are included in the operating system.
If one were to develop an application program as a set of machine instructions

that is completely responsible for controlling the computer hardware, one would be
faced with an overwhelmingly complex undertaking.
To ease this chore, a set of system programs is provided. Some of these programs
are referred to as utilities, or library programs. These implement frequently used
functions that assist in program creation, the management of files, and the control of
I/O devices.
A programmer will make use of these facilities in developing an application, and

the application, while it is running, will invoke the utilities to perform certain functions.
The most important collection of system programs comprises the OS. The OS masks the
details of the hardware from the programmer and provides the programmer with a
convenient interface, efficient manner of computer resources, and ability to evolve for
using the system.
3
OPERATING SYSTEMS STRUCTURE
Operating-System Services
An operating system provides an environment for the execution of programs. It

provides certain services to programs and to the users of those programs. The specific
services provided, of course, differ from one operating system to another, but we can
identify common classes. These operating system services are provided for the
convenience of the programmer, to make the programming task easier.
Figure 1 shows the view of the various operating-system services and how they
interrelate.
Figure 1. A view of the Operating Services (Operating System. http://www.os-book.com)
One set of operating system services provides functions that are helpful to the user.
• User interface. Almost all operating systems have a user interface (UI). This
interface can take several forms. One is a command-line interface (CLI), which uses
text commands and a method for entering them (say, a keyboard for typing in
commands in a specific format with specific options). Another is a batch interface,
in which commands and directives to control those commands are entered into files,
and those files are executed. Most commonly, a graphical user interface (GUI) is
used. Here, the interface is a window system with a pointing device to direct I/O,
choose from menus, and make selections and a keyboard to enter text. Some systems
provide two or all three of these variations.
• Program execution. The system must be able to load a program into memory and
to run that program. The program must be able to end its execution, either normally
or abnormally (indicating error).
• I/O operations. A running program may require I/O, which may involve a file or an
I/O device. For specific devices, special functions may be desired (such as recording
to a CD or DVD drive or blanking a display screen). For efficiency and protection,
users usually cannot control I/O devices directly. Therefore, the operating system
must provide a means to do I/O.
4
• File-system manipulation. The file system is of particular interest. Obviously,
programs need to read and write files and directories. They also need to create and
delete them by name, search for a given file, and list file information. Finally, some
operating systems include permissions management to allow or deny access to files
or directories based on file ownership. Many operating systems provide a variety of
file systems, sometimes to allow personal choice and sometimes to provide specific
features or performance characteristics.
• Communications. There are many circumstances in which one process needs to

exchange information with another process. Such communication may occur
between processes that are executing on the same computer or between processes
that are executing on different computer systems tied together by a computer
network. Communications may be implemented via shared memory, in which two or
more processes read and write to a shared section of memory, or message passing,
in which packets of information in predefined formats are moved between processes
by the operating system.
• Error detection. The operating system needs to be detecting and correcting errors
constantly. Errors may occur in the CPU and memory hardware (such as a memory
error or a power failure), in I/O devices (such as a parity error on disk, a connection
failure on a network, or lack of paper in the printer), and in the user program (such
as an arithmetic overflow, an attempt to access an illegal memory location, or a too-
great use of CPU time). For each type of error, the operating system should take the
appropriate action to ensure correct and consistent computing. Sometimes, it has
no choice but to halt the system. At other times, it might terminate an error-causing
process or return an error code to a process for the process to detect and possibly
correct.
Another set of operating system functions exists not for helping the user but
rather for ensuring the efficient operation of the system itself. Systems with multiple
users can gain efficiency by sharing the computer resources among the users.
• Resource allocation. When there are multiple users or multiple jobs running at the
same time, resources must be allocated to each of them. The operating system
manages many different types of resources. Some (such as CPU cycles, main
memory, and file storage) may have special allocation code, whereas others (such as
I/O devices) may have much more general request and release code. For instance,
in determining how best to use the CPU, operating systems have CPU-scheduling
routines that take into account the speed of the CPU, the jobs that must be executed,
the number of registers available, and other factors. There may also be routines to
allocate printers, USB storage drives, and other peripheral devices.
• Accounting. We want to keep track of which users use how much and what kinds
of computer resources. This record keeping may be used for accounting (so that
users can be billed) or simply for accumulating usage statistics. Usage statistics may
be a valuable tool for researchers who wish to reconfigure the system to improve
computing services.
• Protection and security. The owners of information stored in a multiuser or

networked computer system may want to control use of that information. When
several separate processes execute concurrently, it should not be possible for one
process to interfere with the others or with the operating system itself. Protection
involves ensuring that all access to system resources is controlled. Security of the
system from outsiders is also important. Such security starts with requiring each
user to authenticate himself or herself to the system, usually by means of a
password, to gain access to system resources. It extends to defending external I/O
devices, including network adapters, from invalid access attempts and to recording
all such connections for detection of break-ins. If a system is to be protected and
secure, precautions must be instituted throughout it. A chain is only as strong as
its weakest link.
5
A View of Operating System Services
One provides a command-line interface, or command interpreter, that allows

users to directly enter commands to be performed by the operating system. The other
allows users to interface with the operating system via a graphical user interface, or
GUI.
A. User Operating System Interface - CLI

• CLI or command interpreter allows direct command entry
• Sometimes implemented in kernel, sometimes by systems program
• Sometimes multiple flavors implemented – shells or drive prompt
• Primarily fetches a command from user and executes it
• Sometimes commands built-in, sometimes just names of programs
• If the latter, adding new features doesn’t require shell modification
Bourne Shell Command Interpreter
Figure 2 The Bourne shell command interpreter in Solrais 10 (Operating System.

http://www.os-book.com).
B. User Operating System Interface – GUI

• A second strategy for interfacing with the operating system is through a user
friendly graphical user interface, or GUI. Here, rather than entering commands
directly via a command-line interface, users employ a mouse-based window and-
menu system characterized by a desktop metaphor or known as User-friendly
desktop metaphor interface
• Usually mouse, keyboard, and monitor
• Icons represent files, programs, actions, etc
• Various mouse buttons over objects in the interface cause various actions
(provide information, options, execute function, open directory (known as a
folder)
• Invented in the early 1970s at Xerox PARC research facility
• Many systems now include both CLI and GUI interfaces
• Microsoft Windows is GUI with CLI “command” shell
• Apple Mac OS X is “Aqua” GUI interface with UNIX kernel underneath and shells
available
• Unix and Linux have CLI with optional GUI interfaces (CDE, KDE, GNOME)
6
C. Touchscreen Interfaces
• Touchscreen devices require new interfaces
o Mouse not possible or not desired
o Actions and selection based on gestures
o Virtual keyboard for text entry
• Voice commands.
Figure 3. The iPad Touchscreen (Operating System. http://www.os-book.com).
D. Choice of Interface
• The choice of whether to use a command-line or GUI interface is mostly one
of personal preference.
• System administrators who manage computers and power users who have
deep knowledge of a system frequently use the command-line interface. For
them, it is more efficient, giving them faster access to the activities they need
to perform. Indeed, on some systems, only a subset of system functions is
available via the GUI, leaving the less common tasks to those who are
command-line knowledgeable. Further, commandline interfaces usually make
repetitive tasks easier, in part because they have their own programmability.
For example, if a frequent task requires a set of command-line steps, those
steps can be recorded into a file, and that file can be run just like a program.
The program is not compiled into executable code but rather is interpreted by
the command-line interface. These shell scripts are very common on systems
that are command-line oriented, such as UNIX and Linux.
• In contrast, most Windows users are happy to use the Windows GUI
environment and almost never use the MS-DOS shell interface. The various
changes undergone by the Macintosh operating systems provide a nice study
in contrast. Historically, Mac OS has not provided a command-line interface,
always requiring its users to interface with the operating system using its GUI.
• However, with the release of Mac OS X (which is in part implemented using a

UNIX kernel), the operating system now provides both Aqua interface and
command-line interface. Figure 2.4 is a screenshot of the Mac OS X GUI.
7
Figure 4. The Mac OS X GUI (Operating System. http://www.os-book.com).
System Calls
System calls provide an interface to the services made available by an operating

system. These calls are generally available as routines written in C and C++, although
certain low-level tasks (for example, tasks where hardware must be accessed directly)
may have to be written using assembly-language instructions.
Let’s first use an example to illustrate how system calls are used: writing a
simple program to read data from one file and copy them to another file.
1. The first input that the program will need is the names of the two files: the input
file and the output file. These names can be specified in many ways, depending
on the operating-system design.
a. One approach is for the program to ask the user for the names. In an
interactive system, this approach will require a sequence of system calls,
first to write a prompting message on the screen and then to read from the
keyboard the characters that define the two files.
b. On mouse-based and icon-based systems, a menu of file names is usually
displayed in a window. The user can then use the mouse to select the
source name, and a window can be opened for the destination name to be
specified. This sequence requires many I/O system calls.
2. Once the two file names have been obtained, the program must open the input
file and create the output file. Each of these operations requires another system
call. Possible error conditions for each operation can require additional system
calls.
3. When the program tries to open the input file, for example, it may find that
there is no file of that name or that the file is protected against access.
4. The program should print a message on the console (another sequence of

system calls) and then terminate abnormally (another system call).
5. If the input file exists, then we must create a new output file. We may find that
there is already an output file with the same name. This situation may cause the
program to abort (a system call), or we may delete the existing file (another system
call) and create a new one (yet another system call).
a. Another option, in an interactive system, is to ask the user (via a sequence
of system calls to output the prompting message and to read the response
from the terminal) whether to replace the existing file or to abort the
program.
8
6. When both files are set up, we enter a loop that reads from the input file (a system
call) and writes to the output file (another system call). Each read and write must
return status information regarding various possible error conditions. On input,
the program may find that the end of the file has been reached or that there was
a hardware failure in the read (such as a parity error).
7. The write operation may encounter various errors, depending on the output
device (for example, no more disk space).
8. Finally, after the entire file is copied, the program may close both files (another
system call), write a message to the console or window (more system calls), and
finally terminate normally (the final system call). This system-call sequence is
shown in Figure 5 where the system call sequence to copy the contents of one file
to another file.
Figure 5. Example of how system calls are used (Operating

System. http://www.os-book.com).
System Call Implementation
• Typically, a number associated with each system call

• System-call interface maintains a table indexed according to these
numbers
• The system call interface invokes the intended system call in OS kernel
and returns status of the system call and any return values
• The caller need know nothing about how the system call is implemented
• Just needs to obey Application Programming Interface (API) and
understand what OS will do as a result call
• Most details of OS interface hidden from programmer by Application
Programming Interface (API)
• Managed by run-time support library (set of functions built into libraries
included with compiler)
Application Programming Interface (API) – System Call – OS Relationship
9
The caller need know nothing about how the system call is implemented
or what it does during execution. Rather, the caller need only obey the Application
Programming Interface (API) and understand what the operating system will do
as a result of the execution of that system call. Thus, most of the details of the
operating-system interface are hidden from the programmer by the Application
Programming Interface (API) and are managed by the run-time support library.
The relationship between an Application Programming Interface (API), the
system-call interface, and the operating system is shown in Figure 6, which
illustrates how the operating system handles a user application invoking the
open() system call.
Figure 6. The handling of a user application invoking the open() system call
(Operating System. http://www.os-book.com).
System Call Parameter Passing
Three general methods used to pass parameters to the OS

Figure 7 shows the passing parameter to the operating system described
in three methods:
• Simplest: pass the parameters in registers
o In some cases, may be more parameters than registers
• Parameters stored in a block, or table, in memory, and address of block
passed as a parameter in a register
o This approach taken by Linux and Solaris
• Parameters placed, or pushed, onto the stack by the program and popped off
the stack by the operating system
• Block and stack methods do not limit the number or length of parameters
being passed
10
Figure 7. Passing of parameters as a table (Operating System. http://www.os-
book.com).
• Often, more information is required than simply identity of desired system call
o Exact type and amount of information vary according to OS and call
Six Types or Category of System Calls
1. Process control
• create process, terminate process
• end, abort
• load, execute
• get process attributes, set process attributes
• wait for time
• wait event, signal event
• allocate and free memory
• Dump memory if error
• Debugger for determining bugs, single step execution
• Locks for managing access to shared data between processes
A running program needs to be able to halt its execution either normally

(end()) or abnormally (abort()). If a system call is made to terminate the currently
running program abnormally, or if the program runs into a problem and causes
an error trap, a dump of memory is sometimes taken and an error message
generated. The dump is written to disk and may be examined by a debugger—a
system program designed to aid the programmer in finding and correcting errors,
or bugs—to determine the cause of the problem. Under either normal or abnormal
circumstances, the operating system must transfer control to the invoking
command interpreter. The command interpreter then reads the next command.
In an interactive system, the command interpreter simply continues with the next
command; it is assumed that the user will issue an appropriate command to
respond to any error.
The figure 8 below shows the standard C library provides a portion of the
system-call interface for many versions of UNIX and Linux. As an example, let’s
assume a C program invokes the printf() statement. The C library intercepts this
call and invokes the necessary system call (or calls) in the operating system—in
this instance, the write() system call. The C library takes the value returned by
write() and passes it back to the user program.
11
Figure 8. System Call Interface using C program invoking printf() library call,
which calls write() system call (Operating System. http://www.os-book.com).
There are so many facets of and variations in process and job control that we
next use two examples—one involving a single-tasking system and the other a
multitasking system—to clarify these concepts. Figure 9 shows the MS-DOS operating
system is an example of a single-tasking system. It has a command interpreter that is
invoked when the computer is started.
• Single-tasking
• Shell invoked when system
booted
• Simple method to run program
• No process created
• Single memory space
• Loads program into memory,
overwriting all but the kernel
• Program exit -> shell reloaded
Figure 9. MS-DOS execution. (a) At system startup. (b) Running a program (Operating
FreeBSD (derived from Berkeley UNIX) is an example of a multitasking system.

When a user logs on to the system, the shell of the user’s choice is run. This shell is
similar to the MS-DOS shell in that it accepts commands and executes programs that
the user requests. Figure 10 shows the command interpreter may continue running
while another program is executed or known as multitasking.
12
• Unix variant
• Multitasking
• User login -> invoke user’s choice of
shell
• Shell executes fork() system call to
create process
o Executes exec() to load program
into process
o Shell waits for process to
terminate or continues with
user commands
• Process exits with:
o code = 0 – no error
o code > 0 – error code
Figure 10. FreeBSD running multiple programs (Operating System.

2. File management
• create file, delete file
• open, close file
• read, write, reposition
• get and set file attributes
We first need to be able to create() and delete() files. Either system call
requires the name of the file and perhaps some of the file’s attributes. Once the
file is created, we need to open() it and to use it. We may also read(), write(), or
reposition() (rewind or skip to the end of the file, for example).
Finally, we need to close() the file, indicating that we are no longer using
it. We may need these same sets of operations for directories if we have a directory
structure for organizing files in the file system. In addition, for either files or
directories, we need to be able to determine the values of various attributes and
perhaps to reset them if necessary.
File attributes include the file name, file type, protection codes, accounting
information, and so on. At least two system calls, get file attributes() and set file
attributes(), are required for this function. Some operating systems provide many
more calls, such as calls for file move() and copy(). Others might provide an
Application Programming Interface (API) that performs those operations using
code and other system calls, and others might provide system programs to
perform those tasks. If the system programs are callable by other programs, then
each can be considered an Application Programming Interface (API) by other
system programs.
3. Device management
• request device, release device
• read, write, reposition
• get device attributes, set device attributes
• logically attach or detach devices
A process may need several resources to execute—main memory, disk

drives, access to files, and so on. If the resources are available, they can be
granted, and control can be returned to the user process. Otherwise, the process
will have to wait until sufficient resources are available.
13
The various resources controlled by the operating system can be thought
of as devices. Some of these devices are physical devices (for example, disk
drives), while others can be thought of as abstract or virtual devices (for example,
files). A system with multiple users may require us to first request() a device, to
ensure exclusive use of it. After we are finished with the device, we release() it.
These functions are similar to the open() and close() system The hazard then is
the potential for device contention and perhaps deadlock.
Once the device has been requested (and allocated to us), we can read(),
write(), and (possibly) reposition() the device, just as we can with files. In fact, the
similarity between I/O devices and files is so great that many operating systems,
including UNIX, merge the two into a combined file–device structure. In this case,
a set of system calls is used on both files and devices. Sometimes, I/O devices
are identified by special file names, directory placement, or file attributes.
The user interface can also make files and devices appear to be similar,
even though the underlying system calls are dissimilar. This is another example
of the many design decisions that go into building an operating system and user
interface.
4. Information maintenance
• get time or date, set time or date
• get system data, set system data
• get and set process, file, or device attributes
Many system calls exist simply for the purpose of transferring information
between the user program and the operating system. For example, most systems
have a system call to return the current time() and date(). Other system calls may
return information about the system, such as the number of current users, the
version number of the operating system, the amount of free memory or disk
space, and so on.
Another set of system calls is helpful in debugging a program. Many

systems provide system calls to dump() memory. This provision is useful for
debugging. A program trace lists each system call as it is executed. Even
microprocessors provide a CPU mode known as single step, in which a trap is
executed by the CPU after every instruction. The trap is usually caught by a
debugger.
Many operating systems provide a time profile of a program to indicate the

amount of time that the program executes at a particular location or set of
locations. A time profile requires either a tracing facility or regular timer
interrupts. At every occurrence of the timer interrupt, the value of the program
counter is recorded. With sufficiently frequent timer interrupts, a statistical
picture of the time spent on various parts of the program can be obtained.
In addition, the operating system keeps information about all its

processes, and system calls are used to access this information. Generally, calls
are also used to reset the process information (get process attributes() and set
process attributes()).
5. Communications
• create, delete communication connection
• send, receive messages if message passing model to host name or process
name
• From client to server
• Shared-memory model create and gain access to memory regions
• transfer status information
• attach and detach remote devices
14
There are two common models of interprocess communication: the
message passing model and the shared-memory model. In the message-passing
model, the communicating processes exchange messages with one another to
transfer information. Messages can be exchanged between the processes either
directly or indirectly through a common mailbox. Before communication can take
place, a connection must be opened. The name of the other communicator must
be known, be it another process on the same system or a process on another
computer connected by a communications network. Each computer in a network
has a host name by which it is commonly known. A host also has a network
identifier, such as an IP address. Similarly, each process has a process name,
and this name is translated into an identifier by which the operating system can
refer to the process. The get hostid() and get processid() system calls do this
translation. The identifiers are then passed to the general purpose open() and
close() calls provided by the file system or to specific open connection() and close
connection() system calls, depending on the system’s model of communication.
The recipient process usually must give its permission for communication to take
place with an accept connection() call. Most processes that will be receiving
connections are special-purpose daemons, which are system programs provided
for that purpose. They execute a wait for connection() call and are awakened when
a connection is made.
The source of the communication, known as the client, and the receiving
daemon, known as a server, then exchange messages by using read message()
and write message() system calls. The close connection() call terminates the
communication.
In the shared-memory model, processes use shared memory create() and

shared memory attach() system calls to create and gain access to regions of
memory owned by other processes.
6. Protection
• Control access to resources
• Get and set permissions
• Allow and deny user access
Protection provides a mechanism for controlling access to the resources

provided by a computer system. Historically, protection was a concern only on
multiprogrammed computer systems with several users. However, with the
advent of networking and the Internet, all computer systems, from servers to
mobile handheld devices, must be concerned with protection.
Typically, system calls providing protection include set permission() and

get permission(), which manipulate the permission settings of resources such as
files and disks. The allow user() and deny user() system calls specify whether
particular users can—or cannot—be allowed access to certain resources.
System Programs
System programs provide a convenient environment for program

development and execution. They can be divided into:
o File manipulation
o Status information sometimes stored in a File modification
o Programming language support
o Program loading and execution
o Communications
o Background services
o Application programs
15
Most users’ view of the operation system is defined by system programs,
not the actual system calls
• Provide a convenient environment for program development and execution

o Some of them are simply user interfaces to system calls; others are
considerably more complex
• File management - Create, delete, copy, rename, print, dump, list, and
generally manipulate files and directories
• Status information
o Some ask the system for info - date, time, amount of available
memory, disk space, number of users
o Others provide detailed performance, logging, and debugging
information
o Typically, these programs format and print the output to the
terminal or other output devices
o Some systems implement a registry - used to store and retrieve
configuration information
• File modification
o Text editors to create and modify files
o Special commands to search contents of files or perform
transformations of the text
• Programming-language support - Compilers, assemblers, debuggers and
interpreters sometimes provided
o Program loading and execution- Absolute loaders, relocatable
loaders, linkage editors, and overlay-loaders, debugging systems for
higher-level and machine language
• Communications - Provide the mechanism for creating virtual
connections among processes, users, and computer systems
o Allow users to send messages to one another’s screens, browse web
pages, send electronic-mail messages, log in remotely, transfer files
from one machine to another
• Background Services
o Launch at boot time
▪ Some for system startup, then terminate
▪ Some from system boot to shutdown
o Provide facilities like disk checking, process scheduling, error
logging, printing
o Run in user context not kernel context
o Known as services, subsystems, daemons
• Application programs
o Don’t pertain to system
o Run by users
o Not typically considered part of OS
o Launched by command line, mouse click, finger poke
Operating System Design and Implementation

o Design and Implementation of OS not “solvable”, but some approaches have
proven successful
o Internal structure of different Operating Systems can vary widely
o Start the design by defining goals and specifications
o Affected by choice of hardware, type of system
o User goals and System goals
o User goals – operating system should be convenient to use, easy to learn,
reliable, safe, and fast
o System goals – operating system should be easy to design, implement, and
maintain, as well as flexible, reliable, error-free, and efficient
o Important principle to separate
o Policy: What will be done?
o Mechanism: How to do it?
o Mechanisms determine how to do something, policies decide what will be done
16
o The separation of policy from mechanism is a very important principle, it allows
maximum flexibility if policy decisions are to be changed later (example – timer)
o Specifying and designing an OS is highly creative task of software engineering
Implementation
o Much variation
o Early OSes in assembly language
o Then system programming languages like Algol, PL/1
o Now C, C++
o Actually usually a mix of languages
o Lowest levels in assembly
o Main body in C
o Systems programs in C, C++, scripting languages like PERL, Python, shell
scripts
o More high-level language easier to port to other hardware
o But slower
o Emulation can allow an OS to run on non-native hardware
Operating System Structure

o General-purpose OS is very large program
o Various ways to structure ones
o Simple structure – MS-DOS
o More complex -- UNIX
o Layered – an abstrcation
o Microkernel -Mach
Simple Structure -- MS-DOS
Figure 11. MS-DOS layer structure (Operating System. http://www.os-

book.com).
o Figure 11 shows that Microsoft Disk Operating System (MS-DOS) was originally
designed and implemented by a few people who had no idea that it would
become so popular. It was written to provide the most functionality in the least
space, so it was not carefully divided into modules.
o MS-DOS – written to provide the most functionality in the least space
o Not divided into modules
o Although MS-DOS has some structure, its interfaces and levels of
functionality are not well separated
17
Non Simple Structure -- UNIX
Figure 12. Traditional UNIX system structure (Operating System. http://www.os-

book.com).
o UNIX – limited by hardware functionality, the original UNIX operating

system had limited structuring. The UNIX OS consists of two separable
parts: the kernel and the system programs. The kernel is further separated
into a series of interfaces and device drivers, which have been added and
expanded over the years as UNIX has evolved. Figure 12 shows the
traditional UNIX operating system as being layered to some extent.
Systems programs
o The kernel
o Consists of everything below the system-call interface and above the
physical hardware
o Provides the file system, CPU scheduling, memory management,
and other operating-system functions; a large number of functions
for one level
o This monolithic structure was difficult to implement and maintain. It had
a distinct performance advantage, however: there is very little overhead in
the system call interface or in communication within the kernel.
o UNIX signifies that beyond simple but not fully layered
18
Layered Approach
Figure 13 A layered operating system (Operating System. http://www.os-book.com).
o The operating system is divided into a number of layers (levels), each built on top of
lower layers. The bottom layer (layer 0), is the hardware; the highest (layer N) is the
user interface.
o With modularity, layers are selected such that each uses functions (operations) and
services of only lower-level layers
o The major difficulty with the layered approach involves appropriately defining the
various layers. Because a layer can use only lower-level layers, careful planning is
necessary. For example, the device driver for the backing store (disk space used by
virtual-memory algorithms) must be at a lower level than the memory-management
routines, because memory management requires the ability to use the backing store.
Microkernel System Structure
Application File Device user

Program System Driver mode
messages messages
Interprocess memory CPU kernel

Communication managment scheduling mode
microkernel
hardware
Figure 14 Architecture of a typical microkernel (Operating System. http://www.os-

book.com).
o Moves as much from the kernel into user space

o Mach example of microkernel
o Mac OS X kernel (Darwin) partly based on Mach
o Communication takes place between user modules using message passing
o Benefits:
o Easier to extend a microkernel
o Easier to port the operating system to new architectures
o More reliable (less code is running in kernel mode)
19
o More secure
o Detriments:
o Performance overhead of user space to kernel space communication
Modules
o Many modern operating systems implement loadable kernel modules
o Uses object-oriented approach
o Each core component is separate
o Each talks to the others over known interfaces
o Each is loadable as needed within the kernel
o Overall, similar to layers but with more flexible
o Linux, Solaris, etc
Solaris Modular Approach
Figure 15. Solaris loadable modules (Operating System. http://www.os-

book.com).
Figure 15 shows the Solaris operating system structure is organized

around a core kernel with seven types of loadable kernel modules such as
scheduling classes, file systems, loadable system calls, executable formats,
STREAMS modules, miscellaneous, and device and bus drivers.
Hybrid Systems
o Most modern operating systems are actually not one pure model
o Hybrid combines multiple approaches to address performance, security,
usability needs
o Linux and Solaris kernels in kernel address space, so monolithic, plus
modular for dynamic loading of functionality
o Windows mostly monolithic, plus microkernel for different subsystem
personalities
o Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming environment
o Below is kernel consisting of Mach microkernel and BSD Unix parts, plus
I/O kit and dynamically loadable modules (called kernel extensions)
Example of Hybrid System –

A. Mac OS X Structure
o Figure 16 shows the Apple Mac OS X operating system uses a hybrid
structure and it is layered system. The top layers include the Aqua user
interface and a set of application environments and services. Notably, the
Cocoa environment specifies an Application Programming Interface (API)
for the Objective-C programming language, which is used for writing Mac
OS X applications. Below these layers is the kernel environment, which
consists primarily of the Mach microkernel and the BSD UNIX kernel.
Mach provides memory management; support for remote procedure calls
(RPCs) and interprocess communication (IPC) facilities, including message
20
passing; and thread scheduling. The BSD component provides a BSD
command-line interface, support for networking and file systems, and an
implementation of POSIX Application Programming Interface (API)s,
including Pthreads.
o In addition to Mach and BSD, the kernel environment provides an I/O kit
for development of device drivers and dynamically loadable modules
(which Mac OS X refers to as kernel extensions). The BSD application
environment can make use of BSD facilities directly.
graphical user interface

Aqua
application environments and services
Java Cocoa Quicktime BSD
kernel environment
BSD
Mach
I/O kit kernel extensions

Figure 16. The Mac OS X structure (Operating System. http://www.os-
book.com).
B. iOS
o Apple mobile OS for iPhone, iPad
o Structured on Mac OS X, added functionality
o Does not run OS X applications natively
o Also runs on different CPU architecture (ARM vs. Intel)
o Cocoa Touch Objective-C Application Programming Interface (API) for
developing apps
o Media services layer for graphics, audio, video
o Core services provides cloud computing, databases
o Core operating system, based on Mac OS X kernel
Figure 17. Architecture of Apple’s iOS (Operating System.

21
C. Android
o Figure 18 shows the modified by Google and the bottom of this

software stack is the Linux kernel and is currently outside the normal
distribution of Linux releases
o Developed by Open Handset Alliance (mostly Google)
o Open Source
o Similar stack to IOS
o Based on Linux kernel but modified
o Provides process, memory, device-driver management
o Adds power management
o Runtime environment includes core set of libraries and Dalvik virtual
machine
o Apps developed in Java plus Android Application Programming
Interface (API)
▪ Java class files compiled to Java bytecode then translated
to executable than runs in Dalvik VM
o
Applications
Libraries include frameworks for web browser (webkit), database
(SQLite), multimedia, smaller libc
Application Framework
Libraries Android runtime
SQLite openGL Core Libraries
surface media
Dalvik
manager framework
virtual machine
webkit libc
Figure 18. Architecture of Google’s Android (Operating System.

Linux kernel
Operating-System Debugging
o Debugging is finding and fixing errors, or bugs
o OS generate log files containing error information
o Failure of an application can generate core dump file capturing memory of the
process
o Operating system failure can generate crash dump file containing kernel memory
o Beyond crashes, performance tuning can optimize system performance
o Sometimes using trace listings of activities, recorded for analysis
o Profiling is periodic sampling of instruction pointer to look for statistical
trends
o Kernighan’s Law: “Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.”
Performance Tuning
o Improve performance by removing bottlenecks
o OS must provide means of computing and displaying measures of system
behavior
o For example, “top” program or Windows Task Manager
22
Figure 19. Windows Task Manager (Operating System. http://www.os-
book.com).
DTrace
• DTrace tool in Solaris, FreeBSD, Mac OS X allows live instrumentation on
production systems
o Probes fire when code is executed within a provider, capturing state data
and sending it to consumers of those probes
• Example of following XEventsQueued system call move from libc library to kernel
and back
Figure 20. Solaris 10 dtrace follows a system call within the kernel (Operating
• DTrace code to record amount of time each process with UserID 101 is in running
mode (on CPU) in nanoseconds
23
Operating System Generation
1. Operating systems are designed to run on any of a class of machines; the system
must be configured for each specific computer site
2. SYSGEN program obtains information concerning the specific configuration of
the hardware system
o Used to build system-specific compiled kernel or system-tuned
o Can general more efficient code than one general kernel
System Boot
• The procedure of starting a computer by loading the kernel is known as booting
the system.
• When power initialized on system, execution starts at a fixed memory location
o Firmware ROM used to hold initial boot code
o All forms of ROM are also known as firmware
• Operating system must be made available to hardware so hardware can start it
o Small piece of code – bootstrap loader, stored in Read-on-Memory (ROM)
or erasable programmable read-only memory (EEPROM) locates the
kernel, loads it into memory, and starts it execution
o Sometimes two-step process where boot block at fixed location loaded by
ROM code, which loads bootstrap loader from disk
o Common bootstrap loader, GRUB (example of an open-source bootstrap
program for Linux systems), allows selection of kernel from multiple
disks, versions, kernel options
• Kernel loads and system is then running
SUMMARY
Operating systems provide a number of services. At the lowest level, system calls
allow a running program to make requests from the operating system directly. At a
higher level, the command interpreter or shell provides a mechanism for a user to issue
a request without writing a program. Commands may come from files during batch-
mode execution or directly from a terminal or desktop GUI when in an interactive or
time-shared mode. System programs are provided to satisfy many common user
requests.
The types of requests vary according to level. The system-call level must provide
the basic functions, such as process control and file and device manipulation. Higher-
level requests, satisfied by the command interpreter or system programs, are translated
into a sequence of system calls. System services can be classified into several categories:
program control, status requests, and I/O requests. Program errors can be considered
implicit requests for service.
The design of a new operating system is a major task. It is important that the
goals of the system be well defined before the design begins. The type of system desired
is the foundation for choices among various algorithms and strategies that will be
needed.
Throughout the entire design cycle, we must be careful to separate policy

decisions from implementation details (mechanisms). This separation allows maximum
flexibility if policy decisions are to be changed later. Once an operating system is
designed, it must be implemented. Operating systems today are almost always written
in a systems-implementation language or in a higher-level language. This feature
improves their implementation, maintenance, and portability.
A system as large and complex as a modern operating system must be engineered

carefully. Modularity is important. Designing a system as a sequence of layers or using
a microkernel is considered a good technique. Many operating systems now support
dynamically loaded modules, which allow adding functionality to an operating system
24
while it is executing. Generally, operating systems adopt a hybrid approach that
combines several different types of structures.
Debugging process and kernel failures can be accomplished through the use of
debuggers and other tools that analyze core dumps. Tools such as DTrace analyze
production systems to find bottlenecks and understand other system behavior.
To create an operating system for a particular machine configuration, we must

perform system generation. For the computer system to begin running, the CPU must
initialize and start executing the bootstrap program in firmware.
The bootstrap can execute the operating system directly if the operating system
is also in the firmware, or it can complete a sequence in which it loads progressively
smarter programs from firmware and disk until the operating system itself is loaded into
memory and executed.
It may be a good idea to review the basic concepts of machine organization and
assembly language programming. You should be comfortable with the concepts of
memory, CPU, registers, I/O, interrupts, instructions, and the instruction execution
cycle. Since the operating system is the interface between the hardware and user
programs, a good understanding of operating systems requires an understanding of
both hardware and programs.
It’s Your Turn.
Program Activity.
1. Based on the Figure below, make this program using JAVA. Be sure to
include all necessary error checking, including ensuring that the source file
exists. Once you have correctly designed and tested the program, if you
used a system that supports it, run the program using a utility that traces
system calls. Pass your program either written or computerized in a clean
short coupon bond.
Operating System. http://www.os-book.com
25
LESSON 2 - PROCESS
Objectives
1. introduce the notion of a process—a program in execution, which forms the
basis of all computation;
2. describe the various features of processes, including scheduling, creation, and
termination;
3. explore interprocess communication using shared memory and message
passing; and,
4. describe communication in client–server systems.
LET’S ENGAGE
Early computers allowed only one program to be executed at a time. This program
had complete control of the system and had access to all the system’s resources. In
contrast, contemporary computer systems allow multiple programs to be loaded into
memory and executed concurrently. This evolution required firmer control and more
compartmentalization of the various programs; and these needs resulted in the notion
of a process, which is a program in execution. A process is the unit of work in a modern
time-sharing system.
In this lesson we introduce the concepts of a process and concurrent execution.

These concepts are at the very heart of modern operating systems. A process is a
program in execution and is the unit of work in a modern time-sharing system. Such a
system consists of a collection of processes: Operating-system processes executing
system code and user processes executing user code. All these processes can potentially
execute concurrently, with the CPU (or CPUs) multiplexed among them. By switching
the CPU between processes, the operating system can make the computer more
productive. We also introduce the notion of a thread (lightweight process) and
interprocess communication (IPC).
A process can be thought of as a program in execution. A process will need certain

resources—such as CPU time, memory, files, and I/O devices —to accomplish its task.
These resources are allocated to the process either when it is created or while it is
executing.
A process is the unit of work in most systems. Systems consist of a collection of

processes: operating-system processes execute system code, and user processes execute
user code. All these processes may execute concurrently.
Although traditionally a process contained only a single thread of control as it

ran, most modern operating systems now support processes that have multiple threads.
The operating system is responsible for several important aspects of process and thread
management: the creation and deletion of both user and system processes; the
scheduling of processes; and the provision of mechanisms for synchronization,
communication, and deadlock handling for processes.
LET’S TALK ABOUT IT
1. Process Concept
A question that arises in discussing operating systems involves what to call all
the Central Processing Unit (CPU) activities. A batch system executes jobs, whereas a
time-shared system has user programs or tasks. Even on a single-user system, a user
26
may be able to run several programs at one time: a word processor, a Web browser, and
an e-mail package. And even if a user can execute only one program at a time, such as
on an embedded device that does not support multitasking, the operating system may
need to support its own internal programmed activities, such as memory management.
In many respects, all these activities are similar, so we call all of them processes.
The terms job and process are used almost interchangeably in this text. Although
we personally prefer the term process, much of operating-system theory and terminology
was developed during a time when the major activity of operating systems was job
processing. It would be misleading to avoid the use of commonly accepted terms that
include the word job (such as job scheduling) simply because process has superseded
job.
o Process – a program in execution; process execution must progress in

sequential fashion
o Multiple parts
▪ The program code, also called text section
▪ Current activity including program counter, processor registers
▪ Stack containing temporary data
▪ Function parameters, return addresses, local variables
▪ Data section containing global variables
▪ Heap containing memory dynamically allocated during run time
o Program is passive entity stored on disk (executable file), process is
active
o Program becomes process when executable file loaded into memory
o Execution of program started via GUI mouse clicks, command line entry
of its name, etc
o One program can be several processes
▪ Consider multiple users executing the same program
Figure 21. Process in Memory (Operating System. http://www.os-book.com).
1.1 Process State

o Figure 22 shows the diagram of process state that each process is
represented in the operating system by a process control block (PCB)—
also called a task control block
o As a process executes, it changes state
o new: The process is being created
o running: Instructions are being executed
o waiting: The process is waiting for some event to occur
o ready: The process is waiting to be assigned to a processor
27
o terminated: The process has finished execution
▪ The states that they represent are found on all systems, however. Certain
operating systems also more ﬁnely delineate process states. It is
important to realize that only one process can be running on any
processor at any instant. Many processes may be ready and waiting
Figure 22. Diagram of process state (Operating System. http://www.os-

book.com).
1.2 Process Control Block (PCB)

▪ PCB simply serves as the repository for any information that may vary
from process to process.
o Information associated with each process (also called task control block)
▪ Process state – running, waiting, etc
▪ Program counter – location of instruction to next execute
▪ CPU registers – contents of all process-centric registers. Along
with the program counter, this state information must be saved
when an interrupt occurs, to allow the process to be continued
correctly afterward that shown in figure 24.
▪ CPU scheduling information- priorities, scheduling queue pointers
▪ Memory-management information – memory allocated to the
process
▪ Accounting information – CPU used, clock time elapsed since
start, time limits
▪ I/O status information – I/O devices allocated to process, list of
open files
Figure 23. Process control block (PCB) (Operating System.

28
Figure 24. Diagram showing CPU switch from process to process
1.3 Threads
▪ So far, process has a single thread of execution
▪ Consider having multiple program counters per process
o Multiple locations can execute at once
▪ Multiple threads of control -> threads
▪ Must then have storage for thread details, multiple program counters in
PCB
2. Process Scheduling
▪ Maximize CPU use, quickly switch processes onto CPU for time sharing
▪ Process scheduler selects among available processes for next execution on CPU
▪ Maintains scheduling queues of processes
o Job queue – set of all processes in the system
o Ready queue – set of all processes residing in main memory, ready and
waiting to execute
o Device queues – set of processes waiting for an I/O device
o Processes migrate among the various queues
29
Figure 25. Ready Queue and Various I/O Device Queues (Operating System.
2.1 Scheduling Queues

▪ Figure 26 shows the Queueing diagram represents queues, resources,
flows
▪
Figure 26. Representation of Process Scheduling (Operating System.

2.2 Schedulers
▪ Short-term scheduler (or CPU scheduler) – selects which process
should be executed next and allocates CPU
o Sometimes the only scheduler in a system
o Short-term scheduler is invoked frequently (milliseconds) 
(must be fast)
▪ Long-term scheduler (or job scheduler) – selects which processes
should be brought into the ready queue
o Long-term scheduler is invoked infrequently (seconds,
minutes)  (may be slow)
o The long-term scheduler controls the degree of
multiprogramming
30
▪ Processes can be described as either:
o I/O-bound process – spends more time doing I/O than
computations, many short CPU bursts
o CPU-bound process – spends more time doing computations;
few very long CPU bursts
▪ Long-term scheduler strives for good process mix
Addition of Medium Term Scheduling

• Medium-term scheduler can be added if degree of multiple
programming needs to decrease
o Remove process from memory, store on disk, bring back in
from disk to continue execution: swapping
Figure 27. Addition of Medium Term Scheduling (Operating System.

▪ Multitasking in Mobile Systems

▪ Some mobile systems (e.g., early version of iOS) allow only
one process to run, others suspended
▪ Due to screen real estate, user interface limits iOS provides
for a
▪ Single foreground process- controlled via user
interface
▪ Multiple background processes– in memory, running,
but not on the display, and with limits
▪ Limits include single, short task, receiving
notification of events, specific long-running tasks like
audio playback
▪ Android runs foreground and background, with fewer limits
▪ Background process uses a service to perform tasks
▪ Service can keep running even if background process
is suspended
▪ Service has no user interface, small memory use
2.3 Context Switch

▪ When CPU switches to another process, the system must save the
state of the old process and load the saved state for the new
process via a context switch
▪ Context of a process represented in the PCB
▪ Context-switch time is overhead; the system does no useful work
while switching
▪ The more complex the OS and the PCB ➔ the longer the
context switch
▪ Time dependent on hardware support
▪ Some hardware provides multiple sets of registers per CPU
➔ multiple contexts loaded at once
31
3. Operations on Processes
• The processes in most systems can execute concurrently, and they maybe
created and deleted dynamically. Thus, these systems must provide a
mechanism for process creation and termination.
3.1 Process Creation

o Parent process create children processes, which, in turn create other
processes, forming a tree of processes
o Generally, process identified and managed via a process identifier (pid)
o Resource sharing options
▪ Parent and children share all resources
▪ Children share subset of parent’s resources
▪ Parent and child share no resources
o Execution options
▪ Parent and children execute concurrently
▪ Parent waits until children terminate
o Figure 28 shows the recursively tracing parent processes all the way to the
init process. On UNIX and Linux systems, we can obtain a listing of
processes by using the ps command. For example, the command ps –el
will list complete information for all processes currently active in the
system. It is easy to construct a process tree similar to the one shown in
Figure 28.
init
pid = 1
login kthreadd sshd

pid = 8415 pid = 2 pid = 3028
bash khelper pdflush sshd

pid = 8416 pid = 6 pid = 200 pid = 3610
emacs tcsch
ps
pid = 9204 pid = 4005
pid = 9298
Figure 28. A Tree of Processes in Linux (Operating System.

Address space
▪ Child duplicate of parent
▪ Child has a program loaded into it
UNIX examples
▪ fork() system call creates new process
▪ exec() system call used after a fork() to replace the process’
memory space with a new program
32
Figure 29 Process creation using the fork() system call (Operating
o C Program Forking Separate Process
Figure 30. Creating a separate process using the UNIX fork() system call.
o Creating a Separate Process via Windows Application Programming

Interface (API)
Figure 31. Creating a separate process using the Windows Application

Programming Interface (API).
3.2 Process Termination
33
• Process executes last statement and then asks the operating system to delete it
using the exit() system call.
o Returns status data from child to parent (via wait())
o Process’ resources are deallocated by operating system
• Parent may terminate the execution of children processes using the abort()
system call. Some reasons for doing so:
o Child has exceeded allocated resources
o Task assigned to child is no longer required
o The parent is exiting and the operating systems does not allow a child to
continue if its parent terminates
• Some operating systems do not allow child to exists if its parent has terminated.
If a process terminates, then all its children must also be terminated.
o cascading termination. All children, grandchildren, etc. are terminated.
o The termination is initiated by the operating system.
• The parent process may wait for termination of a child process by using the
wait()system call. The call returns status information and the pid of the
terminated process
pid = wait(&status);
• If no parent waiting (did not invoke wait()) process is a zombie
• If parent terminated without invoking wait , process is an orphan
Multiprocess Architecture – Chrome Browser

o Many web browsers ran as single process (some still do)
▪ If one web site causes trouble, entire browser can hang or crash
o Google Chrome Browser is multiprocess with 3 different types of
processes:
▪ Browser process manages user interface, disk and network I/O
▪ Renderer process renders web pages, deals with HTML,
Javascript. A new renderer created for each website opened
▪ Runs in sandbox restricting disk and network I/O,
minimizing effect of security exploits
▪ Plug-in process for each type of plug-in
4. Interprocess Communication
• Processes within a system may be independent or cooperating
• Cooperating process can affect or be affected by other processes, including
sharing data
• Reasons for cooperating processes:
o Information sharing. Since several users may be interested in the same
piece of information (for instance, a shared file), we must provide an
environment to allow concurrent access to such information.
o Computation speedup. If we want a particular task to run faster, we must
break it into subtasks, each of which will be executing in parallel with the
others. Notice that such a speedup can be achieved only if the computer
has multiple processing cores.
o Modularity. We may want to construct the system in a modular fashion,
dividing the system functions into separate processes or threads was
elaborated in the module 1.
o Convenience. Even an individual user may work on many tasks at the
same time. For instance, a user may be editing, listening to music, and
compiling in parallel.
34
• Cooperating processes need interprocess communication (IPC) –
mechanism that will allow them to exchange data and information
• Two models of IPC
o Shared memory - a region of memory that is shared by cooperating
processes is established. Processes can then exchange information by
reading and writing data to the shared region.
o Message passing - communication takes place by means of messages
exchanged between the cooperating processes.
Figure 31 Communications models. (a) Message passing. (b) Shared memory

Shared memory - Cooperating Processes

• Independent process cannot affect or be affected by the execution of
another process
• Cooperating process can affect or be affected by the execution of another
process
• Advantages of process cooperation
o Information sharing
o Computation speed-up
o Modularity
o Convenience
Producer-Consumer Problem
▪ Paradigm for cooperating processes, producer process produces
information that is consumed by a consumer process
▪ unbounded-buffer places no practical limit on the size of
the buffer
▪ bounded-buffer assumes that there is a fixed buffer size
▪ Bounded-Buffer – Shared-Memory Solution

▪ Shared data
#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
▪ Solution is correct, but can only use BUFFER_SIZE-1
elements
▪ Bounded-Buffer – Producer
item next_produced;
35
while (true) {
/* produce an item in next produced */
while (((in + 1) % BUFFER_SIZE) == out)
; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
}
▪ Bounded Buffer – Consumer

item next_consumed;
while (true) {
while (in == out)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
/* consume the item in next consumed */
}
Interprocess Communication – Shared Memory

▪ An area of memory shared among the processes that wish to
communicate
▪ The communication is under the control of the users processes
not the operating system.
▪ Major issues is to provide mechanism that will allow the user
processes to synchronize their actions when they access shared
memory.
Interprocess Communication – Message Passing

▪ Mechanism for processes to communicate and to synchronize
their actions
▪ Message system – processes communicate with each other without
resorting to shared variables
▪ IPC facility provides two operations:
▪ send(message)
▪ receive(message)
▪ The message size is either fixed or variable
▪ If processes P and Q wish to communicate, they need to:
▪ Establish a communication link between them
▪ Exchange messages via send/receive
▪ Implementation issues:
▪ How are links established?
▪ Can a link be associated with more than two processes?
▪ How many links can there be between every pair of
communicating processes?
▪ What is the capacity of a link?
▪ Is the size of a message that the link can accommodate
fixed or variable?
▪ Is a link unidirectional or bi-directional?
▪ Implementation of communication link
▪ Physical:
▪ Shared memory
▪ Hardware bus
▪ Network
▪ Logical:
▪ Direct or indirect
▪ Synchronous or asynchronous
▪ Automatic or explicit buffering
1. Direct Communication
▪ Processes must name each other explicitly:
▪ send (P, message) – send a message to process P
36
▪ receive(Q, message) – receive a message from process
Q
▪ Properties of communication link
▪ Links are established automatically
▪ A link is associated with exactly one pair of
communicating processes
▪ Between each pair there exists exactly one link
▪ The link may be unidirectional, but is usually bi-
directional
Indirect Communication
▪ Messages are directed and received from mailboxes (also
referred to as ports)
▪ Each mailbox has a unique id
▪ Processes can communicate only if they share a
mailbox
▪ Properties of communication link
▪ Link established only if processes share a common
mailbox
▪ A link may be associated with many processes
▪ Each pair of processes may share several
communication links
▪ Link may be unidirectional or bi-directional
▪ Operations
▪ create a new mailbox (port)
▪ send and receive messages through mailbox
▪ destroy a mailbox
▪ Primitives are defined as:
▪ send(A, message) – send a message to mailbox A
▪ receive(A, message) – receive a message from mailbox
A
▪ Mailbox sharing
▪ P1, P2, and P3 share mailbox A
▪ P1, sends; P2 and P3 receive
▪ Who gets the message?
▪ Solutions
▪ Allow a link to be associated with at most two
processes
▪ Allow only one process at a time to execute a receive
operation
▪ Allow the system to select arbitrarily the receiver.
Sender is notified who the receiver was.
▪ 2. Synchronization
▪ Message passing may be either blocking or non-blocking
▪ Blocking is considered synchronous
▪ Blocking send -- the sender is blocked until the
message is received
▪ Blocking receive -- the receiver is blocked until a
message is available
▪ Non-blocking is considered asynchronous
▪ Non-blocking send -- the sender sends the message
and continue
▪ Non-blocking receive -- the receiver receives:
▪ A valid message, or
▪ Null message
▪ Different combinations possible
▪ If both send and receive are blocking, we have a
rendezvous
▪ Producer-consumer becomes trivial
message next_produced;
37
while (true) {
/* produce an item in next produced */
send(next_produced);
}
3. Buffering
▪ Queue of messages attached to the link.
▪ implemented in one of three ways
1. Zero capacity – no messages are queued on a link.
Sender must wait for receiver (rendezvous)
2. Bounded capacity – finite length of n messages
Sender must wait if link full
3. Unbounded capacity – infinite length
Sender never waits
5. Communications in Client-Server Systems

1. Sockets
• A socket is defined as an endpoint for communication
• Concatenation of IP address and port – a number included at start of
message packet to differentiate network services on a host
• The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8
• Communication consists between a pair of sockets
• All ports below 1024 are well known, used for standard services
• Special IP address 127.0.0.1 (loopback) to refer to system on which
process is running
• All connections must be unique. Therefore, if another process also on host
X wished to establish another connection with the same web server, it
would be assigned a port number greater than 1024 and not equal to 1625.
This ensures that all connections consist of a unique pair of sockets.
Figure 32. Communication using sockets (Operating System.

Socket Communication
• Sockets in Java
• Three types of sockets
o Connection-oriented (TCP)
o Connectionless (UDP)
o MulticastSocket class– data can be sent to multiple recipients
o Consider this “Date” server:
38
Figure 33. Date server.
2. Remote Procedure Calls

• Remote procedure call (RPC) abstracts procedure calls between processes on
networked systems
• Again uses ports for service differentiation
• Stubs – client-side proxy for the actual procedure on the server
• The client-side stub locates the server and marshalls the parameters
• The server-side stub receives this message, unpacks the marshalled
parameters, and performs the procedure on the server
• On Windows, stub code compile from specification written in Microsoft
Interface Definition Language (MIDL)
• Data representation handled via External Data Representation (XDL) format
to account for different architectures
1. Big-endian and little-endian
• Remote communication has more failure scenarios than local
1. Messages can be delivered exactly once rather than at most once
• OS typically provides a rendezvous (or matchmaker) service to connect client
and server
• Problem: The RPC scheme requires a similar binding of the client and the
server port, but how does a client know the port numbers on the server?
Neither system has full information about the other, because they do not
share memory.
• Solution: Two approaches are common.

1. Binding information may be predetermined, in the form of fixed port
addresses. At compile time, an RPC call has a fixed port number
associated with it. Once a program is compiled, the server cannot
change the port number of the requested service.
2. Figure 34 shows that binding can be done dynamically by a
rendezvous mechanism. Typically, an operating system provides a
rendezvous (also called a matchmaker) daemon on a fixed RPC port. A
client then sends a message containing the name of the RPC to the
rendezvous daemon requesting the port address of the RPC it needs
to execute. The port number is returned, and the RPC calls can be
39
sent to that port until the process terminates (or the server crashes).
This method requires the extra overhead of the initial request but is
more flexible than the first approach.
•
Figure 34 Execution of a remote procedure call (RPC) (Operating System.

Pipes
• Acts as a conduit allowing two processes to communicate
• Issues:
1. Is communication unidirectional or bidirectional?
2. In the case of two-way communication, is it half or full-duplex?
3. Must there exist a relationship (i.e., parent-child) between the
communicating processes?
4. Can the pipes be used over a network?
• Ordinary pipes – cannot be accessed from outside the process that created
it. Typically, a parent process creates a pipe and uses it to communicate
with a child process that it created.
• Named pipes – can be accessed without a parent-child relationship.
1. Ordinary Pipes
• Ordinary Pipes allow communication in standard producer-
consumer style
• Producer writes to one end (the write-end of the pipe)
• Consumer reads from the other end (the read-end of the pipe)
• Ordinary pipes are therefore unidirectional
• Require parent-child relationship between communicating
processes
• Windows calls these anonymous pipes
• See Unix and Windows code samples in textbook
2. Named Pipes
• Named Pipes are more powerful than ordinary pipes
• Communication is bidirectional
• No parent-child relationship is necessary between the
communicating processes
• Several processes can use the named pipe for communication
40
• Provided on both UNIX and Windows systems (examples are Dir
command in the Windows and ls command in the UNIX)
Summary
A process is a program in execution. As a process executes, it changes state. The
state of a process is defined by that process’s current activity. Each process may be in
one of the following states: new, ready, running, waiting, or terminated. Each process
is represented in the operating system by its own process control block (PCB).
A process, when it is not executing, is placed in some waiting queue. There are
two major classes of queues in an operating system: I/O request queues and the ready
queue. The ready queue contains all the processes that are ready to execute and are
waiting for the CPU. Each process is represented by a PCB.
The operating system must select processes from various scheduling queues.
Long-term (job) scheduling is the selection of processes that will be allowed to contend
for the CPU. Normally, long-term scheduling is heavily influenced by resource-allocation
considerations, especially memory management. Short-term (CPU) scheduling is the
selection of one process from the ready queue.
Operating systems must provide a mechanism for parent processes to create new
child processes. The parent may wait for its children to terminate before proceeding, or
the parent and children may execute concurrently. There are several reasons for
allowing concurrent execution: information sharing, computation speedup, modularity,
and convenience.
The processes executing in the operating system may be either independent

processes or cooperating processes. Cooperating processes require an interprocess
communication mechanism to communicate with each other. Principally,
communication is achieved through two schemes: shared memory and message
passing. The shared-memory method requires communicating processes to share some
variables. The processes are expected to exchange information through the use of these
shared variables. In a shared-memory system, the responsibility for providing
communication rests with the application programmers; the operating system needs to
provide only the shared memory. The message-passing method allows the processes to
exchange messages.
The responsibility for providing communication may rest with the operating
system itself. These two schemes are not mutually exclusive and can be used
simultaneously within a single operating system.
Communication in client–server systems may use (1) sockets, (2) remote

procedure calls (RPCs), or (3) pipes. A socket is defined as an endpoint for
communication. A connection between a pair of applications consists of a pair of
sockets, one at each end of the communication channel. RPCs are another form of
distributed communication. An RPC occurs when a process (or thread) calls a procedure
on a remote application. Pipes provide a relatively simple ways for processes to
communicate with one another. Ordinary pipes allow communication between parent
and child processes, while named pipes permit unrelated processes to communicate.
IT’S YOUR TURN
41
Direction: Read the passage carefully and plan what you will write. Place your answer
in the pad paper (yellow or white) to be submitted. Please answer the questions wisely
and must be supported based on the modules, books, or internet (attached the website of
your references). Each questions has 10 points each. The Essay rubrics have a
correspond points that will guide you in your essay.
Features 9-10 points 7-8 points 4-6 points 1-3 points
Expert Accomplished Capable Beginner
Understanding Writing shows Writing shows a Writing shows Writing shows
strong clear adequate little
understanding understanding understanding understanding
Quality of Piece was Piece was written Piece had little Piece had no style
Writing written in an in an interesting style
extraordinary style
style
Gives no new
Very informative Somewhat Gives some new information and
and well- informative and information but very poorly
organized organized poorly organized organized
Grammar, Virtually no Few spelling and A number of So many spelling,
Usage & spelling, punctuation spelling, punctuation and
Mechanics punctuation or errors, minor punctuation or grammatical
grammatical grammatical grammatical errors that it
errors errors errors interferes with the
meaning
QUESTIONS:
1. Provide two programming examples in which multithreading provides better
performance than a single-threaded solution.
2. What are two differences between user-level threads and kernel-level threads?
Under what circumstances is one type better than the other?
3. Describe the actions taken by a kernel to context-switch between kernel level
threads.
4. What resources are used when a thread is created? How do they differ from those
used when a process is created?
LESSON 3: Threads
Objectives:
1. Identify thoroughly the notion of a thread—a fundamental unit of CPU
utilization that forms the basis of multithreaded computer systems;
2. Analyze comprehensively the APIs for the Pthreads, Windows, and Java thread
libraries;
3. distinguish accurately strategies that provide implicit threading;
4. inspect thoroughly issues related to multithreaded programming; and
5. inspect thoroughly operating system support for threads in Windows and Linux.
Let’s Engage.
The basic idea is that the several components in any complex system will
perform particular subfunctions that contribute to the overall function.
—THE SCIENCES OF THE ARTIFICIAL, Herbert Simon
This lesson examines some more advanced concepts related to process

management, which are found in a number of contemporary operating systems. We
show that the concept of process is more complex and subtle than presented so far and
in fact embodies two separate and potentially independent concepts: one relating to
42
resource ownership and another relating to execution. This distinction has led to the
development, in many operating systems, of a construct known as the thread.
The process model introduced in lesson 2 of this module assumed that a process
was an executing program with a single thread of control. Virtually all modern operating
systems, however, provide features enabling a process to contain multiple threads of
control. In this lesson, we introduce many concepts associated with multithreaded
computer systems, including a discussion of the APIs for the Pthreads, Windows, and
Java thread libraries. We look at a number of issues related to multithreaded
programming and its effect on the design of operating systems. Finally, we explore how
the Windows and Linux operating systems support threads at the kernel level.
1. Overview
A thread is a basic unit of CPU utilization; it comprises a thread ID, a program

counter, a register set, and a stack. It shares with other threads belonging
to the same process its code section, data section, and other operating-system
resources, such as open files and signals. A traditional (or heavyweight) process
has a single thread of control. If a process has multiple threads of control, it
can perform more than one task at a time. Figure 35 illustrates the difference
between a traditional single-threaded process and a multithreaded process.
1. Motivation
o Most modern applications are multithreaded
o Figure 35 shows the single-thread and multithreaded processes were
threads run within application
o A web browser might have one thread display images or text while another
thread retrieves data from the network, for example. A word processor may
have a thread for displaying graphics, another thread for responding to
keystrokes from the user, and a third thread for performing spelling and
grammar checking in the background. Applications can also be designed
to leverage processing capabilities on multicore systems.
Figure 35 Single-threaded and multithreaded processes.
o An application typically is implemented as a separate process with several

threads of control. Such applications can perform several CPU-intensive
tasks in parallel across the multiple computing cores.
o A single application may be required to perform several similar tasks. For
example, a web server accepts client requests for web pages, images,
sound, and so forth. A busy web server may have several (perhaps
thousands of) clients concurrently accessing it. If the web server ran as a
traditional single-threaded process, it would be able to service only one
client at a time, and a client might have to wait a very long time for its
request to be serviced.
43
o Multiple tasks with the application can be implemented by separate
threads
▪ Update display
▪ Fetch data
▪ Spell checking
▪ Answer a network request
o Figure 36 shows the threads also play a vital role in remote procedure call
(RPC) systems. Recall that RPCs allow interprocess communication by
providing a communication mechanism similar to ordinary function or
procedure calls. Typically, RPC servers are multithreaded. When a server
receives a message, it services the message using a separate thread. This
allows the server to service several concurrent requests.
o If the web-server process is multithreaded, the server will create a separate
thread that listens for client requests. When a request is made, rather than
creating another process, the server creates a new thread to service the
request and resume listening for additional requests.
o Process creation is heavy-weight while thread creation is light-weight
o Can simplify code, increase efficiency
o Finally, most operating-system kernels are now multithreaded. Several
threads operate in the kernel, and each thread performs a specific task,
such as managing devices, managing memory, or interrupt handling. For
example, Solaris has a set of threads in the kernel specifically for interrupt
handling; Linux uses a kernel thread for managing the amount of free
memory in the system.
Figure 36. Multithreaded server architecture
2. Benefit
• Responsiveness – may allow continued execution if part of process is
blocked, especially important for user interfaces
• Resource Sharing – threads share resources of process, easier than shared
memory or message passing
• Economy – cheaper than process creation, thread switching lower
overhead than context switching
• Scalability – process can take advantage of multiprocessor architectures
2. Multicore Programming
1. Program Challenges.
• Multicore or multiprocessor systems putting pressure on programmers,
challenges for multicore systems include:
▪ Identifying tasks/Dividing Activities. This involves examining
applications to find areas that can be divided into separate,
concurrent tasks. Ideally, tasks are independent of one another and
thus can run in parallel on individual cores.
▪ Balance. While identifying tasks that can run in parallel,
programmers must also ensure that the tasks perform equal work
44
of equal value. In some instances, a certain task may not contribute
as much value to the overall process as other tasks. Using a
separate execution core to run that task may not be worth the cost.
▪ Data splitting. Just as applications are divided into separate tasks,
the data accessed and manipulated by the tasks must be divided to
run on separate cores.
▪ Data dependency. The data accessed by the tasks must be
examined for dependencies between two or more tasks. When one
task depends on data from another, programmers must ensure that
the execution of the tasks is synchronized to accommodate the data
dependency.
▪ Testing and debugging. When a program is running in parallel on
multiple cores, many different execution paths are possible. Testing
and debugging such concurrent programs is inherently more
difficult than testing and debugging single-threaded applications.
2. Types of Parallelism
• implies a system can perform more than one task simultaneously
▪ Data parallelism – distributes subsets of the same data across
multiple cores, same operation on each
▪ Task parallelism – distributing threads across cores, each thread
performing unique operation
o Concurrency supports more than one task making progress
▪ Single processor / core, scheduler providing concurrency
o As # of threads grows, so does architectural support for threading

▪ CPUs have cores as well as hardware threads
▪ Consider Oracle SPARC T4 with 8 cores, and 8 hardware threads
per core
Concurrency vs. Parallelism

• A system is parallel if it can perform more than one task simultaneously.
In contrast, a concurrent system supports more than one task by allowing
all the tasks to make progress. Thus, it is possible to have concurrency
without parallelism.
• Concurrent execution on single-core system:
• Parallelism on a multi-core system:
Amdahl’s Law
• Identifies performance gains from adding additional cores to an application
that has both serial and parallel components
45
• S is serial portion
• N processing cores
• That is, if application is 75% parallel / 25% serial, moving from 1 to 2

cores results in speedup of 1.6 times
• As N approaches infinity, speedup approaches 1 / S
Serial portion of an application has disproportionate effect on
performance gained by adding additional cores
• But does the law take into account contemporary multicore systems?
User Threads and Kernel Threads

• User threads - management done by user-level threads library
• Three primary thread libraries:
o POSIX Pthreads
o Windows threads
o Java threads
• Kernel threads - Supported by the Kernel
• Examples – virtually all general purpose operating systems, including:
o Windows , Solaris, Linux, Tru64 UNIX, and Mac OS X
3. Multithreading Models
Support for threads may be provided either at the user level, for user threads, or by the
kernel, for kernel threads. User threads are supported above the kernel and are managed
without kernel support, whereas kernel threads are supported and managed directly by
the operating system. Virtually all contemporary operating systems—including
Windows, Linux, Mac OS X, and Solaris— support kernel threads. Ultimately, a
relationship must exist between user threads and kernel threads. There are three
common ways of establishing such a relationship: the many-to-one model, the one-to-
one model, and the many-to-many model.
1.Many-to-One
• Many user-level threads mapped to single kernel thread
• One thread blocking causes all to block
• Multiple threads may not run in parallel on muticore system because only one
may be in kernel at a time
• Few systems currently use this model
• Examples: Solaris Green Threads, GNU Portable Threads
2. One-to-One
• Each user-level thread maps to kernel thread
• Creating a user-level thread creates a kernel thread
• More concurrency than many-to-one
46
• Number of threads per process sometimes restricted due to overhead
• Examples : Windows, Linux, Solaris 9 and later
3. Many-to-Many Model
• Allows many user level threads to be mapped to many kernel threads

• Allows the operating system to create a sufficient number of kernel threads
• Solaris prior to version 9
• Windows with the ThreadFiber package
• Two-level Model
• Similar to M:M, except that it allows a user thread to be bound to kernel thread
• Examples: IRIX, HP-UX, Tru64 UNIX, Solaris 8 and earlier
4. Thread Libraries
• Thread library provides programmer with API for creating and managing
threads
• Two primary ways of implementing
• Library entirely in user space
• Kernel-level library supported by the OS
A. Pthreads
o May be provided either as user-level or kernel-level
o A POSIX standard (IEEE 1003.1c) API for thread creation and
synchronization
o Specification, not implementation
o API specifies behavior of the thread library, implementation is up
to development of the library
o Common in UNIX operating systems (Solaris, Linux, Mac OS X)
o Pthreads Example
47
Pthreads Code for Joining 10 Threads
B. Windows Multithreaded C Program

o The technique for creating threads using the Windows thread
library is similar to the Pthreads technique in several ways. We
illustrate the Windows thread API in the C program shown below.
Notice that we must include thewindows.h header file when using
the Windows API.
o Just as in the Pthreads version, data shared by the
separate threads—in this case, Sum—are declared globally (the
DWORD data type is an unsigned 32-bit integer). We also define the
Summation() function that is to be performed in a separate thread.
This function is passed a pointer to a void, which Windows defines
as LPVOID. The thread performing this function sets the global data
Sum to the value of the summation from 0 to the parameter passed
to Summation().
48
C. Java Threads
o Java threads are managed by the JVM

o Typically implemented using the threads model provided by
underlying OS
o Java threads may be created by:
o Extending Thread class

o Implementing the Runnable interface
5. Implicit Threading
o Growing in popularity as numbers of threads increase, program correctness more
difficult with explicit threads
o Creation and management of threads done by compilers and run-time libraries
rather than programmers
o Three methods explored
o Thread Pools
o OpenMP
o Grand Central Dispatch
o Other methods include Microsoft Threading Building Blocks (TBB),
java.util.concurrent package
1. Thread Pools
49
o Create a number of threads in a pool where they await work
o Advantages:
o Usually slightly faster to service a request with an existing thread than
create a new thread
o Allows the number of threads in the application(s) to be bound to the
size of the pool
o Separating task to be performed from mechanics of creating task allows
different strategies for running task
▪ i.e.Tasks could be scheduled to run periodically
o Windows API supports thread pools:
2. OpenMP
o Set of compiler directives and an API for C, C++, FORTRAN
o Provides support for parallel programming in shared-memory
environments
o Identifies parallel regions – blocks of code that can run in parallel
#pragma omp parallel
Create as many threads as there are cores
#pragma omp parallel for for(i=0;i<N;i++) {

c[i] = a[i] + b[i];
}
Run for loop in parallel
3.Grand Central Dispatch

o Apple technology for Mac OS X and iOS operating systems
o Extensions to C, C++ languages, API, and run-time library
o Allows identification of parallel sections
o Manages most of the details of threading
o Block is in “^{ }” - ˆ{ printf("I am a block"); }
o Blocks placed in dispatch queue
o Assigned to available thread in thread pool when removed from queue
o Two types of dispatch queues:
o serial – blocks removed in FIFO order, queue is per process, called main queue
o Programmers can create additional serial queues within program
o concurrent – removed in FIFO order but several may be removed at a time
o Three system wide queues with priorities low, default, high
50
6. Threading Issues
1. Semantics of fork() and exec() system calls
o Does fork()duplicate only the calling thread or all threads?
▪ Some UNIXes have two versions of fork
o exec() usually works as normal – replace the running process including all
threads
2. Signal handling
o Signals are used in UNIX systems to notify a process that a particular
event has occurred.
o A signal handler is used to process signals
▪ Signal is generated by particular event
▪ Signal is delivered to a process
▪ Signal is handled by one of two signal handlers:
• default
• user-defined
o Every signal has default handler that kernel runs when handling signal
▪ User-defined signal handler can override default
▪ For single-threaded, signal delivered to process
o Where should a signal be delivered for multi-threaded?
▪ Deliver the signal to the thread to which the signal applies
▪ Deliver the signal to every thread in the process
▪ Deliver the signal to certain threads in the process
▪ Assign a specific thread to receive all signals for the process
3. Thread Cancellation
o Terminating a thread before it has finished
o Thread to be canceled is target thread
o Two general approaches:
▪ Asynchronous cancellation terminates the target thread
immediately
▪ Deferred cancellation allows the target thread to periodically
check if it should be cancelled
o Pthread code to create and cancel a thread:
o Invoking thread cancellation requests cancellation, but actual cancellation

depends on thread state
o If thread has cancellation disabled, cancellation remains pending until thread

enables it
o Default type is deferred
o Cancellation only occurs when thread reaches cancellation point
▪ I.e. pthread_testcancel()
▪ Then cleanup handler is invoked
o On Linux systems, thread cancellation is handled through signals
4. Thread-Local Storage
o Thread-local storage (TLS) allows each thread to have its own copy of data
o Useful when you do not have control over the thread creation process (i.e.,
when using a thread pool)
51
o Different from local variables
o Local variables visible only during single function invocation
o TLS visible across function invocations
o Similar to static data
o TLS is unique to each thread
5. Scheduler Activations
o Both M:M and Two-level models require communication to maintain the
appropriate number of kernel threads allocated to the application
o Typically use an intermediate data structure between user and kernel threads –
lightweight process (LWP)
o Appears to be a virtual processor on which process can schedule user
thread to run
o Each LWP attached to kernel thread
o How many LWPs to create?
o Scheduler activations provide upcalls - a communication mechanism from the

kernel to the upcall handler in the thread library
o This communication allows an application to maintain the correct number kernel
threads
7. Operating System Examples
1. Windows Threads
o Windows implements the Windows API – primary API for Win 98, Win NT, Win
2000, Win XP, and Win 7
o Implements the one-to-one mapping, kernel-level
o Each thread contains
o A thread id
o Register set representing state of processor
o Separate user and kernel stacks for when thread runs in user mode or
kernel mode
o Private data storage area used by run-time libraries and dynamic link
libraries (DLLs)
o The register set, stacks, and private storage area are known as the context of
the thread
o The primary data structures of a thread include:
o ETHREAD (executive thread block) – includes pointer to process to which
thread belongs and to KTHREAD, in kernel space
o KTHREAD (kernel thread block) – scheduling and synchronization info,
kernel-mode stack, pointer to TEB, in kernel space
o TEB (thread environment block) – thread id, user-mode stack, thread-local
storage, in user space
52
2. Linux Threads
o Linux refers to them as tasks rather than threads
o Thread creation is done through clone() system call
o clone() allows a child task to share the address space of the parent task
(process)
o Flags control behavior
o struct task_struct points to process data structures (shared or unique)
Summary
A thread is a flow of control within a process. A multithreaded process contains several

different flows of control within the same address space. The benefits of multithreading
include increased responsiveness to the user, resource sharing within the process,
economy, and scalability factors, such as more efficient use of multiple processing cores.
User-level threads are threads that are visible to the programmer and are
unknown to the kernel. The operating-system kernel supports and manages kernel-level
threads. In general, user-level threads are faster to create and manage than are kernel
threads, because no intervention from the kernel is required.
Three different types of models relate user and kernel threads. The manyto-one
model maps many user threads to a single kernel thread. The one-to-one model maps
each user thread to a corresponding kernel thread. The many-tomany model multiplexes
many user threads to a smaller or equal number of kernel threads.
Most modern operating systems provide kernel support for threads. These include
Windows, Mac OS X, Linux, and Solaris. Thread libraries provide the application
programmer with an API for creating and managing threads. Three primary thread
libraries are in common use: POSIX Pthreads, Windows threads, and Java threads.
In addition to explicitly creating threads using the API provided by a library, we

can use implicit threading, in which the creation and management of threading is
transferred to compilers and run-time libraries. Strategies for implicit threading include
thread pools, OpenMP, and Grand Central Dispatch. Multithreaded programs introduce
many challenges for programmers, including the semantics of the fork() and exec()
53
system calls. Other issues include signal handling, thread cancellation, thread-local
storage, and scheduler activations.
IT’S YOUR TURN
Activity:
Direction: Read the passage carefully and plan what you will write. Place your answer
in the pad paper (yellow or white) to be submitted. Each question has 10 points each.
The Essay rubrics have a correspond points that will guide you in your essay.
“Construct your determination with Sustained Effort, Controlled Attention and Concentrated
Energy, Opportunities never come to those who wait… they are captured by those who dare to
attack” – Paul J. Meyer
Features 9-10 points 7-8 points 4-6 points 1-3 points
Expert Accomplished Capable Beginner
Understanding Writing shows Writing shows a Writing shows Writing shows
strong clear adequate little
understanding understanding understanding understanding
Quality of Piece was Piece was written Piece had little Piece had no style
Writing written in an in an interesting style
extraordinary style
style
Gives no new
Very informative Somewhat Gives some new information and
and well- informative and information but very poorly
organized organized poorly organized organized
Grammar, Virtually no Few spelling and A number of So many spelling,
Usage & spelling, punctuation spelling, punctuation and
Mechanics punctuation or errors, minor punctuation or grammatical
grammatical grammatical grammatical errors that it
errors errors errors interferes with the
meaning
QUESTIONS:
1) Provide two programming examples in which multithreading provides
better performance than a single-threaded solution.
2) What are two differences between user-level threads and kernel-level
threads? Under what circumstances is one type better than the other?
3) Describe the actions taken by a kernel to context-switch between kernel level
threads.
4) What resources are used when a thread is created? How do they differ
from those used when a process is created?
POST ASSESSMENT
Directions: The following questions cover general areas of this module. You may not
know the answers to all questions, but please attempt to answer them without asking
others or referring to books. Place your answer in a separate pad paper for you to be
submitted to the instructor.
Choose the best answer for each question and write the letter of your
choice after the number.
1. Generally manipulate files and directories even create, delete, copy, resume, and
print.
a. File modification
b. Application program
c. Communication
54
d. File management
2. View the date, time, amount of available memory, disk space, and user.
a) Status information
b) File management
c) File modification
d) PL support
3. It provides facilities like disk checking, process scanning, error loading, and
printing.
a) File modification
b) Background services
c) Communication
d) Application program
4. A text editor to create and modify file or perform transformation of the text.
a) A file modification
b) Background services
c) Application program
d) PL support
5. Software that is not typically considered as part of the Operating System and run
by the users.
a) Background services
b) Communication
c) PL support
d) Application program
6. It was written to provide the most functionality in the least space so it was not
carefully divided into modules.
a) MS-DOS
b) UNIX
c) ROM BIOS
d) Application software
7. A system software that has limited hardware functionality and limited
structuring.
a) Window 98
b) Window XP
c) UNIX
d) MS-DOS
8. In the layered operating system under layered approach the bottom layer is
called______.
a) User interface
b) Hardware
c) Application
d) UNIX
9. An operating system used in the Microkernel is.
a) Mac OSX
b) Unix
c) Solaris
d) Microsoft
10. Does the Android operating system that developed by Google is open source?
a) True
b) false
55
REFERENCES
Silberschatz, A. et. al. (2013). Operating System Concepts. 9th Edition. Hoboken, New
Jersey, USA: John Wiley & Sons, Inc.
Stallings, William (2012). Operating System Internals and Design Principles. 7th edition.
Upper Saddle River, New Jersey: Pearson Education, Inc.
56

Platform Technologies Module 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Platform Technologies Module 2

Uploaded by

Copyright:

Available Formats

Republic of the Philippines

Mountain Province State Polytechnic College

OPERATING SYSTEM STRUCTURES

Information Technology Department

1st Semester, SY 2020-2021

At the end of the module, you should be able to:

3. Does the program always ends its execution normally?

4. Communication that via shared memory and message passing.

7. It allows direct command entry.

9. An interface that does not need a mouse and virtual keyboard.

10. It provides an interface to the services made available by an operating system.

LESSON 1: Operating System Structures

If one were to develop an application program as a set of machine instructions

A programmer will make use of these facilities in developing an application, and

An operating system provides an environment for the execution of programs. It

Figure 1. A view of the Operating Services (Operating System. http://www.os-book.com)

• Communications. There are many circumstances in which one process needs to

• Protection and security. The owners of information stored in a multiuser or

One provides a command-line interface, or command interpreter, that allows

A. User Operating System Interface - CLI

Bourne Shell Command Interpreter

Figure 2 The Bourne shell command interpreter in Solrais 10 (Operating System.

B. User Operating System Interface – GUI

Figure 3. The iPad Touchscreen (Operating System. http://www.os-book.com).

• However, with the release of Mac OS X (which is in part implemented using a

System calls provide an interface to the services made available by an operating

4. The program should print a message on the console (another sequence of

Figure 5. Example of how system calls are used (Operating

System Call Implementation

• Typically, a number associated with each system call

Application Programming Interface (API) – System Call – OS Relationship

System Call Parameter Passing

Three general methods used to pass parameters to the OS

Six Types or Category of System Calls

A running program needs to be able to halt its execution either normally

FreeBSD (derived from Berkeley UNIX) is an example of a multitasking system.

Figure 10. FreeBSD running multiple programs (Operating System.

A process may need several resources to execute—main memory, disk

Another set of system calls is helpful in debugging a program. Many

Many operating systems provide a time profile of a program to indicate the

In addition, the operating system keeps information about all its

In the shared-memory model, processes use shared memory create() and

Protection provides a mechanism for controlling access to the resources

Typically, system calls providing protection include set permission() and

System programs provide a convenient environment for program

• Provide a convenient environment for program development and execution

Operating System Design and Implementation

Operating System Structure

Simple Structure -- MS-DOS

Figure 11. MS-DOS layer structure (Operating System. http://www.os-

Figure 12. Traditional UNIX system structure (Operating System. http://www.os-

o UNIX – limited by hardware functionality, the original UNIX operating

Figure 13 A layered operating system (Operating System. http://www.os-book.com).

Microkernel System Structure

Application File Device user

Interprocess memory CPU kernel

Figure 14 Architecture of a typical microkernel (Operating System. http://www.os-

o Moves as much from the kernel into user space

Solaris Modular Approach

Figure 15. Solaris loadable modules (Operating System. http://www.os-

Figure 15 shows the Solaris operating system structure is organized

Example of Hybrid System –