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 [phone]
• 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)