CS523 Operating Systems

1
CS523Operating Systems

• Fred Kuhns
• Applied Research Laboratory
• Computer Science and Engineering
• Washington University in St. Louis

2
CS523 - Operating Systems

• Instructor Fred KuhnsPhone 935-6598Email fred
  k_at_cse.wustl.eduOffice Hours Bryan
  411, Wednesday 400 500
• Location Lopata Hall, Room 101Times 100
  230
• Newsgroup wu.cs.class.523Web
  http//www.arl.wustl.edu/fredk/Courses/cs523

3
Course Materials

• No Required Textbook, but I will reference the
  following
• Real-Time Systems, Jane W. S. Liu, Prentice Hall,
  2000
• Foundations of Multithreaded, Parallel, and
  Distributed Programming, Gregory Andrews, Addison
  Wesley, 2000
• UNIX Internals The New Frontiers, 2nd edition,
  Uresh Vahalia, Prentice Hall, 2001
• The Design and Implementation of the 4.4 BSD
  Operating System, McKusick, Bostic, Karels and
  Quarterman, Addison Wesley, 1996
• and your favorite undergraduate text
• Selected papers from the literature, web page,
  handouts, class notes, and man pages

4
Course Work and Grading

• Grading scale 0 100 (points)
• 90 -gt A, 80-89 -gtB, 70-79 -gt C, 60-69 -gt D, else
  F
• Project with report 45 points
• Implementation must be submitted in 3 stages, 10
  points for each stage
• Project report written as a paper, 15 points
• Final exam 15 points
• Homework and Quiz 30 points
• Homework problems or minor programming
  assignments.
• Quizzes announced or unannounced
• Class participation 10 points
• everyone starts out with 10 points for just
  showing up
• if not in class when called on, or not prepared
  then -1 point

5
Other Policies

• Late Policy
• only with prior approval
• Post questions to the newsgroup, rather than
  sending email to me
• all benefit from both the questions and answers
• someone other than I may respond faster
• feel free to discuss homework and projects on the
  newsgroup
• do not post answers, but you may post hints or
  code snippets

6
Programming Project

• Major systems design and implementation
• Project report
• Introduction and motivation problem
  identification, why I should care and solution
  outline
• problem, context and solution
• System (i.e. project) implementation overview
• Analysis this is where you provide quantitative
  data to support your claims.
• Related work what others have done to solve this
  problem
• Conclusions and Future work
• Software/system development
• Correct, predictable behavior
• Performance (efficiency)
• Completeness of design
• readability of code (maintainability and
  whether I can understand it)

7
Source Code Grading Policy

• Design 30
• Are all conditions covered
• Have synchronization and scheduling issues been
  addressed
• Used proper measurement and/or data collection
  techniques
• Does it demonstrate an understanding of the
  underlying issues
• Does solution demonstrate insight or have novel
  approaches been used
• Structure 20
• Logically structured
• Understandability (comments, names etc)
• Maintainability or portability issues
• Documentation 30
• Must include a README file (ascii, lt 80
  columns/line, UNIX format)
• Does analysis address all required issues and is
  it insightful
• Logically structured and understandable
• Followed instructions
• Operation 20
• Work are specified or does it terminate in error
• Accept required parameters
• Results displayed properly

8
Course Overview

• Overview of OS design issues
• Review of general purpose OS services
• Intro to Advanced OS Topics
• Real-Time, Database, Distributed and
  Multiprocessor
• Detailed analysis of conventional OS internals
• Focus on UNIX - Linux, BSD, SVR4 and Mach
• Single/Multi-processor
• Resource management
• Focus on Real-Time design and implementation
• Performance and predictability issues
• Resource scheduling and managing concurrency

9
Course Topics

• Conventional Systems
• Process and Kernel Model
• Threads, MicroKernel, Multiprocessors
• Synchronization and Inter-Process Communication
• File Systems, Memory Management and Virtual
  Memory
• Communications, Networking and I/O
• Real-Time scheduling, reclaiming and reliability
• Clock Driven, Priority Driven -
• periodic, aperiodic and sproadic tasks
• Non-Processor resources and access control
• if time allows, multiprocessor and dependencies
• Flexible Scheduling, Real-Time Communications
• if time permits, a look at the end-to-end problem

10
Three Driving Concepts

• Abstraction resource abstraction used to manage
  complexity. Low-level computing resources (the
  hardware interface) is abstracted to create an
  extended machine.
• Virtualization Resources are virtualized to
  permit controlled sharing and isolation.
• Resource management OS ensures applications make
  progress by providing policies and mechanisms
  that enable both implicit and explicit
  allocation. Must not impose undue performance
  penalties while maximizing utilization,
  minimizing overhead, providing fair/predictable
  access to system resources.

11
Functions of an OS

• Resource Management
• Time management - CPU and disk transfer
  scheduling
• Space management - main and secondary storage
  allocation
• Synchronization and deadlock handling - IPC,
  critical section, coordination
• Accounting and status information - resource
  usage tracking
• User Environment - OS layer transforms bare
  hardware machine into higher level abstractions
• Execution environment - process management, file
  manipulation, interrupt handling, I/O operations,
  language.
• Error detection and handling
• Protection and security
• Fault tolerance and failure recovery

12
Design Approaches

• Deal with complexities of modern systems
• Separation of Policies and Mechanisms
• Policies - What should be done
• Mechanisms - How it should be done
• Levin, R., E. Cohen, W. Corwin, F. Pollack and W.
  Wulf, "Policy/Mechanism Separation in HYDRA,"
  Proceedings of the 5th Symposium on Principles of
  Operating Systems, 1975, pp. 132-140.
• Three common approaches
• Layered Approach
• Kernel Approach
• Virtual Machine Approach

13
Layered Approach

• Simplifies design, implementation and testing
• Modular by dividing OS into functional layers.
• References
• Dijkstra, E. W., "The Structure of THE
  Multiprogramming System", Communications of the
  ACM, May 1968, pp. 341-346.
• (Ring) Organick, E., The Multics System, MIT
  Press, Cambridge, MA. 1972.

environment
resource
HW
14
Kernel Based Approach

• Kernel contains a collection of primitives which
  are used to build the OS
• OS implements policy, Kernel implements
  mechanisms
• References
• Brinch Hansen, P., "The Nucleus of a
  Multiprogramming System", Communications of the
  ACM, Apr. 1970, pp. 238-241.
• Wulf, W., E. Cohen, W. Corwin, A. Jones, R.
  Levin, C. Pierson, and F. Pollack, "HYDRA The
  Kernel of a Multiprocessor Operating System",
  Communications of the ACM, June 1974, pp. 337-345.

User Apps
Sys Services
User Applications
kernel (privileged)
kernel-user interface
kernel (privileged)
kernel-user interface
hw-sw interface
hw-sw interface
hardware
hardware
15
Virtual Machine Approach

• Virtual software layer over hardware
• Illusion of multiple instances of hardware
• Supports multiple instances of OSs
• References
• Seawright, L., and R. MacKinnon, "VM/370 - A
  Study of Multiplicity and Usefulness", IBM
  Systems Journal, 1979, pp. 4-17.

16
Standard Abstractions and Resources
Processor
System Bus
Secondary Storage
Primary Memory
I/O Device
I/O Device
I/O Device
I/O Device

• Operating systems are extensions of the computer
  system upon which they run.
• The above figure shows a simple computer model
• Common abstractions and models
• Process model represent and manage resource
  access (sharing and isolation), resource
  ownership (open files, etc), program state (data)
  and execution context (threads). Models a running
  program.
• Memory model manage the shared memory resource.
  Instructions and data reside in main memory and
  are accessed there by the CPU.
• File systems high-level abstraction of disk I/O
• Device I/O network, keyboards, low-level disk,
  tapes, CDs, etc.
• Protection and Security

17
Examples of where you will find OSes

• Servers specialized for processing large
  volumes of requests for a given service.
  Generally has a large number of necessary
  resources.
• web server, file server, print server,
  time-sharing systems for interactive use,
  database management systems.
• Desktops specialized for single-user (or limited
  number of users).
• Generally has a GUI that is integral to system
  software
• designed to minimize response time to user
  requests
• Embedded systems specialized for managing a
  limited number of resources such as power,
  memory, I/O speed.
• PDAs, cell phones, smart cards, automobiles.
• Real-time systems Specialized systems that must
  meet stringent performance and behavior
  requirements.
• The goal is to bound worst-case behavior
• Medical devices, avionic systems, multi-media
  players, routers.

18
Multiple Processor Systems

• Shared-memory multiprocessors All processors
  share the same global memory space and
  communicate through it.
• Tightly-coupled.
• Message-passing multicomputer (Clusters)
  Computers are interconnected by a high-speed
  interconnection fabric. Each processor has its
  own local memory and they communicate using the
  interconnect.
• May share secondary storage.
• Loosely coupled.
• Distributed systems Each node is separate,
  standalone computer and the message delay times
  over a WAN can reach 100s of msecs.
• Loosely coupled

19
Why are we looking at UNIX?

• Historical significance
• Advanced features developed for or ported to UNIX
• Availability of source code and research papers
• Importance to present and future research
  activities at WashU
• Highlights key design and architectural issues

20
Traditional UNIX kernel

• Bloated kernel
• Inflexible supported single type of
• file system,
• process scheduling
• executable file format
• References
• D. M. Ritchie, and K. Thompson, The UNIX
  Time-Sharing System, Communications of the ACM,
  Vol. 17, No. 7, Jul. 1974, pp. 365-375.
• (just for fun) D. Milojicic, B. Bolosky, et al.
  "Operating Systems - Now and in the Future", IEEE
  Concurrency, 7(1)12-21, January-March 1999

21
Designing and Building Systems

• See class handout