System Overview

1
System Overview
System Overview
Recommended Reading Bacon, J. Concurrent
Systems (1, 2) Davis, W. Operating Systems
(2) Nehmer, J. Grundlagen moderner
Betrieebssysteme (1) Silbershatz, A. Operating
System Concepts (3) Stallings, W. Operating
Systems (2) Tanenbaum, A. Modern Operating
Systems (1) Wettstein, H. Systemarchitektur,
Chapter 3
2
System Overview
Introduction Motivation µ-Kernel
Systems System Types System
Characteristics System Architectures
Some Notions
3
System Overview
What is an Operating System?
An interface between applications and
hardware Comment Every complex system needs
some kind of administration layer between
users or customers and the resources needed to
execute the tasks

• Examples
• university
• restaurant
• bank

4
System Overview
Other Ideas about an Operating System

• OS primal mud of a computer system
• Makes reality pretty
• OS is magic to most people.
• This course rips open
• OS extended example of a complex system
• huge, parallel, not completely understood,
• insanely expensive to build, e.g.
• Win/NT 8 years, 1000s of people. Still
  doesnt work well
• most interesting things are complex systems
• internet, air traffic control, governments,
  weather, space shuttle,

5
System Overview
What are the objectives of an Operating System?

• Convenience
• OS should facilitate programming of applications
• Abstraction
• HW details should be hidden
• Uniform interface for different I/O devices
  should be provided
• Generality
• Changes in the characteristics of major
  application shouldnt
• require a complete redesign
• Extensibility
• Should permit development, testing and
  introduction of new
• system functions without interfering with
  current service

6
System Overview
What are the objectives of an Operating System?

• Scalability
• System should be able to face ever increasing
  load conditions
• Efficiency
• Make good use of resources and be fast
• Robustness
• No system breakdown due to a malicious or
  erroneous application
• Protection
• Should provide fairness, security, and safety

7
System Overview
Why do we need System Architecture and System
Architects at all?
applications
market
The job of a system architect is similar to
the one of a witty octopus juggling daily new
balls of different size on the back of a
jumping dolphin at the shore of Waikiki. He
also has to take care of sharks and other bad
guys around him.
hackers
hardware
8
System Overview
Why do we need System Architecture and System
Architects at all?
1. To design useful and extensible systems
2. To establish non-functional properties, e.g.
quality-of-service guarantees (QoS) 3. To
implement correct, secure, and robust systems

9
System Overview
History on OS Evolution Step 0
APP
OS
Hardware

• Simple OS One program, one user, one machine
• examples early computers, early PCs,
• embedded controllers such as nintendo, cars,
  elevators
• OS just a library of standard services.
  Examples
• standard device drivers, interrupt handlers,
  I/O.
• Non-problems No malisiuos people. No bad
  programs.
• ? A minimum of complex interactions
• Problem poor utilization, expensive

10
System Overview
History on OS Evolution Step 1

• Simple OS is inefficient
• if process is waiting for something, machine sits
  wasted.
• (Seemingly) Simple hack
• run more than one process at once
• when one process blocks, switch to another
• A couple of problems what if a program
• infinite loops?
• starts randomly scribbling on memory?
• OS adds protection
• interposition preemption
  privilege

11
System Overview
History on OS Evolution Step 2

• Simple OS is expensive
• one user one computer
• (Seemingly) Simple hack
• Allow more than user at once.
• Does machine now run N times slower? Usually
  not!
• Key observation users bursty.
• If one idle, give other resources.
• Couple of problems
• what if users are greedy?
• evil?
• or just too numerous?
• OS adds protection
• (notice as we try to utilize resources,
  complexity grows)

12
System Overview
System Structure
Software System Set of Components
13
System Overview
System Components

• Application (e.g. traffic simulation,
• weather forecasting,
• editing a textbook etc.)
• Subsystem with a specific task
• - controlling (e.g. shell)
• - protecting (e.g. firewall)
• - accounting (e.g. monitor)
• - servicing (e.g. file server)
• - supporting (e.g. disk driver)
• Basic Function (e.g. synchronization)

14
System Overview
System Structure
Software System Set of components and
their interconnections with various
interdependencies
Varying in functionality and performance
15
System Overview
Interdependencies between Components

• Calls main() calls printf()
• Serialization thread1 after thread2
• Communication message from a sender to a
  receiver
• Master/Slave shell invokes an application
• Peers producer and consumer
• Client/Server application uses a file server

16
is there a discipline how to construct and
structure complex software systems? (see course
Software Technique)
System Overview
System Structure
Software System Set of components and
their interconnections with various
interdependencies
17
System Overview
Whats the appropriate type to implement this
component?
System Structure
Software System Set of components and
their interconnections with various
interdependencies

• Main or Procedure
• Module, Abstract Data Type
• Object or Class
• Process or Thread

Disk Driver
18
System Overview
can we imply some ordering within the structure
of a system?
System Structure
Software System Set of components and
their interconnections with various
interdependencies
19
System Overview
What does this ordering imply? Is it a strict
layering? What has to be up, what has to be down?
Layers
Application Programs
Utilities
Operating-System
Computer Hardware
20
System Overview
Nested Layered System Structure
Emulation of an existing operating system on top
of a kernel
Unix application
Unix application
Unix system call interface
Unix Emulation
Kernel interface
Kernel
Communication softeware
Terminal driver
Process manager
Memory manager
Network Driver
21
System Overview
Potential System Components
Task Semantic Objects Example
Operation GUI/shell window Execute Shell
Script Application a.out Quit, Kill, File
System directories, files Open, Close, Read,
Devices printer, display Open, Write, ...
Communication ports Send, Receive, Virtual
Memory segments, pages Map, Write,
Fetch Secondary Store chunks, blocks Allocate,
Free, Processes task queue Exit,
Create Threads ready queue Wakeup,
Execute, Interrupts interrupt handler Invoke,
Mask, ...
22
System Overview
Typical Layering within the I/O-Subsystem
Application program Language runtime system and
library routines
Mapping of library routines to system calls
AS
System call
OS
Determine device type notify appropriate driver
I/O control
Driver needs to know the device details and must
be authorized to program the device
Device driver
Map an abstract device function to the device
interface function(s)
Device interface
disk
23
System Overview
Controlling Role

• The operating system controls the
• movement
• storage and
• processing of data
• but it is not always in controlling phase

Note On a single processos system either the
operating system or an application is executed
24
System Overview
Monolithic Systems
Rating Fast, however, no protection at all.
Any application can monopolize and bring down
the system.
25
System Overview
System Services

• Program development (editor, compiler, debugger
  )
• Program execution (loading, initializing, )
• Access to I/O devices (controlling)
• Access to files (file operations, protection)
• Access to system (security and protection)
• Error detection (minimize effects of HW, SW
  errors)
• Accounting

26
System Overview
System Call
Monolithic-Kernel Systems

• Rating
• Most OS services inside the privileged kernel
  ?
• Kernel protected against applications.
• Applications protected against each other
  (virtual address space)
• Kernel components not protected against each
  other.
• Applications must trust the kernel.

27
System Overview
µ-Kernel Systems

• Rating
• see below in greater detail

Only few µ-kernel interface functions (e.g. L4
offers only 7 )! Can you state some good reasons?
28
System Overview
Pros and Cons of a µ-Kernel Architecture
easier to test/proof/modify improved
robustness security improved
maintainability coexistence of n
APIs extensibility
decomposing effort less performance communicatio
n overhead
29
System Overview
Strong Arguments against µ-Kernel Systems
1. Weak Performance 2. Still Large and
Inflexible Vehicles

• Comment True for µ-kernels of the 1st generation
  like
• Mach (CMU, OSF)
• Chorus (INRIA, Chorus)
• Amoeba (Vrije Universiteit)
• L3 (GMD)

30
System Overview
Machs 100 µsec Disaster
IPC Costs (Intel 486, 50 MHz)
Jump to first page
31
System Overview
µ-Kernel Architectures of 2nd Generation

• L4 (GMD, IBM, Uni Ka)
• Exokernel (MIT)
• Pebbles (Bell Labs)
• Flux (U of Utah)
• show far better performance results.

32
System Overview
Architectural Costs (monolithic kernel)
Application
write_file(file a, record xyz)
User Mode Kernel Mode
Monolithic Kernel
File Server
get_disk_block()
Disk Driver
33
System Overview
Architectural Costs (monolithic kernel)
1 System Call (including kernel entrance
leaving) 1 Procedure Call 1 Return (both
within kernel address space,
potential sharing of common information)
Why performance loss through µ-kernels?
34
System Overview
Architectural Costs (µ-Kernel)
Application
SVC-Interface
File Server
Disk Driver
User Mode Kernel Mode
µ-Kernel
35
System Overview
Architectural Costs (µ-Kernel)

• 1. µK ipc call to file server (write_file ),
  including
• µK Entrance/Leaving
• message transfer
• address-space switch to server
• 2. µK ipc call to disk driver (write_block ),
  costs see (1.)
• 3. µK ipc reply to file server (done ), costs
  see (1.)
• 4. µK ipc reply to application (done ), costs
  see (1.)

Result Exchanging information via messages
implies overhead.
36
System Overview
Conclusion
µ-Kernel operations have to be
fast, faster, fastest !!!
We have to provide a very fast µ-kernel entrance
and µ-kernel exit.
37
System Overview
System Design Parameters

• Size (tiny pervasive, NC, PC, WS, Super
  Computer, LM,WANs)
• Price (low budget systems, medium b.s., high
  b.s.)
• Performance (slow, , ultra fast)
• Scalability (non scalable, slightly ..., highly
  scalable)
• Versatility (dedicated systems, ., general
  purpose systems)
• Security (open systems, ... closed systems)
• Homogeneity (homogeneous, heterogeneous)
• Mobility (stationary, fully mobile systems)
• Think it over, e.g. how do they interfere?

38
System Overview
Specific Systems

• Real time System (see course real time systems
  (next ST) and
• seminar Real-Time-Systems and
  -Architectures)
• Database System (see communication and data
  bases)
• Operating System (the main examples in this
  course)
• Middleware (see use of distributed systems)
• Concurrent Application (see parallel
  algorithms,hot systems)

39
System Overview
Real Time Systems

• Process Control
• hard real time requirements
• responds to an alarm signal in specific time,
  otherwise a
• an expensive disaster or even a catastrophe
  might happen,
• e.g. fuel injection control, ABS, Air Bag etc.
  in a car,
• flight control, nuclear power station,
  military equipment, ...)
• signals arrive in some unpredictable way
• Multimedia
• soft real time requirements
• responds to a signal in more or less specific
  time,
• otherwise something unpleasant, but no
  catastrophe will happen
• (synchronize audio and video signals)
• signals tend to occur periodically

40
System Overview
Process Control Systems
Component Computer
Actor
Sensor
External Process under control
e.g. patient in an emergency room in a hospital
Network
41
System Overview
Component Computer
Sensor Interface
Actuator Interface
Monitoring gathers data analyses data reports
results
Controlling responds to alarms responds to
management
Network Interface
Network
42
System Overview
Multi Media Systems
camera
speaker
gateway, router etc.

• Videophone, -mail or -conferencing
• Multimedia documents (museum catalogue, music
  video archive etc.)

43
System Overview
Requirements for Real Time Systems

• Support separate concurrent activities
• (some are periodic, some are unpredictable)
• Specific requirements of activities
• (meet deadlines, assure quality of service)
• Support for teamwork of some activities
• (achieving a common goal)

44
System Overview
Database Systems
Database containing flight information
Booking system
Booking clerks at remote terminals
Network
45
System Overview
Requirements for Database Systems

• Support separate activities
• Support for concurrent accesses and updates
• of the database without interference
• Results of a transaction are recorded
• permanently and securely before user is
• told that an operation has been done

46
System Overview
Operating Systems

• Single-user system
• Multi-user system
• Distributed Operating System

47
System Overview
Operating Systems (SUS)
Users I/O devices
Devices
Memory
users program(s) operating system
disk
screen
printer
keyboard
processor (cpu)
48
System Overview
Operating Systems (MUS)
Users I/O devices
Devices
Memory
users programs operating system
disk
disk
disk
disk
disk
disk
tape
tape
printer
processor (cpu)
printer
processor (cpu)
printer
49
System Overview
Distributed Operating System
user at workstation
user at workstation
user at workstation
user at workstation
file server
print server
gateway
user at workstation
user at workstation
user at workstation
print server
file server
50
System Overview
Requirements of Operating Systems

• Support separate activities on application level
• Support separate activities within the OS
• Support separate activities working together
  (e.g. spooler)
• Support resource management
• Support synchronization and communication
  between
• separate activities, e.g. reading/writing
  shared data
• Support protection and security

51
System Overview

• Examples of Operating Systems within this Course
• Unix (OS for WS)
• (see http//www.cl.cam.ac.uk/smh22/os-net.html
  unix or
• http//www.unix-vs-nt.org/)
• Windows 98/NT/2000 (OS for PC, WS)
• (see course Windows NT Internals or
• http//www.sysinternals.com/ntinfo.htm)
• Linux (OS for PC)
• (see proseminar Linux Internals
• http//www.linuxhq.com/guides/TLK/tlk.html)
• Hopefully these systems contain some
  commonly usable concepts
• that can also be applied to other
  systems.

52
System Overview
Unix Architecture
53
System Overview
Windows Architecture
54
System Overview
Example Simulation System
Without an application specific controlling
interface, you can only abort and restart the
simulation (via usual system commands, i.e. kill
or exec etc.). With an application specific
controlling interface, you may stop and protocol
an endless running simulation, and resume it
with proper parameters. gt Paradigms,
Principles, Policies and Mechanisms of OSes
can be also used within other systems.
55
System Overview
Middleware
Client
Object
Object naming service
IDL stub
IDL skeleton
IDL compiler
Object Request Broker (ORB)
Interface repository
OS
OS
Implementation repository
Network
56
System Overview
Requirements of Middleware

• Support for separate activities induced by
  clients
• Support for protection and security
• Support for location and implementation
  transparency
• Support for communication mechanisms

57
System Overview
Parallel Application (Replicated code,
partitioned data)
Partition of data
Partition of data
Partition of data
Partition of data
Copy of code to execute data
Copy of code to execute data
Copy of code to execute data
Copy of code to execute data
Manager of parallel computations (initiating
computations, synchronizing results)
58
System Overview
Parallel Application (Pipelined Processing)
Who knows a typical example for this pattern?
Starting input
Data 5
First phase of code
Second phase of code
Third phase of code
Fourth phase of code
Data 4
Data 3
Data 2
Data 1
Final output
Intermediate outputs/inputs
59
System Overview
Requirements for Concurrent Applications

• Support for separate activities inclusive their
  controlling
• (i.e. create, start and stop activities)
• Support to synchronize these activities and/or
  to allow
• cooperation on shared data
• Support for communication mechanisms

60
System Overview
Summary

• Lots of different systems (comparable to system
  type car)

61
System Overview
Summary

• Lots of different systems (comparable to system
  type car)
• Some common requirements, e.g. separate
  activities
• (comparable to the standard solution four
  wheel car)
• Some specific requirements, e.g. deadlines in
  real-time
• systems (comparable to ABS supported cars)

• Goal of this course
• Focus on common principles, policies and
  mechanisms
• Additionally some specific solutions

62
System Overview
Summary Many different Systems
There is not a single system that is ideally
suited for all purposes. Thus we need differently
customized systems, or would you really hire
with this car
to transport fresh halibuts from Cuxhaven to
Karlsruhe?
Interesting Question How can we detect and
evaluate commonly used
principles and mechanisms in our target systems?
63
System Overview
Performance

• Only few dedicated systems can be optimized
• to achieve ideal performance.
• In general, we have to live with more or less
  suited
• compromises (due to conflicting requirements)
• However, any system we are modeling or
• implementing has to be correct.
• Correctness is mandatory !!!
• Although total correctness is hardly achievable,
  we have
• to work hard to make a system as correct as
  possible!
• (Seems to be a never-ending story)

64
System Overview

• Special System Architectures
• Virtual Machine
• Local Client/Server Model
• Distributed Client/Server Model

65
System Overview

• Special System Architectures
• Virtual Machine
• Local Client Server Model
• Distributed Client Server Model

. . .
. . .
. . .
Unix Kernel
OS/2 Kernel
NT Kernel
Virtual Machine Monitor
66
System Overview

• Special System Architectures
• Virtual Machine
• Local Client Server Model
• Distributed Client Server Model

Client Process
File Server
Disk Server
Disk Server
Kernel
IPC
67
System Overview

• Special System Architectures
• Virtual Machine
• Local Client Server Model
• Distributed Client Server Model

Client
Kernel
...
Network
68
System Overview
Basic Notions

• Single/Multi-Processor
• Single/Multi-Processing
• Single/Multi-Address Space
• Single/Multi-Programming
• Single/Multi-User

Dont mix up these notions
69
System Overview
Single-/Multi-Processor System
(a matter of hardware design)

• 1 processor (CPU)
• p processors (tightly coupled)
• either UMA SMPs
• or NUMA SMPs
• p processors (loosely coupled)
• either parallel systems
• or distributed systems

70
System Overview
Single/Multi-Processing
(a matter of software design)

• 1 process per CPU
• The (or one of the) CPUs is executing
• one (specific) process all the time
• n gt p processes
• - Symmetric multiprocessing
• (each CPU can execute any process)
• - Asymmetric multiprocessing
• (some processes may need special CPUs)
  

71
System Overview
Single/Multi-Address Spaces
(a matter of software design)

• 1 Address Space shared by all tasks
• SASOS, Single Address Space OS
• Relatively new design for 64-bit processors
• Protection has to offered via domains
• n Address Spaces (1 per process/task)
• (Usual case)

72
System Overview
Single/Multi-Programming
(a matter of software design)

• only 1 application per system
• m concurrent application per system
• (m should be limited by system capacity)

73
System Overview
Single/Multi-User
(a matter of software design)

• 1 user per system
• (typical for PC and WS)
• m concurrent users
• (typical for main frames and distributed
  systems)