1. Introduction to Operating System (OS)
Operating Systems
Introduction to Operating System (OS)
A. Frank - P. Weisberg

2. Slides Credits for all PPTs of OS course
The slides/diagrams in this course are an adaptation, combination, and enhancement of material from the following resources and persons:
Slides of A. Silberschatz, P. B. Galvin and G. Gagne (see book references ahead) with some enhancements by Y. Wiseman.
Slides of Mario Marchand of the University of Ottawa and Patricia Roy of Manatee Community College based on W. Stallings (see book reference ahead) with some enhancements by O. Kremien and E. Gruengard.
Some diagrams from R. A. Finkel and Andrew S. Tanenbaum (see book references ahead).
A. Frank - P. Weisberg

3. What is an Operating System (1)?
A modern computer consists of:
One or more processors
Main memory
Disks
Printers
Various input/output devices.
Managing all these varied components requires a layer of software – the Operating System (OS).
A. Frank - P. Weisberg

4. What is an Operating System (2)?
An Operating System is a program that acts as an intermediary/interface between a user of a computer and the computer hardware.
OS goals:
Control/execute user/application programs.
Make the computer system convenient to use.
Ease the solving of user problems.
Use the computer hardware in an efficient manner.
A. Frank - P. Weisberg

5. Where does the OS fit in?
A. Frank - P. Weisberg

6. Services provided by an OS
Facilities for program creation
editors, compilers, linkers, debuggers, etc.
Program execution
loading in memory, I/O and file initialization.
Access to I/O and files
deals with the specifics of I/O and file formats.
System access
resolves conflicts for resource contention.
protection in access to resources and data.
A. Frank - P. Weisberg

7. Why are Operating Systems Important?
Important to understand and know how to correctly use when writing user applications.
Large and complex systems that have a high economic impact and result in interesting problems of management.
Few actually involved in OS design and implementation but nevertheless many general techniques to be learned and applied.
Combines concepts from many other areas of Computer Science: Architecture, Languages, Data Structures, Algorithms.
A. Frank - P. Weisberg

8. Motivation for Operating Systems (OS) Introduction
Course Syllabus (1)
Motivation for Operating Systems (OS)
Introduction
What's an Operating System?
Computer/Operating System Overview
Evolution of Operating Systems
Functional/Protection Aspects
Operating System Structures
A. Frank - P. Weisberg

9. Course Syllabus (2) Concurrent Processes Process Models and Management
Process Description and Control
Task/Thread Description and Control
Concurrency: Mutual Exclusion and Synchronization
Concurrency: Deadlock and Starvation
A. Frank - P. Weisberg

10. Course Syllabus (3) Memory Management Real Memory Management
Motivation for Virtual Memory (VM)
Paging and Segmentation
Page Fetch, Placement and Replacement
A. Frank - P. Weisberg

11. Uniprocessor Scheduling
Course Syllabus (4)
Uniprocessor Scheduling
Levels of CPU Scheduling
Process Scheduling
External Storage Management
File Systems/Management
Directories
File Allocation
Disk Scheduling
A. Frank - P. Weisberg

12. Main Bibliography
A. Silberschatz, P. B. Galvin, and G. Gagne, “Operating Systems Concepts (with Java)”, 8th Edition, John Wiley & Sons, 2009.
A. Frank - P. Weisberg

13. Main Bibliography
W. Stallings, “Operating Systems: Internals and Design Principles”, 7th ed, Prentice Hall,
A. Frank - P. Weisberg

14. Additional Bibliography
A. S. Tanenbaum, “Modern Operating Systems”, 3rd Edition, Prentice-Hall Intl.,
A. Frank - P. Weisberg

15. Additional Bibliography
A. S. Tanenbaum and A. S. Woodhill, “Operating Systems: Design and Implementation”, 3rd Edition, Prentice-Hall Intl.,
A. Frank - P. Weisberg

16. Additional Bibliography
S. Toledo, “Operating Systems”, in Hebrew, Akademon, 2001.
G. Nutt, ``Operating Systems: A Modern Perspective'', 2nd Edition Lab Update, Addison-Wesley,
R. A. Finkel, “An Operating Systems Vade Mecum”, Prentice-Hall Intl., 1988.
A. Frank - P. Weisberg

17. UNIX Bibliography (Internals)
R. Love, “Linux Kernel Development”, 2nd Edition, Novell Press, 2005.
U. Vahalia, “UNIX Internals: The New Frontiers”, Prentice-Hall Intl., 1995.
S. J. Leffler, et al, “The Design and Implementation of the 4.3BSD UNIX Operating System”, Addison-Wesley, 1989.
M. J. Bach, “The Design of the UNIX Operating System”, Prentice-Hall Intl., 1986.
A. Frank - P. Weisberg

18. UNIX Bibliography (Programming)
K. Haviland, et al, “Unix System Programming: A Programmer's Guide to Software Development”, Addison-Wesley, 1999.
W. R. Stevens, and S. A. Rago, “Advanced Programming in the UNIX Environment”, 2nd Edition, Addison-Wesley, 2008.
D. P. Bovet, and M. Cesati, “Understanding the Linux Kernel”, 3rd ed, O’Reilly Media, 2008
A. Frank - P. Weisberg

19. Computer Hardware Organization
A. Frank - P. Weisberg

20. Computer System Components
Hardware – provides basic computing resources (CPU, Memory, I/O devices, Communication).
Operating System – controls and coordinates the use of the hardware among various application programs for various users.
System & Application Programs – ways in which the system resources are used to solve computing problems of the users (Word processors, Compilers, Web browsers, Database systems, Video games).
Users – (People, Machines, other computers).
A. Frank - P. Weisberg

21. Hierarchical view of computer system
A. Frank - P. Weisberg

22. Static View of System Components
A. Frank - P. Weisberg

23. Dynamic View of System Components
A. Frank - P. Weisberg

24. Layers of a Computer System
End
User
Programmer
Application
Programs
Utilities
Operating-
System
Designer
Operating-System
Computer Hardware
A. Frank - P. Weisberg

25. Views of an Operating System
There are three classical views (in literature):
Resource Manager – manages and allocates resources.
Control program – controls the execution of user programs and operations of I/O devices.
Command Executer – Provides an environment for running user commands.
But one more modern view: the Operating System as a Virtual Machine.
A. Frank - P. Weisberg

26. 1. Resource Manager Resource Manager: Sort of a bottom-up view.
Manages and protects multiple computer resources: CPU, Processes, Internal/External memory, Tasks, Applications, Users, Communication channels, etc…
Handles and allocates resources to multiple users or multiple programs running at the same time and space (e.g., processor time, memory, I/O devices).
Decides between conflicting requests for efficient and fair resource use (e.g., maximize throughput, minimize response time).
Sort of a bottom-up view.
A. Frank - P. Weisberg

27. OS as a Resource Manager
A. Frank - P. Weisberg

28. Resource Manager oriented OS names
DEC RSX – Resource Sharing eXecutive
MIT Multics – MULTiplexed Information and Computing Services
IBM MFT/MVT – Multiple Fixed/Variable Tasks
IBM MVS – Multiple Virtual Storage
DEC VMS – Virtual Memory System
MVS TSO – Time Sharing Option
CTSS – Compatible Time Sharing System
IBM VM – Virtual machine
A. Frank - P. Weisberg

29. 2. Control Program Control Program: Sort of a black box view.
Manages all the components of a complex computer system in an integrated manner.
Controls the execution of user programs and I/O devices to prevent errors and improper use of computer resources.
Looks over and protects the computer: Monitor, Supervisor, Executive, Controller, Master, Coordinator ….
Sort of a black box view.
A. Frank - P. Weisberg

30. Control program oriented OS names
Unisys MCP – Master Control Program
DR CP/M – Control Program/Microcomputer
IBM VM/CP – VM Control Program
IBM AIX – Advanced Interactive eXecutive
DEC RSX – Resource Sharing eXecutive
A. Frank - P. Weisberg

31. 3. Command Executer Command Executer: Sort of a top-down view.
Interfaces between the users and machine.
Supplies services/utilities to users.
Provides the users with a convenient CLI (Command Language Interface), also called a Shell (in UNIX), for entering the user commands.
Sort of a top-down view.
A. Frank - P. Weisberg

32. Command Executer oriented OS names
IBM AIX – Advanced Interactive Executive
IBM VM/CMS – Conversational monitor System
A. Frank - P. Weisberg

33. Modern view: Virtual Machine (1)
Operating System as a Virtual Machine:
An interface between the user and hardware that hides the details of the hardware (e.g., I/O).
Constructs higher-level (virtual) resources out of lower-level (physical) resources (e.g., files).
Definition: OS is a collection of software enhancements, executed on the bare hardware, culminating in a high-level virtual machine that serves as an advanced programming environment.
virtual machine = software enhancement = extended machine = abstract machine = layer = level = ring.
A. Frank - P. Weisberg

34. Modern view: Virtual Machine (2)
A. Frank - P. Weisberg

35. Definition of Operating System
There is no universally accepted definition.
“Everything a vendor ships when you order an operating system” is good approximation but varies widely.
“The one program running at all times on the computer” is the Kernel.
Everything else is either a system program (ships with the operating system) or an application program.
A. Frank - P. Weisberg

36. One Kernel Point of View
A. Frank - P. Weisberg

37. What is the OS/Kernel?
Is the Operating System just the Kernel (not the utilities and application programs)?!
The Command Line Interface (CLI) (or command layer/interpreter or shell) allows direct command entry by the user.
The shell used to be in the kernel but now is a (first between equals) utility outside of it:
Easy to change/debug
Many of them (sh, bsh, csh, ksh, tcsh, wsh, bash)
Possible to switch between them (chsh)
A. Frank - P. Weisberg

38. UNIX Shell and Utilities
User
Utilities
Shell
Kernel
Hardware
A. Frank - P. Weisberg

39. Bourne Shell (bsh)
A. Frank - P. Weisberg

40. A very simplified Shell
A. Frank - P. Weisberg

41. UNIX System Layout
A. Frank - P. Weisberg

42. General UNIX Architecture (1)
A. Frank - P. Weisberg

43. General UNIX Architecture (2)
Other application programs
nroff sh
who
a.out
cpp
Kernel
date
comp
Hardware cc we as ld
grep vi ed
Other application programs
A. Frank - P. Weisberg

44. Evolution of Operating Systems
A. Frank - P. Weisberg

45. Evolution of an Operating Systems?
Must adapt to hardware upgrades and new types of hardware. Examples:
Character vs. graphic terminals
Introduction of paging hardware
Must offer new services, e.g., internet support.
The need to change the OS on regular basis place requirements on it’s design:
modular construction with clean interfaces.
object oriented methodology.
A. Frank - P. Weisberg

46. Evolution of Operating Systems
Early Systems (1950)
Simple Batch Systems (1960)
Multiprogrammed Batch Systems (1970)
Time-Sharing and Real-Time Systems (1970)
Personal/Desktop Computers (1980)
Multiprocessor Systems (1980)
Networked/Distributed Systems (1980)
Web-based Systems (1990)
A. Frank - P. Weisberg

47. Early Systems Structure Single user system.
Programmer/User as operator (Open Shop).
Large machines run from console.
Paper Tape or Punched cards.
A. Frank - P. Weisberg

48. Example of an early computer system
A. Frank - P. Weisberg

49. Characteristics of Early Systems
Early software: Assemblers, Libraries of common subroutines (I/O, Floating-point), Device Drivers, Compilers, Linkers.
Need significant amount of setup time.
Extremely slow I/O devices.
Very low CPU utilization.
But computer was very secure.
A. Frank - P. Weisberg

50. Simple Batch Systems Use of high-level languages, magnetic tapes.
Jobs are batched together by type of languages.
An operator was hired to perform the repetitive tasks of loading jobs, starting the computer, and collecting the output (Operator-driven Shop).
It was not feasible for users to inspect memory or patch programs directly.
A. Frank - P. Weisberg

51. Operator-driven Shop
A. Frank - P. Weisberg

52. Operation of Simple Batch Systems
The user submits a job (written on cards or tape) to a computer operator.
The computer operator place a batch of several jobs on an input device.
A special program, the monitor, manages the execution of each program in the batch.
Monitor utilities are loaded when needed.
“Resident monitor” is always in main memory and available for execution.
A. Frank - P. Weisberg

53. Idea of Simple Batch Systems
Reduce setup time by batching similar jobs.
Alternate execution between user program and the monitor program.
Rely on available hardware to effectively alternate execution from various parts of memory.
Use Automatic Job Sequencing – automatically transfer control from one job when it finishes to another one.
A. Frank - P. Weisberg

54. Control Cards (1) Problems:
1. How does the monitor know about the nature of the job (e.g., Fortran versus Assembly) or which program to execute?
2. How does the monitor distinguish: (a) job from job? (b) data from program?
Solution: Introduce Job Control Language (JCL) and control cards.
A. Frank - P. Weisberg

55. Control Cards (2)
Special cards that tell the monitor which programs to run: $JOB $FTN $RUN $DATA $END
Special characters distinguish control cards from data or program cards: $ in column 1 // in column 1 and in column1
A. Frank - P. Weisberg

56. Job Control Language (JCL)
JCL is the language that provides instructions to the monitor:
what compiler to use
what data to use
Example of job format: >>
$FTN loads the compiler and transfers control to it.
$LOAD loads the object code (in place of compiler).
$RUN transfers control to user program.
$JOB
$FTN
...
FORTRAN
program
$LOAD
$RUN
Data
$END
A. Frank - P. Weisberg

57. Example card deck of a Job
A. Frank - P. Weisberg

58. Another Job/Steps example
A. Frank - P. Weisberg

59. Effects of Job Control Language (JCL)
Each read instruction (in user program) causes one line of input to be read.
Causes (OS) input routine to be invoked:
checks for not reading a JCL line.
skip to the next JCL line at completion of user program.
A. Frank - P. Weisberg

60. Resident Monitor is first rudimentary OS.
Resident Monitor (Job Sequencer):
initial control is in monitor.
loads next program and transfers control to it.
when job completes, the control transfers back to monitor.
Automatically transfers control from one job to another, no idle time between programs.
A. Frank - P. Weisberg

61. Resident Monitor Layout
A. Frank - P. Weisberg

62. Resident Monitor Parts
Parts of resident monitor:
Control Language Interpreter – responsible for reading and carrying out instructions on the cards.
Loader – loads systems programs and applications programs into memory.
Device drivers – know special characteristics and properties for each of the system’s I/O devices.
A. Frank - P. Weisberg

63. Desirable Hardware Features
Memory protection
do not allow the memory area containing the monitor to be altered by a user program.
Privileged instructions
can be executed only by the resident monitor.
A trap occurs if a program tries these instructions.
Interrupts
provide flexibility for relinquishing control to and regaining control from user programs.
Timer interrupts prevent a job from monopolizing the system.
A. Frank - P. Weisberg

64. Offline Operation Problem:
Card Reader slow, Printer slow (compared to Tape).
I/O and CPU could not overlap.
Solution: Offline Operation (Satellite Computers) –
speed up computation by loading jobs into memory from tapes while card reading and line printing is done off-line using smaller machines.
A. Frank - P. Weisberg

65. Main/Offline Computers
A. Frank - P. Weisberg

66. Spooling (1) Problem: Solution: Spooling -
Card reader, Line printer and Tape drives slow (compared to Disk).
I/O and CPU could not overlap.
Solution: Spooling -
Overlap I/O of one job with the computation of another job (using double buffering, DMA, etc).
Technique is called SPOOLing: Simultaneous Peripheral Operation On Line.
A. Frank - P. Weisberg

67. Spooling System Components
A. Frank - P. Weisberg

68. Spooling (2) While executing one job, the OS:
Reads next job from card reader into a storage area on the disk (Job pool).
Outputs printout of previous job from disk to printer.
Job pool – data structure that allows the OS to select which job to run next in order to increase CPU utilization.
A. Frank - P. Weisberg

69. We assumed Uniprogramming until now
I/O operations are exceedingly slow (compared to instruction execution).
A program containing even a very small number of I/O operations, will spend most of its time waiting for them.
Hence: poor CPU usage when only one program is present in memory.
A. Frank - P. Weisberg

70. Memory Layout for Uniprogramming
A. Frank - P. Weisberg

71. Memory Layout for Batch Multiprogramming
Several jobs are kept in main memory at the same time, and the CPU is multiplexed among them.
A. Frank - P. Weisberg

72. Multiprogramming (1)
A. Frank - P. Weisberg

73. Multiprogramming (2)
A. Frank - P. Weisberg

74. Why Multiprogramming?
Multiprogramming (also known as Multitasking) needed for efficiency:
Single user cannot keep CPU and I/O devices busy at all times.
Multiprogramming organizes jobs (code and data) so CPU always has one to execute.
A subset of total jobs in system is kept in memory.
One job selected and run via job scheduling.
When it has to wait (for I/O for example), OS switches to another job.
A. Frank - P. Weisberg

75. Example of Multiprogramming
kernel
I/O }
scheduler
I/O request {
device driver
scheduler }
Time slice exceeded
scheduler }
Interrupt
device driver { }
scheduler
A. Frank - P. Weisberg

76. Components of Multiprogramming
A. Frank - P. Weisberg

77. Requirements for Multiprogramming
Hardware support:
I/O interrupts and DMA controllers
in order to execute instructions while I/O device is busy.
Timer interrupts for CPU to gain control.
Memory management
several ready-to-run jobs must be kept in memory.
Memory protection (data and programs).
Software support from the OS:
For scheduling (which program is to be run next).
To manage resource contention.
A. Frank - P. Weisberg

78. Evolution of Operating Systems
A. Frank - P. Weisberg

79. Evolution of Operating Systems
Early Systems (1950)
Simple Batch Systems (1960)
Multiprogrammed Batch Systems (1970)
Time-Sharing and Real-Time Systems (1970)
Personal/Desktop Computers (1980)
Multiprocessor Systems (1980)
Networked/Distributed Systems (1980)
Web-based Systems (1990)
A. Frank - P. Weisberg

80. Time-Sharing
Batch multiprogramming does not support interaction with users.
Time-sharing extends Batch Multiprogramming to handle multiple interactive jobs – it’s Interactive Multiprogramming.
Multiple users simultaneously access the system through commands entered at terminals.
Processor’s time is shared among multiple users.
A. Frank - P. Weisberg

81. Time-sharing Architecture
A. Frank - P. Weisberg

82. Why Time-sharing?
In Time-sharing (multitasking) the CPU switches jobs so frequently that users can interact with each job while it is running, creating interactive computing:
Response time should be < 1 second.
Each user has at least one program (process) executing in memory.
CPU scheduling supports several jobs ready to run at the same time.
If processes don’t fit in memory, swapping moves them in and out to run.
Virtual memory allows execution of processes not completely in memory.
A. Frank - P. Weisberg

83. Why did Time-Sharing work?
Because of slow human reaction time, a typical user needs 2 seconds of processing time per minute.
Then many users should be able to share the same system without noticeable delay in the computer reaction time.
The user should get a good response time.
It fit the economic basis of the mainframe computer installation.
A. Frank - P. Weisberg

84. Real-Time Systems
Note that not all Operating Systems are general-purpose systems.
Real-Time (RT) systems are dedicated systems that need to adhere to deadlines , i.e., time constraints.
Correctness of the computation depends not only on the logical result but also on the time at which the results are produced.
A. Frank - P. Weisberg

85. Hard Real-Time Systems
Hard real-time system must meet its deadline.
Conflicts with time-sharing systems, not supported by general-purpose OSs.
Often used as a control device in a dedicated application:
Industrial control
Robotics
Secondary storage limited or absent, data/program is stored in short term memory, or Read-Only Memory (ROM).
A. Frank - P. Weisberg

86. Soft Real-Time Systems
Deadlines desirable but not mandatory.
Limited utility in industrial control or robotics.
Useful in modern applications (multimedia, video conference, virtual reality) requiring advanced operating-system features.
A. Frank - P. Weisberg

87. Personal/Desktop Computers (1)
Personal computers – computer system dedicated to a single user.
I/O devices: keyboards, mice, display screens, small printers.
User convenience and responsiveness.
Can adopt technology developed for larger operating system; often individuals have sole use of computer and do not need advanced CPU utilization of protection features.
May run several different types of operating systems (Windows, MacOS, UNIX, Linux)
A. Frank - P. Weisberg

88. Components of a simple personal computer
A. Frank - P. Weisberg

89. (2) Personal/Desktop Systems
Traditional personal computer blurring over time.
Office environment:
PCs connected to a network, terminals attached to mainframe or minicomputers providing batch and timesharing.
Now portals allowing networked and remote systems access to same resources.
Home networks:
Used to be single system, then modems
Now firewalled, networked.
A. Frank - P. Weisberg

90. Two categories of Computer Systems
Single Instruction Single Data (SISD) –
single processor executes a single instruction sequence to operate on data stored in a single memory.
This is a Uniprocessor.
Multiple Instruction Multiple Data (MIMD) -
a set of processors simultaneously execute different instruction sequences on different data sets.
This is a Multiprocessor.
A. Frank - P. Weisberg

91. Multiprocessor Systems
System with several CPUs in close communication:
processors share memory and a clock.
communication usually takes place through the shared memory.
Also known as parallel systems, tightly-coupled systems.
Multiprocessors systems growing in use and importance – advantages include:
Increased throughput
Economy of scale
Increased reliability – graceful degradation or fault tolerance.
A. Frank - P. Weisberg

92. Multiprocessor Architecture
A. Frank - P. Weisberg

93. Multithreaded/Multicore Chips
A. Frank - P. Weisberg

94. Multiprogramming vs. Multiprocessing
A. Frank - P. Weisberg

95. Types of Multiprocessor Systems
Asymmetric Multiprocessing
master processor schedules and allocates work to slave processors.
Symmetric Multiprocessing (SMP)
Each processor runs an identical copy of the operating system.
Typically each processor does self-scheduling form the pool of available process.
Most modern operating systems support SMP.
A. Frank - P. Weisberg

96. Symmetric Multiprocessing (SMP)
Each processor can perform the same functions and share same main memory and I/O facilities (symmetric).
The OS schedule processes/threads across all the processors (real parallelism).
Existence of multiple processors is transparent to the user.
Incremental growth: just add another CPU!
Robustness: a single CPU failure does not halt the system, only the performance is reduced.
A. Frank - P. Weisberg

97. Clustered Systems (1)
Clustering allows two or more systems to share external storage and balance CPU load:
processors also have their own external memory
communication takes place through high-speed channels
Provides high reliability
Also known as Closely-coupled system.
Like multiprocessor systems, but multiple systems here are working together.
A. Frank - P. Weisberg

98. Clustered Systems Architecture
A. Frank - P. Weisberg

99. Architecture for Cluster Computing System

100. Clustered Systems (2)
Usually sharing storage via a Storage-Area Network (SAN).
Provides a high-availability service which survives failures:
Asymmetric clustering has one machine in hot-standby mode
Symmetric clustering has multiple nodes running applications, monitoring each other.
Some clusters are used for high-performance computing (HPC) where applications must be written to use parallelization.
A. Frank - P. Weisberg

101. Networked Systems
Distribute resources and the computation among several physical processors.
Loosely coupled system:
each processor has its own local memory.
processors communicate with one another through various communications lines.
Advantages:
Resources Sharing
Computation speed up – load sharing
Reliability
A. Frank - P. Weisberg

102. Networked System Structure
node 2
node 1
disk
processors
disk
processors
network
node 3
node N
disk
processors
disk
processors …
A. Frank - P. Weisberg

103. Requires networking infrastructure.
Networked Systems
Requires networking infrastructure.
Most are Local area networks (LAN) or Wide area networks (WAN).
May be either Centralized Sever or Client/Server or Peer-to-Peer (P2P) systems.
A. Frank - P. Weisberg

104. Local Area Network (LAN)
LAN designed to cover small geographical area:
Multiaccess bus, ring, or star network.
Speed  10–100 Megabits/second.
Broadcast is fast and cheap.
Nodes:
usually workstations and/or personal computers.
a few (usually one or two) mainframes.

105. Example of Local Area Network (LAN)
A. Frank - P. Weisberg

106. Wide-Area Network (WAN)
Links geographically separated sites:
Point-to-point connections over long-haul lines (often leased from a phone company).
Speed  1.544–45 Megabits/second.
Broadcast usually requires multiple messages.
Nodes:
usually a high percentage of mainframes.

107. Example of Wide Area Network (WAN)
A. Frank - P. Weisberg

108. Network-attached Storage (NAS)
A. Frank - P. Weisberg

109. Storage-area Network (SAN)
A. Frank - P. Weisberg

110. Generic Client/Server Environment
A. Frank - P. Weisberg

111. Client/Server Computing
Dumb terminals supplanted by smart PCs.
Many systems are now servers, responding to requests generated by clients:
Compute-server provides an interface to client to request services (i.e., database).
File-server provides interface for clients to store and retrieve files.
A. Frank - P. Weisberg

112. General Structure of a Client/Server System
A. Frank - P. Weisberg

113. Distributed Systems
Distributed system is collection of loosely coupled processors interconnected by a communications network.
Processors variously called nodes, computers, machines, hosts.
Reasons for distributed systems:
Resource sharing:
sharing and printing files at remote sites.
processing information in a distributed database.
using remote specialized hardware devices.
Computation speedup – load sharing.
Reliability – detect and recover from site failure, function transfer, reintegrate failed site.
Communication – message passing.

114. Distributed Systems
A. Frank - P. Weisberg

115. Peer-To-Peer (P2P) P2P does not distinguish clients and servers.
Instead all nodes are considered peers.
May each act as client, server or both.
Node must join P2P network:
Registers its service with central lookup service on network, or
Broadcasts request for service and responds to requests for service via discovery protocol
Examples include Napster and Gnutella.
A. Frank - P. Weisberg

116. Peer-To-Peer (P2P) Systems
DISTRIBUTED SERVICE
A. Frank - P. Weisberg

117. (NOS) Networked Operating Systems
Each computer runs independently from other computers on the network.
Provides mainly file sharing.
Users are aware of multiplicity of machines.
Access to resources of various machines is done explicitly by:
Remote logging into the appropriate remote machine (telnet, ssh).
Remote Desktop (Microsoft Windows).
Transferring data from remote machines to local machines, via the File Transfer Protocol (FTP) mechanism.
A. Frank - P. Weisberg

118. Distributed Operating Systems (DOS)
Gives the impression there is a single operating system controlling the network.
Users not aware of multiplicity of machines
Access to remote resources similar to access to local ones.
Network is mostly transparent – it’s a powerful virtual machine.
Data Migration – transfer data by transferring entire file, or transferring only those portions of the file necessary for the immediate task.
Computation Migration – transfer the computation, rather than the data, across the system.
Process Migration – execute an entire process, or parts of it, at different sites.
A. Frank - P. Weisberg

119. Web has become ubiquitous. PCs most prevalent devices.
Web-based Systems
Web has become ubiquitous.
PCs most prevalent devices.
More devices becoming networked to allow web access.
New category of devices to manage Web traffic among similar servers: Load Balancers.
Basis for Grids/Cloud Computing.
A. Frank - P. Weisberg

120. Grid Computing Systems
Collection of computer resources, usually owned by multiple parties and in multiple locations, connected together such that users can share access to their combined power:
Can easily span a wide-area network
Heterogeneous environment
Crosses administrative/geographic boundaries
Supports Virtual Organizations (VOs)
Examples: EGEE - Enabling Grids for E-SciencE (Europe), Open Science Grid (USA).

121. Cloud Computing Systems (1)
Collection of computer resources, usually owned by a single entity, connected together such that users can lease access to a share of their combined power:
Location independence: the user can access the desired service from anywhere in the world, using any device with any (supported) system.
Cost-effectiveness: the whole infrastructure is owned by the provider and requires no capital outlay by the user.
Reliability: enhanced by way of multiple redundant sites, though outages can occur, leaving users unable to remedy the situation.

122. Cloud Computing Systems (2)
Scalability: user needs can be tailored to available resources as demand dictates – cost benefit is obvious.
Security: low risk of data loss thanks to centralization, though problems with control over sensitive data need to be solved.
Readily consumable: the user usually does not need to do much deployment or customization, as the provided services are easy to adopt and ready-to-use.
Examples: Amazon EC2 (Elastic Compute Cloud), Google App Engine, IBM Enterprise Data Center, MS Windows Azure, SUN Cloud Computing.

123. Handheld systems are also dedicated.
Personal Digital Assistants (PDAs).
Cellular telephones.
Issues:
Limited memory
Slow processors
Small display screens
Support for multimedia (images, video).
A. Frank - P. Weisberg

124. Migration of OS Concepts and Features
A. Frank - P. Weisberg