Chapter 1: Introduction OS is a control program

Computer System Structure  Controls execution of programs to prevent errors and

improper use of the computer
Computer system can be divided into four components:
Operating System Definition
Hardware – provides basic computing resources.
No universally accepted definition
 CPU, memory, I/O devices
“The one program running at all times on the computeris the kernel.
Operating system
Everything else is either.
System and application programs
 a system program (ships with the operating system), or
 Word processors, compilers, web browsers, database
 an application program.
systems, video games
Computer System Organization
Users
A modern general-purpose computer system
 People, machines, other computers
 One or more CPUs, device controllers connect through
Four Components of a Computer System
common bus providing access to shared memory.
 Concurrent execution of CPUs and devices competing for
memory cycles

What is an Operating System? Computer Start-up

A program that acts as an intermediary between a user of a computer bootstrap program is loaded at power-up or reboot.
and the computer hardware
 Typically stored in ROM or EEPROM, known as firmware
Operating system goals:  Initializes all aspects of system.
 Loads operating system kernel and starts execution.
 Execute user programs and make solving user problems
easier. Computer-System Operation
 Make the computer system convenient to use.
 I/O devices and the CPU can execute concurrently
 Use the computer hardware in an efficient manner.
 Each device controller oversees a particular device type.
What Operating Systems Do  Each device controller has a local buffer.
 CPU moves data from/to main memory to/from local buffers.
An operating system provides an environment within which other  I/O is from the device to local buffer of controller
programs can do useful work.  Device controller informs CPU that it has finished its operation by
Two viewpoints to understand the role of operating systems: causing an interrupt

 User view Storage Structure

 System view Main memory – only large storage media that the CPU can access
Users want convenience, ease of use and good performance directly

 Don’t care about resource utilization.  Random access

 Typically, volatile
But shared computer such as mainframe or minicomputer must keep
all users happy. Secondary storage – extension of main memory that provides large
non-volatile storage capacity.
Users of dedicate systems such as workstations have dedicated
resources but frequently use shared resources from servers Hard disks – rigid metal or glass platters covered with magnetic
recording material.
From the point of system, OS is the program most intimately involved
with the hardware  Disk surface is logically divided into tracks, which are
subdivided into sectors
OS is a resource allocator.  The disk controller determines the logical interaction between
the device and the computer
 Manages all resources.
 Decides between conflicting requests for efficient and fair Solid-state disks – faster than hard disks, nonvolatile
resource use.
 Various technologies
  Becoming more popular The controller starts data transfer from device to its local buffer.

Storage Hierarchy After the data transfer,

Storage systems organized in hierarchy.  The controller informs the driver via an interrupt.
 The driver returns control to the OS.
 Speed
 Cost Direct Memory Access Structure
 Volatility
Used for high-speed I/O devices able to transmit information at close
Caching – copying information into faster storage system; main to memory speeds
memory can be viewed as a cache for secondary storage
Device controller transfers blocks of data from buffer storage directly
Device Driver for each device controller to manage I/O to main memory without CPU intervention

Provides uniform interface between controller and kernel. Only one interrupt is generated per block, rather than the one
interrupt per byte

How a Modern Computer Works

Storage Definitions and Notation Review

The basic unit of computer storage is the bit. A bit can contain one of A von Neumann architecture
two values, 0 and 1. All other storage in a computer is based on
collections of bits. Given enough bits, it is amazing how many things a Computer-System Architecture
computer can represent: numbers, letters, images, movies, sounds,
Most systems use a single general-purpose processor.
documents, and programs, to name a few. A byte is eight bits, and on
most computers, it is the smallest convenient chunk of storage. For Most systems have special-purpose processors as well.
example, most computers don’t have an instruction to move a bit but
do have one to move a byte. A less common term is word, which is a Multiprocessors systems growing in use and importance.
given computer architecture’s native unit of data. A word is made up Also known as parallel systems, tightly coupled systems.
of one or more bytes. For example, a computer that has 64-bit
registers and 64-bit memory addressing typically has 64-bit (8-byte) Advantages include:
words. A computer executes many operations in its native word size
1. Increased throughput
rather than a byte at a time.
2. Economy of scale
Computer storage, along with most computer throughput, is generally
3. Increased reliability – graceful degradation or fault tolerance
measured and manipulated in bytes and collections of bytes.
Two types:
a kilobyte, or KB, is 1,024 bytes.
1. Asymmetric Multiprocessing – each processor is assigned a
a megabyte, or MB, is 1,0242 bytes.
specific task.
a gigabyte, or GB, is 1,0243 bytes 2. Symmetric Multiprocessing – each processor performs all
tasks.
a terabyte, or TB, is 1,0244 bytes
Symmetric Multiprocessing Architecture
a petabyte, or PB, is 1,0245 bytes.

Computer manufacturers often round off these numbers and say that a
megabyte is 1 million bytes, and a gigabyte is 1 billion bytes.
Networking measurements are an exception to this general rule; they
are given in bits (because networks move data a bit at a time).

I/O Structure

Typically, operating systems have a device driver for each device

controller A Dual-Core Design

To start I/O, the device driver loads registers within the device Multi-chip and multicore
controller. Systems containing all chips.
  Chassis containing multiple separate systems. Increasingly CPUs support multi-mode operations.

i.e., virtual machine manager (VMM) mode for guest VMs

Transition from User to Kernel Mode

Operating System Structure

Multiprogramming (Batch system) needed for efficiency Process Management

 Single user cannot keep CPU and I/O devices always busy A process is a program in execution. It is a unit of work within the
 Multiprogramming organizes jobs (code and data), so CPU system. Program is a passive entity; process is an active entity.
always has one to execute
 A subset of total jobs in system is kept in memory. Process needs resources to accomplish its task.
 One job selected and run via job scheduling.
 CPU, memory, I/O, files
 When it has to wait (for I/O for example), OS switches to
 Initialization data
another job
Process termination requires reclaim of any reusable resources.
Timesharing (multitasking) is logical extension in which CPU switches
jobs so frequently that users can interact with each job while it is Single-threaded process has one program counter specifying location
running, creating interactive computing of next instruction to execute.
 Response time should be < 1 second.  Process executes instructions sequentially, one at a time, until
 Each user has at least one program executing in memory completion
[process.
 If several jobs ready to run at the same time [ CPU scheduling Multi-threaded process has one program counter per thread.
 If pro1cesses don’t fit in memory, swapping moves them in Typically, system has many processes, some user, some operating
and out to run system running concurrently on one or more CPUs.
 Virtual memory allows execution of processes not completely
in memory  Concurrency by multiplexing the CPUs among the processes /
threads.
Memory Layout for Multiprogrammed System
Process Management Activities

The operating system is responsible for the following activities in

connection with process management:

 Creating and deleting both user and system processes

 Suspending and resuming processes
 Providing mechanisms for process synchronization
 Providing mechanisms for process communication
Operating-System Operations
 Providing mechanisms for deadlock handling
Interrupt driven (hardware and software)
Memory Management
Hardware interrupt by one of the devices
To execute a program all (or part) of the instructions must be in
Software interrupt (exception or trap): memory.

 Software error (e.g., division by zero) All (or part) of the data that is needed by the program must be in
 Request for operating system service memory.
 Other process problems include infinite loop, processes
Memory management determines what is in memory and when
modifying each other or the operating system.
 Optimizing CPU utilization and computer response to users
Dual-mode operation to distinguish between operating-system code
and user-defined code. Memory management activities
 User mode and kernel mode  Keeping track of which parts of memory are currently being
 Mode bit provided by hardware. used and by whom.
 Provides ability to distinguish when system is running user  Deciding which processes (or parts of processes) and data to
code or kernel code. move into and out of memory.
 Some instructions designated as privileged, only executable in  Allocating and deallocating memory space as needed.
kernel mode.
 System call changes mode to kernel, return from call resets it Storage Management
to user. OS provides uniform, logical view of information storage
Abstracts physical properties to logical storage unit - file. Multiprocessor environment must provide cache coherency in
hardware such that all CPUs have the most recent value in their cache.
File-System management
Protection and Security
Files usually organized into directories.
Protection – any mechanism for controlling access of processes or
Access control on most systems to determine who can access what.
users to resources defined by the OS
OS activities include.
Security – defence of the system against internal and external attacks
 Creating and deleting files and directories
 Huge range, including denial-of-service, worms, viruses,
 Primitives to manipulate files and directories.
identity theft, theft of service
 Mapping files onto secondary storage
 Backup files onto stable (non-volatile) storage media Systems generally first distinguish among users, to determine who can
do what.
Mass-Storage Management
 User identities (user IDs, security IDs) include name and
Usually, disks used to store data that does not fit in main memory or
associated number, one per user
data that must be kept for a “longperiod.
 User ID then associated with all files, processes of that user to
Proper management is of central importance. determine access control
 Group identifier (group ID) allows set of users to be defined
Entire speed of computer operation hinges on disk subsystem and its and controls managed, then also associated with each
algorithms process, file.
 Privilege escalation allows user to change to effective ID with
OS activities
more rights.
 Free-space management
Chapter 2: Operating-System Structures
 Storage allocation
 Disk scheduling Operating System Services
Some storage need not be fast. Operating systems provide an environment for execution of programs
and services to programs and users.
 Tertiary storage includes optical storage, magnetic tape.
 Varies between WORM (write-once, read-many-times) and One set of operating-system services provides functions that are
RW (read-write) helpful to the user:
Caching User interface – Almost all operating systems have a user interface
(UI).
Important principle, performed at many levels in a computer (in
hardware, operating system, software)  Varies between Command-Line (CLI), Graphics User Interface
(GUI), Batch
Information in use copied from slower to faster storage temporarily
Program execution - The system must be able to load a program into
Faster storage (cache) checked first to determine if information is
memory and to run that program, end execution, either normally or
there
abnormally (indicating error)
 If it is, information used directly from the cache (fast)
I/O operations - A running program may require I/O, which may
 If not, data copied to cache and used there.
involve a file or an I/O device
Cache smaller than storage being cached.
File-system manipulation - The file system is of particular interest.
 Cache management important design problem Programs need to read and write files and directories, create, and
 Cache size and replacement policy delete them, search them, list file Information, permission
management.
Performance of Various Levels of Storage
Communications – Processes may exchange information, on the same
computer or between computers over a network.

 Communications may be via shared memory or through

message passing (packets moved by the OS)

Error detection – OS needs to be constantly aware of possible errors

 May occur in the CPU and memory hardware, in I/O devices,

in user program
Migration of data “Afrom Disk to Register  For each type of error, OS should take the appropriate action
to ensure correct and consistent computing
Multitasking environments must be careful to use most recent value,  Debugging facilities can greatly enhance the user’s and
no matter where it is stored in the storage hierarchy. programmer’s abilities to efficiently use the system

Another set of OS functions exists for ensuring the efficient operation

of the system itself via resource sharing
Resource allocation - When multiple users or multiple jobs running  Various mouse buttons over objects in the interface cause
concurrently, resources must be allocated to each of them various actions (provide information, options, execute
function, open directory (known as a folder)
 Many types of resources - CPU cycles, main memory, file
 Invented at Xerox PARC
storage, I/O devices.
Many systems now include both CLI and GUI interfaces
Accounting - To keep track of which users use how much and what
kinds of computer resources  Microsoft Windows is GUI with CLI “commandshell.
 Apple Mac OS X is “AquaGUI interface with UNIX kernel
Protection and security - The owners of information stored in a
underneath and shells available
multiuser or networked computer system may want to control use of
 Unix and Linux have CLI with optional GUI interfaces (CDE,
that information, concurrent processes should not interfere with each
KDE, GNOME)
other
Touchscreen Interfaces
 Protection involves ensuring that all access to system
resources is controlled Touchscreen devices require new
 Security of the system from outsiders requires user interfaces.
authentication, extends to defending external I/O devices
Mouse not possible or not desired
from invalid access attempts
Actions and selection based on gestures.
A View of Operating System Services
Virtual keyboard for text entry

 Voice commands.

The Mac OS X GUI

User Operating System Interface - CLI

CLI or command interpreter allows direct command entry.

Sometimes implemented in kernel, sometimes by systems program.

Sometimes multiple flavours implemented – shells.

System Calls
Primarily fetches a command from user and executes it
Programming interface to the services provided by the OS
Sometimes commands built-in, sometimes just names of programs.
Typically written in a high-level language (C or C++)
 If the latter, adding new features doesn’t require shell
modification. Mostly accessed by programs via a high-level Application Programming
Interface (API) rather than direct system call use
Bourne Shell Command Interpreter
Three most common APIs are Win32 API for Windows, POSIX API for
POSIX-based systems (including virtually all versions of UNIX, Linux,
and Mac OS X), and Java API for the Java virtual machine (JVM)

Note that the system-call names used throughout this text are generic

Example of System Calls

System call sequence to copy the contents of one file to another file

User Operating System Interface - GUI

User-friendly desktop metaphor interface

 Usually mouse, keyboard, and monitor Example of Standard API

 Icons represent files, programs, actions, etc.
 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.

Parameter Passing via Table

Types of System Calls

Process control

System Call Implementation  Create process, terminate process

 End, abort
Typically, a number associated with each system call.
 Load, execute.
System-call interface maintains a table indexed according to these  get process attributes, set process attributes
numbers.  Wait for time.
 Wait event, signal event
The system call interface invokes the intended system call in OS kernel  Allocate and free memory.
and returns status of the system call and any return values  Dump memory if error
 Debugger for determining bugs, single step execution
The caller need know nothing about how the system call is
 Locks for managing access to shared data between processes
implemented
File management
Just needs to obey API and understand what OS will do as a result call.
 Create file, delete file
Most details of OS interface hidden from programmer by API
 Open, close file
 Managed by run-time support library (set of functions built  Read, write, reposition.
into libraries included with compiler)  get and set file attributes

API – System Call – OS Relationship Device management

 Request device, release device

 read, write, reposition
 Get device attributes, set device attributes
 Logically attach or detach devices.

Information maintenance

 Get time or date, set time or date

 Get system data, set system data
 Get and set process, file, or device attributes
System Call Parameter Passing Communications
Often, more information is required than simply identity of desired  Create, delete communication connection.
system call.  send, receive messages if message passing model to host
name or process name 4 From client to server
Exact type and amount of information vary according to OS and call.
 Shared-memory model create and gain access to memory
Three general methods used to pass parameters to the OS. regions.
 Transfer status information.
Simplest: pass the parameters in registers.  Attach and detach remote devices.
 In some cases, may be more parameters than registers Protection
Parameters stored in a block, or table, in memory, and address of  Control access to resources
block passed as a parameter in a register  Get and set permissions
 This approach taken by Linux and Solaris  Allow and deny user access.

Examples of Windows and Unix System Calls

  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

 Launch at boot time

o Some for system startup, then terminate
o Some from system boot to shutdown
 Provide facilities like disk checking, process scheduling, error
logging, printing
 Run in user context not kernel context
 Known as services, subsystems, daemons

Application programs
Standard C Library Example
 Don’t pertain to system
C program invoking printf() library call, which calls write() system call
 Run by users
 Not typically considered part of OS
 Launched by command line, mouse click, finger poke

Operating System Design and Implementation

 Design and Implementation of OS not “solvable”, but some

approaches have proven successful
 Internal structure of different Operating Systems can vary widely
 Start the design by defining goals and specifications
 Affected by choice of hardware, type of system
 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
System Programs design,
o implement, and maintain, as well as flexible, reliable,
Provide a convenient environment for program development and
error-free, and efficient
execution
 Important principle to separate
 Some of them are simply user interfaces to system calls;  Policy: What will be done?
others are considerably more complex  Mechanism: How to do it?
 Mechanisms determine how to do something; policies decide
File management - Create, delete, copy, rename, print, dump, list, and what will be done
generally manipulate files and directories  The separation of policy from mechanism is a very important
Status information principle, it allows maximum flexibility if policy decisions are to be
changed later (example – timer)
 Some ask the system for info - date, time, amount of available  Specifying and designing an OS is highly creative task of software
memory, disk space, number of users engineering
 Others provide detailed performance, logging, and debugging
information Implementation
 Typically, these programs format and print the output to the  Much variation
terminal or other output devices o Early OSes in assembly language
 Some systems implement a registry - used to store and o Then system programming languages like Algol, PL/1
retrieve configuration information o Now C, C++
File modification  Usually, a mix of languages
o Lowest levels in assembly
 Text editors to create and modify files o Main body in C
 Special commands to search contents of files or perform o Systems programs in C, C++, scripting languages like PERL,
transformations of the text o Python, shell scripts
Programming-language support - Compilers, assemblers, debuggers  More high-level language easier to port to other hardware
and interpreters sometimes provided o But slower

Program loading and execution- Absolute loaders, relocatable loaders, Operating System Structure
linkage editors, and overlay-loaders, debugging systems for higher-
 General-purpose OS is very large program
level and machine language
 Various ways to structure ones
Communications - Provide the mechanism for creating virtual o Simple structure – MS-DOS
connections among processes, users, and computer systems o More complex – UNIX
 o Layered – an abstraction Benefits:
o Microkernel – Mach
 Easier to extend a microkernel
o Modules – Solaris
 Easier to port the operating system to new architectures
o Hybrid – Mac OS X
 More reliable (less code is running in kernel mode)
Simple Structure -- MS-DOS  More secure

 MS-DOS – written to Detriments:

provide the most functionality in the
 Performance overhead of user space to kernel space
least space
communication
o Not divided into
modules
o Although MS-DOS has
some structure, its
interfaces and levels of
functionality are not well separated

Non Simple Structure -- UNIX

UNIX – limited by hardware functionality, the original UNIX operating

system had limited structuring. The UNIX OS consists of two separable
Modules
parts
Many modern operating systems implement loadable kernel modules
 Systems programs
 The kernel  Uses object-oriented approach
o Consists of everything below the system-call interface  Each core component is separate
and above the physical hardware  Each talks to the others over known interfaces
o Provides the file system, CPU scheduling, memory  Each is loadable as needed within the kernel
management, and other operating-system functions; a
large number of functions for one level Overall, like layers but with more flexibility

Traditional UNIX System Structure  Linux, Solaris, etc

Beyond simple but not fully layered Solaris Modular Approach

Hybrid Systems

Most modern operating systems are actually not one pure model
Layered Approach  Hybrid combines multiple approaches to address
performance, security, usability needs
 The operating system is divided into
 Linux and Solaris kernels in kernel address space, so
several layers (levels), each built on
monolithic, plus modular for dynamic loading of functionality
top of lower layers. The bottom layer
 Windows mostly monolithic, plus microkernel for different
(layer 0), is the hardware; the
subsystem personalities
highest (layer N) is the user
interface. Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming
 With modularity, layers are selected environment
such that each uses functions (operations) and services of only
lower-level layers  Below is kernel consisting of Mach microkernel and BSD Unix
parts, plus I/O kit and dynamically loadable modules (called
Microkernel System Structure kernel extensions)
Moves as much from the kernel into user space Mac OS X Structure
Mach example of microkernel

 Mac OS X kernel (Darwin) partly based on Mach

Communication takes place between user modules using

message passing
  ready: The process is waiting to be assigned to a processor
 terminated: The process has finished execution

Diagram of Process State

System Boot

When power initialized on system, execution starts at a fixed memory Process Control Block (PCB)
location
Information associated with each process (also called task control
 Firmware ROM used to hold initial boot code block)

Operating system must be made available to hardware so hardware  Process state – running, waiting,
can start it etc
 Program counter – location of
 Small piece of code – bootstrap loader, stored in ROM or instruction to next execute
EEPROM locates the kernel, loads it into memory, and starts it  CPU registers – contents of all
 Sometimes two-step process where boot block at fixed process centric registers
location loaded by ROM code, which loads bootstrap loader  CPU scheduling information -
from disk priorities, scheduling queue
Common bootstrap loader, GRUB, allows selection of kernel from pointers
multiple disks, versions, kernel options  Memory-management
information – memory allocated to the process
Kernel loads and system is then running  Accounting information – CPU used, clock time elapsed since
start, time limits
Chapter 3: Processes
 I/O status information – I/O devices allocated to process, list
Process Concept of open files

Process – a program in execution; process execution must progress in CPU Switch From Process to Process
sequential fashion

Multiple parts

 The program code, also called text section

 Current activity including program counter, processor
registers
 Stack containing temporary data
o Function parameters, return addresses, local
variables
 Data section containing global variables
 Heap containing memory dynamically allocated during run
time
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

 Job queue – set of all processes in the system

 Ready queue – set of all processes residing in main memory,
ready and waiting to execute
 Device queues – set of processes waiting for an I/O device
Process in Memory
 Processes migrate among the various queues
Process State
Ready Queue And Various I/O Device Queues
As a process executes, it changes state

 new: The process is being created

 running: Instructions are being executed
 waiting: The process is waiting for some event to occur
  Some hardware provides multiple sets of registers per CPU ➔
multiple contexts loaded at once

Process Creation

Parent process create children processes, which, in turn create other

processes, forming a tree of processes

Generally, process identified and managed via a process identifier (pid)

Resource sharing options

 Parent and children share all resources

 Children share subset of parent’s resources
 Parent and child share no resources
Representation of Process Scheduling Execution options
Queueing diagram represents queues, resources, flows  Parent and children execute concurrently
 Parent waits until children terminate

Schedulers

Short-term scheduler (or CPU scheduler) – selects which process A Tree of Processes in Linux
should be executed next and allocates CPU
Address space
 Sometimes the only scheduler in a system
 Short-term scheduler is invoked frequently (milliseconds)   Child duplicate of parent
(must be fast)  Child has a program loaded into it

Long-term scheduler (or job scheduler) – selects which processes UNIX examples
should be brought into the ready queue  fork() system call creates new process
 Long-term scheduler is invoked infrequently (seconds,  exec() system call used after a fork() to replace the process’
minutes)  (may be slow) memory space with a new program
 The long-term scheduler controls the degree of
multiprogramming

Processes can be described as either:

 I/O-bound process – spends more time doing I/O than

computations, many short CPU bursts C Program Forking Separate Process
 CPU-bound process – spends more time doing computations;
few very long CPU bursts

Long-term scheduler strives for good process mix

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 Process Termination

 The more complex the OS and the PCB ➔ the longer the Process executes last statement and then asks the operating system to
context switch delete it using the exit() system call.

Time dependent on hardware support  Returns status data from child to parent (via wait())
 Process’ resources are deallocated by operating system
Parent may terminate the execution of children processes using the Shared data
abort() system call. Some reasons for doing so:
#define BUFFER_SIZE 10
 Child has exceeded allocated resources
typedef struct {
 Task assigned to child is no longer required
 The parent is exiting, and the operating systems does not ...
allow a child to continue if its parent terminates (cascading
} item;
termination)

Interprocess Communication
item buffer[BUFFER_SIZE];
Processes within a system may be independent or cooperating
int in = 0;
Cooperating process can affect or be affected by other processes,
int out = 0;
including sharing data
Solution is correct, but can only use BUFFER_SIZE-1 elements
Reasons for cooperating processes:
Bounded-Buffer – Producer
 Information sharing
 Computation speedup item next_produced;
 Modularity
while (true) {
 Convenience
/* produce an item in next produced */
Cooperating processes need interprocess communication (IPC)
while (((in + 1) % BUFFER_SIZE) == out)
Two models of IPC
; /* do nothing */
 Shared memory
 Message passing buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;
Communications Models
}

Bounded Buffer – Consumer

item next_consumed;

while (true) {

while (in == out)

; /* do nothing */

next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

Shared Memory Systems
/* consume the item in next consumed */
IPC using shared memory requires communicating processes to
establish a region of shared memory. }

Normally, the operating system prevents one process accessing other Message Passing Systems
process’s memory
Mechanism for processes to communicate and to synchronize their
 Requires that two or more processes agree to remove this actions
restriction
Message system – processes communicate with each other without
 Communication is under the control of the processes, not the
resorting to shared variables
operating system
IPC facility provides two operations:
Major issues is to provide mechanism that will allow the user
processes to synchronize their actions when they access shared  send(message)
memory.  receive(message)
Producer-Consumer Problem The message size is either fixed or variable
Paradigm for cooperating processes, producer process produces If processes P and Q wish to communicate, they need to:
information that is consumed by a consumer process
 Establish a communication link between them
 unbounded-buffer places no practical limit on the size of the  Exchange messages via send/receive
buffer
 bounded-buffer assumes that there is a fixed buffer size Implementation issues:

Bounded-Buffer – Shared-Memory Solution  How are links established?

 Can a link be associated with more than two processes?
  How many links can there be between every pair of  Non-blocking send -- the sender sends the message and
communicating processes? continue
 What is the capacity of a link?  Non-blocking receive -- the receiver receives:
 Is the size of a message that the link can accommodate fixed o A valid message, or
or variable? o Null message
 Is a link unidirectional or bi-directional?
Different combinations possible
Implementation of communication link
 If both send and receive are blocking, we have a rendezvous
 Physical:
o Shared memory Buffering
o Hardware bus Queue of messages attached to the link.
o Network
 Logical: Implemented in one of three ways
o Direct or indirect
1. Zero capacity – no messages are queued on a link. Sender
o Synchronous or asynchronous must wait for receiver (rendezvous)
o Automatic or explicit buffering 2. Bounded capacity – finite length of n messages. Sender must
Direct Communication wait if link full
3. Unbounded capacity – infinite length. Sender never waits
Processes must name each other explicitly:  Communications in Client-Server Systems

 send (P, message) – send a message to process P Shared memory and message passing can also be used in client-server
 receive(Q, message) – receive a message from process Q systems.

Properties of communication link In addition, client-server systems use three other strategies:

 Links are established automatically  Sockets

 A link is associated with exactly one pair of communicating  Remote Procedure Calls
processes  Pipes
 Between each pair there exists exactly one link
 The link may be unidirectional, but is usually bi-directional Sockets

Indirect Communication  A socket is defined as an endpoint for communication

 Concatenation of IP address and port – a number included at start
Messages are directed and received from mailboxes (also referred to of message packet to differentiate network services on a host
as ports)  The socket 161.25.19.8:1625 refers to port 1625 on host
161.25.19.8
 Each mailbox has a unique id
 Communication consists between a pair of sockets
 Processes can communicate only if they share a mailbox
 All ports below 1024 are well known, used for standard services
Properties of communication link  Special IP address 127.0.0.1 (loopback) to refer to system on
which process is running
 Link established only if processes share a common mailbox
 A link may be associated with many processes Socket Communication
 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:

Sockets in Java
 send(A, message) – send a message to mailbox A
Three types of sockets
 receive(A, message) – receive a message from mailbox A
 Connection-oriented (TCP)
Synchronization
 Connectionless (UDP)
Message passing may be either blocking or non-blocking  MulticastSocket class– data can be sent to multiple recipients

Blocking is considered synchronous Consider this “Dateserver:

 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

  Kernels are generally multithreaded

Multithreaded Server Architecture

Benefits

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

Multicore Programming

Parallelism implies a system can perform more than one task

simultaneously

Chapter 4: Threads

All modern operating systems provide features enabling a process to

contain multiple threads of control. Concurrency supports more than one task making progress
A thread is a basic unit of CPU utilization

 Comprises: thread id, program counter, register set, stack

 Shares: code section, data section, operating system
resources (such as files) Multicore or multiprocessor systems putting pressure on
programmers, challenges include:
Single and Multithreaded Processes
 Dividing activities
 Balance
 Data splitting
 Data dependency
 Testing and debugging

Types of parallelism

 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
Motivation
Amdahl’s Law
 Most modern applications are multithreaded
 Threads run within application  Identifies performance gains from adding additional cores to an
 Multiple tasks with the application can be implemented by application that has both serial and parallel components
separate threads  S is serial portion
o Update display  N processing cores
o Fetch data
o Spell checking
o Answer a network request
 Process creation is heavy-weight while thread creation is
light-weight  That is, if application is 75% parallel / 25% serial, moving from 1 to
 Can simplify code, increase efficiency 2 cores results in speedup of 1.6 times
 As N approaches infinity, speedup approaches 1 / S  Similar to M:M, except that it allows a user thread to be bound to
kernel thread
Serial portion of an application has disproportionate effect on
 Examples:
performance gained by adding additional cores
o IRIX
User Threads and Kernel Threads o HP-UX
o Tru64 UNIX
User threads - management done by user-level threads library o Solaris 8 and earlier
Three primary thread libraries: Thread Libraries
 POSIX Pthreads  Thread library provides programmer with API for creating and
 Windows threads managing threads
 Java threads  Two primary ways of implementing
Kernel threads - Supported by the Kernel o Library entirely in user space
o Kernel-level library supported by the OS
Examples – virtually all general purpose operating systems, including:  Three main libraries are in use today:
o POSIX Pthreads
 Windows
 Solaris o Windows
 Linux o Java
 Tru64 UNIX Pthreads
 Mac OS X
 May be provided either as user-level or kernel-level
Multithreading Models  A POSIX standard (IEEE 1003.1c) API for thread creation and
 Many-to-One synchronization
 One-to-One  Specification, not implementation
 Many-to-Many  API specifies behavior of the thread library, implementation is up
to development of the library
Many-to-One  Common in UNIX operating systems (Solaris, Linux, Mac OS X
 Example:
 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:
o Solaris Green Threads
o GNU Portable Threads

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 Windows Threads
 Number of threads per process sometimes restricted due to  Kernel-level library available on Windows systems
overhead  Similar to the Pthreads in many ways
 Examples: o windows.h header file must be included
o Windows  Windows Multithread C Program:
o Linux
o Solaris 9 and later

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

Java Threads
 Java threads are managed by the JVM Growing in popularity as numbers of threads increase, program
 Typically implemented using the threads model provided by correctness more difficult with explicit threads
underlying OS
Creation and management of threads done by compilers and run-time
 Java threads may be created by:
libraries rather than programmers

Several methods for implicit threading:

 Thread Pools
o Extending Thread class  OpenMP
o Implementing the Runnable interface  Grand Central Dispatch
 Microsoft Threading Building Blocks
Java Multithreaded Program #1
Thread Pools

Create several threads in a pool where they await work

Advantages:

 Usually slightly faster to service a request with an existing

thread than create a new thread
 Allows the number of threads in the application(s) to be
bound to the size of the pool
 Separating task to be performed from mechanics of creating
task allows different strategies for running task
o Tasks could be scheduled to run periodically

Threading Issues

 Semantics of fork() and exec() system calls

 Signal handling
o Synchronous and asynchronous
 Thread cancellation of target thread
o Asynchronous or deferred
 Thread-local storage
 Scheduler Activations

Semantics of fork() and exec()

 Does fork()duplicate only the calling thread or all threads?

o Some UNIXes have two versions of fork
 exec() usually works as normal – replace the running process
including all threads
Java Multithreaded Program #2
Signal Handling

 Signals are used in UNIX systems to notify a process that a

particular event has occurred.
 A signal handler is used to process signals
1. Signal is generated by particular event
2. Signal is delivered to a process
3. Signal is handled by one of two signal handlers:
1. default
2. user-defined
 Every signal has default handler that kernel runs when
 handling signal
o User-defined signal handler can override default
o For single-threaded, signal delivered to process
 Where should a signal be delivered for multi-threaded?
o Deliver the signal to the thread to which the signal
applies
o Deliver the signal to every thread in the process
o Deliver the signal to certain threads in the process
o Assign a specific thread to receive all signals for the
process

Implicit Threading Thread Cancellation

 Terminating a thread before it has finished o counter = register1
 Thread to be canceled is target thread  counter-- could be implemented as
 Two general approaches: o register2 = counter
o Asynchronous cancellation terminates the target thread o register2 = register2 - 1
immediately o counter = register2
o Deferred cancellation allows the target thread to  Consider this execution interleaving with “count = 5” initially:
periodically check if it should be cancelled o S0: producer execute register1 = counter {register1 = 5}
 Pthread code to create and cancel a thread: o S1: producer execute register1 = register1 + 1 {register1 =
6}
o S2: consumer execute register2 = counter {register2 = 5}
o S3: consumer execute register2 = register2 – 1 {register2
= 4}
o S4: producer execute counter = register1 {counter = 6 }
o S5: consumer execute counter = register2 {counter = 4}

 Invoking thread cancellation requests cancellation, but actual Critical Section Problem
cancellation depends on thread state
 Consider system of n processes {p0, p1, … pn-1}
 Each process has critical section segment of code
o Process may be changing common variables, updating
table, writing file, etc
o When one process is in critical section, no other may be
 If thread has cancellation disabled, cancellation remains pending
in its critical section
until thread enables it
 Critical section problem is to design protocol to solve this
 Default type is deferred
 Each process must ask permission to enter critical section in entry
o Cancellation only occurs when thread reaches
section, may follow critical section with exit section, then
cancellation point
remainder section
 I.e. pthread_testcancel()
 Then cleanup handler is invoked Critical Section
 On Linux systems, thread cancellation is handled through signals
 General structure of process Pi
Chapter 5: Process Synchronization
Background

 Processes can execute concurrently

o May be interrupted at any time, partially completing
execution
 Concurrent access to shared data may result in data inconsistency
 Maintaining data consistency requires mechanisms to ensure the
orderly execution of cooperating processes Solution to Critical Section Problem
 Initial approach to the Producer-Consumer Problem
Three requirements of critical section problem:

1. Mutual Exclusion: If process Pi is executing in its critical section,

then no other processes can be executing in their critical sections
2. Progress: If no process is executing in its critical section and there
exist some processes that wish to enter their critical sections, then
the selection of the processes that will enter the critical section
 Deficiency → Cannot utilize the whole buffer
next cannot be postponed indefinitely
o Allows at max BUFFER_SIZE - 1 items in the buffer at the
3. Bounded Waiting: There exists a limit on the number of times that
same time
other processes are allowed to enter their critical sections after a
 An algorithmic improvement to remedy the deficiency
process has made a request to enter its critical section and before
o Using a counter that keeps track of the number of full
that request is granted
buffers
Critical Section & Mutual Exclusion

Race Condition

 counter++ could be implemented as

o register1 = counter Peterson’s Solution
o register1 = register1 + 1
 Good algorithmic description of solving the problem Definition:
 Two process solution
boolean test_and_set (boolean *target)
 Assume that the load and store machine-language instructions are
atomic; that is, cannot be interrupted {
 The two processes share two variables:
boolean rv = *target;
o int turn;
o Boolean flag[2] *target = TRUE;
 The variable turn indicates whose turn it is to enter the critical
return rv:
section
 The flag array is used to indicate if a process is ready to enter the }
critical section. flag[i] = true implies that process Pi is ready!
1. Executed atomically
Algorithm for Process Pi 2. Returns the original value of passed parameter
3. Set the new value of passed parameter to “TRUE”.
do {
Solution using test_and_set()
flag[i] = true;
 Shared Boolean variable lock, initialized to FALSE
turn = j;
 Solution:
while (flag[j] && turn = = j);
do {
critical section
while (test_and_set(&lock))
flag[i] = false;
; /* do nothing */
remainder section
/* critical section */
} while (true);
lock = false;
 Is the algorithm robust enough to satisfy three requirements of
/* remainder section */
critical section problem?
 Provable that the three CS requirement are met: } while (true);
1. Mutual exclusion is preserved
compare_and_swap Instruction
o Pi enters CS only if:
o either flag[j] = false or turn = i Definition:
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met int compare_and_swap(int *value, int expected, int new_value)
{
Synchronization Hardware
int temp = *value;
 Many systems provide hardware support for implementing the if (*value == expected)
critical section code.
 All solutions below based on idea of locking *value = new_value;
o Protecting critical regions via locks return temp;
 Uniprocessors – could disable interrupts
o Currently running code would execute without }
preemption 1. Executed atomically
o Generally too inefficient on multiprocessor systems 2. Returns the original value of passed parameter “value”
 Operating systems using this not broadly 3. Set the variable “value” the value of the passed parameter
scalable “new_value” but only if “value” == “expected”. That is, the swap
 Modern machines provide special atomic hardware instructions takes place only under this condition.
 Atomic = non-interruptible
o Either test memory word and set value Solution using compare_and_swap
o Or swap contents of two memory words
 Shared integer “lock” initialized to 0;
Solution to Critical Section Problem Using Locks  Solution:

do { do {

acquire lock while (compare_and_swap(&lock, 0, 1) != 0)

critical section ; /* do nothing */

release lock /* critical section */

remainder section lock = 0;

} while (TRUE); /* remainder section */

} while (true);
test_and_set Instruction
Mutex Locks  Counting semaphore – integer value can range over an
unrestricted domain
 Previous solutions are complicated and generally inaccessible to
 Binary semaphore – integer value can range only between 0 and 1
application programmers
o Same as a mutex lock
 OS designers build software tools to solve critical section problem
 Can solve various synchronization problems
 Simplest is mutex lock
 Consider P1 and P2 that require S1 to happen before S2
 Protect a critical section by first acquire() a lock then release() the
lock Create a semaphore “synch” initialized to 0
o Boolean variable indicating if lock is available or not
P1:
 Calls to acquire() and release() must be atomic
o Usually implemented via hardware atomic instructions S1;
 But this solution requires busy waiting
signal(synch);
o This lock therefore called a spinlock
P2:
acquire() and release()
wait(synch);
acquire() {
S2;
while (!available)
Semaphore Implementation with no Busy waiting
; /* busy wait */
Overcoming the busy waiting
available = false;

}  When a process executes wait() and finds that the semaphore is

not positive, it blocks itself (rather than busy waiting)
release() { o Process is moved to a waiting queue
available = true;  When another process executes signal(), a process in waiting
queue might be restarted (by CPU scheduler)
}  Two operations:
do { o block – place the process invoking the operation on the
appropriate waiting queue
acquire lock
o wakeup – remove one of processes in the waiting queue
critical section and place it in the ready queue
release lock typedef struct {
remainder section int value;
} while (true); struct process *list;

Semaphore } semaphore;

 Synchronization tool that provides more sophisticated ways (than wait(semaphore *S) {
Mutex locks) for process to S->value--;
synchronize their activities.
 Semaphore S – integer if (S->value < 0) {
variable add this process to S->list;
 Can only be accessed via two
block();
indivisible (atomic) operations
o wait() and signal() }
 Definition of the wait()
}
wait(S) {
signal(semaphore *S) {
while (S <= 0)
S->value++;
; // busy wait
if (S->value <= 0) {
S--;
remove a process P from S->list;
}
wakeup(P);
 Definition of the signal() }

signal(S) { }

S++;

Semaphore Usage Deadlock and Starvation

Deadlock – two or more processes are waiting indefinitely for an event ...
that can be caused by only one of the waiting processes
signal(mutex);
Let S and Q be two semaphores initialized to 1 signal(empty);
P0 P1 ...
wait(S); wait(Q); /* consume the item in next consumed */
wait(Q); wait(S); ...
... ... } while (true);
signal(S); signal(Q);
Readers-Writers Problem
signal(Q); signal(S);
A data set is shared among a number of concurrent processes
Starvation – indefinite blocking
 Readers – only read the data set; they do not perform any
 A process may never be removed from the semaphore queue updates
in which it is suspended  Writers – can both read and write

Priority Inversion – Scheduling problem when lower-priority process Problem – allow multiple readers to read at the same time
holds a lock needed by higher-priority process
 Only one single writer can access the shared data at the same
 Solved via priority-inheritance protocol time

Classical Problems of Synchronization Several variations of how readers and writers are considered – all
involve some form of priorities
Classical problems used to test newly-proposed synchronization
schemes Shared Data

 Bounded-Buffer Problem  Data set

 Readers and Writers Problem  Semaphore rw_mutex initialized to 1
 Dining-Philosophers Problem  Semaphore mutex initialized to 1
 Integer read_count initialized to 0
Bounded-Buffer Problem
The structure of a writer process:
 n buffers, each can hold one item
 Semaphore mutex initialized to the value 1 do {
 Semaphore full initialized to the value 0
wait(rw_mutex);
 Semaphore empty initialized to the value n
 The structure of the producer process ...

do { /* writing is performed */

... ...

/* produce an item in next_produced */ signal(rw_mutex);

... } while (true);

wait(empty); The structure of a reader process:

wait(mutex); do {
... wait(mutex);
/* add next produced to the buffer */ read_count++;
... if (read_count == 1)
signal(mutex); wait(rw_mutex);
signal(full); signal(mutex);
} while (true); ...

 The structure of the consumer process /* reading is performed */

do { ...

wait(full); wait(mutex);

wait(mutex); read count--;

... if (read_count == 0)

/* remove an item from buffer to next_consumed */ signal(rw_mutex);

 signal(mutex); Abstract data type, internal variables only accessible by code within
the procedure
} while (true);
Only one process may be active within the monitor at a time
Readers-Writers Problem Variations
But not powerful enough to model some synchronization schemes
 First variation – no reader kept waiting unless writer has
permission to use shared object monitor monitor-name
 Second variation – once writer is ready, it performs the write ASAP
{
 Both may have starvation leading to even more variations
 Problem is solved on some systems by kernel providing reader- // shared variable declarations
writer locks
procedure P1 (…) { …. }
Dining-Philosophers Problem procedure Pn (…) {……}
 Philosophers spend their lives alternating Initialization code (…) { … }
thinking and eating
}
 Don’t interact with their neighbors,
occasionally try to pick up 2 chopsticks }
(one at a time) to eat from bowl
o Need both to eat, then release Schematic view of a Monitor
both when done
 In the case of 5 philosophers
o Shared data
 Bowl of rice (data set)
 Semaphore chopstick [5] initialized to 1

Dining-Philosophers Problem Algorithm

The structure of Philosopher i:

do {

wait (chopstick[i] );

wait (chopStick[ (i + 1) % 5] );

// eat Condition Variables

signal (chopstick[i] );  condition x, y;

 Two operations are allowed on a condition variable:
signal (chopstick[ (i + 1) % 5] );
o x.wait() – a process that invokes the operation is
// think suspended until x.signal()
o x.signal() – resumes one of processes (if any) that invoked
} while (TRUE);
x.wait()
 Deadlock handling  If no x.wait() on the variable, then it has no
o Allow at most 4 philosophers to be sitting simultaneously effect on the variable
at the table. Monitor with Condition Variables
o Allow a philosopher to pick up the forks only if both are
available (picking must be done in a critical section.
o Use an asymmetric solution -- an odd-numbered
philosopher picks up first the left chopstick and then the
right chopstick. Even-numbered philosopher picks up first
the right chopstick and then the left chopstick.

Problems with Semaphores

 Incorrect use of semaphore operations:

o signal (mutex) …. wait (mutex)
o wait (mutex) … wait (mutex)
o Omitting of wait (mutex) or signal (mutex) (or both)
 Deadlock and starvation are possible. Condition Variables Choices

Monitors  If process P invokes x.signal(), and process Q is suspended in

x.wait(), what should happen next?
A high-level abstraction that provides a convenient and effective o Both Q and P cannot execute in paralel. If Q is resumed,
mechanism for process synchronization then P must wait
 Options include
 o Signal and wait – P waits until Q either leaves the monitor {
or it waits for another condition
boolean busy;
o Signal and continue – Q waits until P either leaves the
monitor or it waits for another condition condition x;
o Both have pros and cons – language implementer can void acquire(int time) {
decide
o Monitors implemented in Concurrent Pascal compromise if (busy)
 P executing signal immediately leaves the x.wait(time);
monitor, Q is resumed
o Implemented in other languages including Mesa, C#, Java busy = TRUE;

}
Monitor Solution to Dining Philosophers
void release() {

busy = FALSE;

x.signal();

initialization code() {

busy = FALSE;

Each philosopher i invokes the operations pickup() and putdown() in

the following sequence:

DiningPhilosophers.pickup(i);

EAT

DiningPhilosophers.putdown(i);

No deadlock, but starvation is possible

Resuming Processes within a Monitor

 If several processes queued on condition x, and x.signal()

executed, which should be resumed?
 FCFS frequently not adequate
 conditional-wait construct of the form x.wait(c)
o Where c is priority number
o Process with lowest number (highest priority) is
scheduled next

Single Resource allocation

 Allocate a single resource among competing processes using

priority numbers that specify the maximum time a process plans
to use the resource

R.acquire(t);

...

access the resurce;

...

R.release;

 Where R is an instance of type ResourceAllocator

 A Monitor to Allocate Single Resource

monitor ResourceAllocator