Operating Systems - PowerPoint PPT Presentation

Loading...

PPT – Operating Systems PowerPoint presentation | free to view - id: 1f7b39-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Operating Systems

Description:

A. Tanenbaum: Modern Operating Systems, Prentice-Hall, 2nd Edition, 2001 ... Operating Systems History. Computer hardware evolved in 4 steps: ... – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 80
Provided by: dramnon5
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Operating Systems


1
Operating Systems
  • Prof. Ehud Gudes
  • Office hours Monday - 14.30 - 16.00
  • Thursday 16.00 18.00
  • Office building 58, 303
  • Tel 08-6461626
  • Email ehud_at_cs.bgu.ac.il

2
Operating Systems
  • Amnon Meisels
  • Office Hrs (314) Monday 1000-1200
  • am_at_cs.bgu.ac.il os002/

3
Operating Systems (OS) - Syllabus
  • 1. Introduction - History Views Concepts
    Structure
  • 2. Process Management - Processes State
    Resources Threads Scheduling Unix
    implementation of Processes
  • 3. Process Synchronization - Synchronization
    primitives and their equivalence Deadlocks
  • 4. File Systems - Implementation Directory and
    space management Unix file system Distributed
    file systems (NFS)
  • 5. Memory Management - Virtual memory Page
    replacement algorithms Segmentation

4
OS - Syllabus (Contd.)
  • 6. Security - General policies and mechanisms
    examples of common problems protection models
    authentication
  • 7. Input/Output - Interrupts Drivers Disks
  • 8. Distributed Systems - Inter Process
    Communication Remote procedures
  • A. Tanenbaum Modern Operating Systems,
    Prentice-Hall, 2nd Edition, 2001
  • A. Silbetschatz et. al. Operating System
    Concepts (6th ed.), Addison Wesley,2001.
  • G. Nutt Operating Systems (a modern perspective)
    (2nd ed.), Addison Wesley, 1999.
  • W. Stallings Operating Systems (3rd ed.),
    Prentice-Hall, 1998.

5
Assignments and Grades
6
Introduction
  • Why do we need an operating system ?
  • Basis for all software
  • Simplifies access (for user processes) to
  • Memory
  • Permanent Data
  • i/o extended machine
  • Security and Protection
  • of executing user programs
  • of resources (devices)

7
Layered Hardware-Software Machine Model
8
What is an Operating System ?
  • The two Views of an Operating System
  • Top-down View
  • An Extended Machine
  • Bottom-up View
  • A Resource Manager

9
Operating Systems - Extended Machines
  • Problems
  • Bare machine has a complex structure
  • Processors
  • Many Devices
  • Primitive Instruction Set
  • Different for Different Machines
  • Solutions provided by the OS
  • Simple, easier to use interface
    (machine-independent)
  • Hiding of unnecessary details

10
Operating Systems as Resource Managers
  • Many Resources
  • Processors Memory
  • Disks Tapes Printers
  • Network interfaces Terminals
  • Controlled allocation of Resources among
  • Users Programs Processors
  • Control means sharing/multiplexing, monitoring,
    protection, report/payment

11
History of Operating Systems
  • First generation 1945 - 1955
  • vacuum tubes, plug boards
  • Second generation 1955 - 1965
  • transistors, batch systems
  • Third generation 1965 1980
  • ICs and multiprogramming
  • Fourth generation 1980 present
  • personal computers
  • Networks and the Internet

12
Operating Systems History
  • Computer hardware evolved in 4 steps
  • Vacuum tubes Plug boards (1945-1955)
  • One user per machine --gt User as Operator
  • Early Software - Assemblers, compilers,
    Libraries of common subroutines, Device drivers
  • Secure
  • Inefficient use -
  • low CPU utilization
  • Significant set-up time
  • No concept of an Operating System

13
History of Operating Systems
  • Early batch system
  • bring cards to 1401
  • read cards to tape
  • put tape on 7094 which does computing
  • put tape on 1401 which prints output

14
History of Operating Systems
  • Structure of a typical job 2nd generation - JCL

15
B. Batch systems - Transistors (1955-1965)
  • Cards into card readers
  • Batch similar jobs (to save on set-up time)
  • Transferring control automatically, from one
    batch job to another --gt a rudimentary OS
  • Job Control Language (JCL)
  • Program LOAD RUN Data EOF.
  • Resident monitor (user ? operator)
  • Initial control in monitor
  • transfers control to job
  • upon completion, control transfers back to
    monitor

16
C. Multiprogramming - Integrated Circuits
(1965-1980)
  • Several programs reside on disk (and in memory)
    at the same time

Job_1
Memory Partitions
Job_2

Job_9
Operating System
17
Multiprogramming Why how its possible?
  • CPU much faster than I/O
  • Memory large enough (512K!)
  • requires protection!
  • Scheduler which manages flow of jobs in and out
  • and shares CPU between jobs requires
    Timer
  • Spooler which takes care of slow I/O (e.g.
    printing).

18
Computer Hardware Review
Monitor
Bus
  • Components of a simple personal computer

19
Computer Hardware Review
  • Typical memory hierarchy
  • numbers shown are rough approximations

20
Computer Hardware Review
  • Structure of a disk drive

21
Computer Hardware Review
(a)
(b)
  • (a) Steps in starting an I/O device and getting
    interrupt
  • (b) How the CPU is interrupted

22
Memory Protection
  • Minimal protection must include the interrupt
    vector and service routines
  • General memory protection can use two registers
    -
  • base register - smallest legal address
  • limit register - size
  • memory outside the range is protected
  • Hardware performs these checks in all user-mode
    memory references
  • The load instructions for the two registers are
    privileged
  • In supervisor mode the OS has unrestricted
    access to all memory

23
Memory Protection
24
Memory protection (Cont.)
  • One base-limit pair and two base-limit pairs

25
User mode lt--gt Privileged mode (I/o)
  • All I/o instructions are privileged instructions
  • I/o devices and cpu can execute concurrently
  • cpu moves data main memory --gt buffers of
    device controllers
  • I/o itself is from device to controllers buffer
  • Device controllers interrupt upon completion
  • Interrupts or Traps enable mode switching..
  • control to interrupt service routine (interrupt
    vector)
  • Architecture saves address of interrupted
    instruction
  • Operating systems are interrupt-driven

26
Timer
  • Timer - interrupts computer after specified
    period, to ensure OS maintains control
  • timer is decremented every clock tick
  • when timer reaches zero, an interrupt occurs
  • timer is set whenever control is transferred to
    user processes (or any process..)
  • timer is mainly used to implement time-sharing or
    multiprocessing
  • load-timer is a privileged instruction

27
Interrupts part of fetch-and-execute
  • While (halt flag not set during execution) /
    every fetch-and-execute/ IR
    memoryPCexecute(IR)PCIf(Interrupt_Reques
    t) memory0 PC PC memory1
  • Interrupt handlers loop over all device numbers
    and call the device_handler for which a flag done
    is raised
  • The interrupt handling routine uses a
    disable_interrupts instruction to avoid losing
    data while processing an interrupt request
  • Hardware may lose queuing interrupts, when the
    Interrupt_Disabled flag is raised and an
    interrupt occurs

28
(No Transcript)
29
History of Operating Systems
  • Multiprogramming systems
  • three jobs in memory 3rd generation

30
C. Multiprogramming - Issues
  • Protect user programs from each other and OS
    from User programs
  • Schedule CPU between jobs
  • Schedule I/O between jobs
  • Avoid concurrent access to exclusive devices (e.g
    Printer)
  • Control job flow into and out the system

31
C. Multiprogramming (Contnd.)
  • I/o routines supplied by the system - device
    allocation
  • Memory management - allocate memory among jobs
  • Processes contend for CPU time - cpu scheduling
  • Spooling (Simultaneous Peripheral Operations On
    Line)
  • Timesharing i.e. Terminals - jobs kept in
    memory and on disk control statements issued
    by user (keyboard)
  • On-line file system is needed, for users access
    to data
  • Examples CTSS Multics Unix.

32
Multics(beg. Of 70s) - Innovations
  • Programmed in high-level language PL/I
  • Time-sharing via terminals
  • Virtual memory including Segmentation paging
  • Files as segments
  • Strong emphasis on protection including
    protection rings and segment descriptors

33
Unix (middle of 70s) - Innovations
  • First OS on a mini-computer (PDP-11 by Dec)
  • High-level language (C )
  • Hierarchical file system
  • Powerful and convenient shell
  • Standard interface to OS via C system calls
  • Unification of many concepts via files (e.g.
    devices, pipes, etc.)
  • Protection? forget it! Convenience was more
    important! (fixed over the years).

34
D. VLSI and personal computers (1980-
  • Machine per user
  • I/o devices - keyboards, displays, mice,
    printers
  • Friendly operating software
  • Examples Unix (here too ?) Windows-NT
  • Parallel (multiprocessor) systems shared
    memory symmetric processing - same OS (no
    master)
  • Networks (distribution)
  • Distributed file systems - shared among many
    systems
  • Network operating systems - protection for
    simple OSs
  • Distributed operating systems - distribute
    computation among several machines/processors

35
Processes - a central concept
  • Programs in Execution
  • Timesharing -
  • Process Suspension
  • Process Table
  • Core image
  • Process Tree
  • Signals
  • Uids - Protection...

36
Operating System Concepts
  • A process tree
  • A created two child processes, B and C
  • B created three child processes, D, E, and F

37
Operating System Concepts
  • Two processes connected by a pipe

38
Files non volatile data
  • File types and operations on files
  • Directories - hierarchical structure
  • Working directories

39
Files non volatile data (cont.)
  • Protection and Security
  • Unix - user group other (rwx bits)
  • File descriptors (handles)
  • i/o as a special file
  • Block Character special files
  • Standard input output error the idea of Late
    binding
  • Pipes

40
Operating system concepts System calls
  • An interface from privileged or system mode to
    user mode (user programs)
  • System calls
  • create, delete, use various objects
  • Examples (Unix)
  • fdopen(file_name, mode)
  • close(fd) kill(pid,sig) fork()

41
A word on System Calls
  • Look like standard procedure calls
  • put parameters in Registers and TRAP
  • operation is performed in privileged mode
  • some system calls can be accessed through the
    command interpreter (Shell)
  • redirection gt
  • pipe
  • Do not wait for offspring process

42
Steps in Making a System Call
  • There are 11 steps in making the system call
  • read (fd, buffer, nbytes)

43
Some System Calls For Process Management
44
Some System Calls For File Management
45
Some System Calls For Directory Management
46
Some System Calls For Miscellaneous Tasks
47
System Calls
  • Some Win32 API calls

48
The Shell Commands Language
  • sort lt file1 gt file2
  • cat file1 sort lpr
  • The Shell is a process which executes its
    commands as offspring processes
  • Processes may call shell commands by using the
    system system call

49
Shell structureParent child
  • A stripped down shell
  • while (TRUE) / repeat forever /
  • type_prompt( ) / display prompt /
  • read_command (command, parameters) / input
    from terminal /
  • if (fork() ! 0) / fork off child process
    /
  • / Parent code /
  • waitpid( -1, status, 0) / wait for
    child to exit /
  • else
  • / Child code /
  • execve (command, parameters, 0) / execute
    command /

50
Initializing a (user) shell
  • The init program runs getty on all ports
  • Detecting a terminal getty runs login
  • Typing in a user name and a password login
    checks the passwd file and if correct runs a
    shell the one specified in the UID entry
  • The shell is run with that user ID environment
    parameters
  • The user process runs the shell

51
Running user commands
  • User types grep some_word file_name
  • Shell parses the command, inserts the strings
    grep, some_word, file_name into argv and argc
  • Next, the shell uses fork() to create a process
    (same user ID)
  • Now, it takes the executable name grep and the
    arguments, all from argv, and uses execve() or
    similar system calls to run the grep executable
  • Normally the shell uses the wait() system call to
    be rerun after grep exits one user process
    running

52
OS - Main Components
  • Process management
  • process creation deletion suspension
  • process synchronization communication
  • Main-memory management
  • Manage used parts and their current users
  • Select processes to load
  • Allocate memory to running processes
  • Secondary storage management
  • Free-space management
  • Storage allocation

53
OS - Main Components (cont.)
  • File system management
  • File directory creation deletion
  • File manipulation primitives
  • Mapping files onto secondary storage
  • I/o system management
  • general device-driver interface
  • Drivers for specific hardware devices
  • Protection system
  • Distinguish between authorized and unauthorized
    usage
  • Provide means of enforcement

54
OS - Main Components (cont.)
  • Networking
  • A distributed system is a collection of
    processors that do not share memory or a clock
  • The processors are connected through a
    communication network
  • Provides user access to various system resources
  • Command-interpreter System
  • control statements that deal with process
    creation and management I/o handling
    file-system access protection networking
  • The program that reads and interprets - shell (in
    Unix)

55
Operating system structure
  • Monolithic systems have little structure

Service Routines
Utility procedures
56
Operating System Structure
  • Structure of the THE operating system

57
Virtual Machines
  • The extreme layered approach
  • Provide an interface identical to the underlying
    bare machine
  • OS creates multiple processes, each executing on
    its own processor and own (virtual) memory
  • Virtual machines provide complete protection of
    system resources - even separate resources
  • Difficult to implement, due to the effort
    required to provide an exact duplicate of the
    underlying machine
  • Recent use run MS-DOS on top of Windows

58
Virtual Machines
59
Virtual Machines
  • Virtual machine monitors for operating systems

System call
System call
CMS
Trapped
CMS
CMS
VM/370
Trapped
370 Bare Hardware
60
Client-Server Model
Memory Server
File Server
Client Process
. . . . . .
Client Process
Kernel
Machine4
Machine3
Machine1
Machine2
Client
File Server
Process Server
. . . .
. . .
Kernel
Kernel
Kernel
Kernel
Network
Distributed System
61
Mechanism vs. Policy
  • Simple Kernel - modularity minimal privileged
    operation
  • Servers for files, memory, etc. - distribution
    user mode operation
  • good for distributed systems
  • Mechanism in kernel - how to do things..
  • Policy outside - decide what to do can be
    changed later..
  • Another solution Critical servers in kernel

62
Advanced Architectures
  • Multi-processors
  • Parallel Computers
  • Networks and Distributed systems
  • Each of these architectures requires a
    corresponding Operating System

63
  • Fig. 9-5. A bus-based multiprocessor
  • Fig 9-8. (a) Grid. (b) Hypercube.

64
  • Fig. 9-7. A Distributed System consisting of
    workstations on a LAN.
  • Fig 9-1. Advantages of distributed systems over
    centralized ones.

65
Metric Units
The metric prefixes
66
Case Study 1 UNIX and LINUX
Chapter 10
10.1 History of unix 10.2 Overview of unix 10.3
Processes in unix 10.4 Memory management in unix
10.5 Input/output in unix 10.6 The unix file
system 10.7 Security in unix
67
UNIX
  • UserInterface

68
UNIX Utility Programs
  • A few of the more common UNIX utility programs
    required by POSIX

69
UNIX Kernel
  • Approximate structure of generic UNIX kernel

70
Case Study 2 Windows 2000
  • Chapter 11

11.1 History of windows 2000 11.2 Programming
windows 2000 11.3 System structure 11.4
Processes and threads in windows 2000 11.5
Memory management 11.6 Input/output in windows
2000 11.7 The windows 2000 file system 11.8
Security in windows 2000 11.9 Caching in windows
2000
71
Windows NT
  • Some differences between Windows 98 and Windows NT

72
Windows 2000 (1)
  • Different versions of Windows 2000

73
Windows 2000 (2)
  • Comparison of some operating system sizes

74
The Maze
0
4
3
2
1
0
monitor
1
queue
2
3
4
monitor
- Treasure-hunter
- Treasure
System
75
The Maze participating elements
  • System module constructs, runs and schedules
    the game-board, the monitor and the
    thread-players in the game.
  • Game Board A flat board containing NN cells
    each one can contain 1 or more treasures or be
    empty. Every cell can be visited by no more than
    one treasure-hunter at a time.
  • Monitor Provides the user an interface for
    monitoring the game. Receives its information
    of the game run from the thread players through a
    bounded buffer queue.
  • Treasure Hunters Thread-players of the game.
    Each of them searches the game board in a random
    matter in order to collect the encapsulated
    treasures.
  • Scheduler Policies The program should be able
    to run two schedule policies, one for a fare game
    and the other for a joined effort game.

76
and in the 1st Assignment ..
  • The system is a set of concurrently executing
    threads, all created by the shell
  • Threads use system calls for actions related
    to resources (send message, acquire treasure,)
  • There is only one independent module in the
    System
  • the Scheduler
  • The rest of system calls are implemented under
    thread control

77
and in the 1st Assignment ..
  • Processes are simulated by threads
  • No process tree, but, the special thread - the
    Shell - creates all other threads
  • The process table is very simplistic, the
    Scheduler keeps track on whos ready
  • Inter process communication is enabled for all
    threads - performed by the Mailer
  • Threads have Ids, essential for the routing

78
and in the 1st Assignment ..
  • System calls are simulated by
  • send(), receive()
  • But, there are all the real system calls
  • suspend(), block(), release()
  • So, the best policy is to let these
    extra-functions be called from the system
    module
  • Remember, the (global) function called is part
    of the thread of control...

79
(No Transcript)
About PowerShow.com