COMP 3713 Operating Systems Slides Part 1 Jim Diamond CAR 409 - - PowerPoint PPT Presentation

COMP 3713 — Operating Systems Slides Part 1

Jim Diamond CAR 409 Jodrey School of Computer Science Acadia University

Acknowledgements These slides borrow from those prepared for “Operating System Concepts” (eighth edition) by Silberschatz, Galvin and Gagne. These slides borrow lightly from those prepared for COMP 3713 by Dr. Darcy Benoit.

Chapter 0

Preliminaries

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 0 1

General Information

• Read course outline at

http://cs.acadiau.ca/~jdiamond/comp3713/comp3713.pdf

• Getting help

– ask questions in class! – my office hours (CAR 409): MWF 8:30–9:30, other times TBA and/or by appointment – these are subject to change! I’ll let you know if they do. – if you need to see me at other times, e-mail or phone me and we can set up a meeting time – the TA contact hours (if desired!) shall be announced RSN

• ANYTHING discussed in class is fair game for assignments and exams

Even if it is not in these slides! – in other words, these slides are not the be-all and end-all of mankind’s knowledge of operating systems – the fine art of taking notes will likely prove profitable

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 0 2

Reference Materials

• Main text: Operating System Concepts by Silberschatz, Galvin and

Gagne (2012, 9th edition) – see also http://codex.cs.yale.edu/avi/os-book/OS9/

errata-dir/os9c-errata.pdf

• Reference: UNIX Systems Programming, by Haviland, Gray and Salama

(1999, 2nd edition) – this should be on reserve in the library RSN

• To refresh your memory of computer architecture: Principles of

Computer Hardware by Alan Clements –

• r any of the many computer architecture books in the library

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 0 3

Background Knowledge

• Writing, compiling and running C programs under Linux

– how to do I/O using printf(), putchar(), getchar(), and so on – how to use command-line arguments

• Basic Linux/Unix information

– using a shell – common useful commands (e.g., ls, cp, mv, rm, ln, diff, man,

grep, mkdir, less, cat, head, tail, . . . )

– knowing how to use a real editor will be useful

• Computer architecture

– cache memory (VERY important) – interrupts – buses (not “busses”) and I/O structures

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 0 4

Course Overview

• Overall structure and purposes of operating systems
• Relationship between OS and hardware

– memory management: real and virtual memory – device management (I/O devices, CPU scheduling, . . . ) – I/O – interrupts

• Relationship between OS and software

– process management; threads; synchronization – system calls – I/O – files and file systems – pipes and other inter-process communication

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1

Introduction

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 5

What (exactly) is an OS?

• A traffic cop?

– direct traffic in an safe, orderly way

• A government?

– provide basic services, but otherwise try to stay out of the way

• There are different view points

– user view – what can the OS do for me? – system view – how can the system hardware be controlled?

• There are different goals

– user: make my life as wonderful as possible, at all costs – system: use system resources efficiently – computer systems used to cost tens of millions of dollars – in such a scenario, you did not want to waste the computer’s precious time

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 6

Abstract View #1 of an OS

• Note that, in general, multiple users may be using the computer

concurrently

• Q: what system(s) do you use which are shared (concurrently) with
• ther users?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 7

Exactly What Makes Up the OS?

• There is no universal agreement

– is the GUI in MS-widnoze part of the OS? – should it be? – how about MS-IE? – should it be? – Not according to the U.S. Dept. of Justice!

• The program which is always running is called the kernel

– many people say this is the OS

• But many OS’s use auxiliary programs called daemons to perform

various functions – these daemons appear and disappear as required – so are they part of the OS?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 8

Types of OS’s, Now and Then: 1

• Originally, computers ran one (batch) program at a time

– wasteful of a hugely expensive resource: the CPU sits idle 70% of the time waiting for I/O

according to studies

• Multiprogramming: allow multiple programs to run concurrently

– while program 1 is waiting for I/O, the CPU may be able to execute program 2

• Time sharing: allow users to directly interact with the computer via

computer terminals

• Workstations, personal computers: (relatively) inexpensive computers

could be allocated for the use of a single person – an OS for such a system might be different than for a mainframe shared by many users (how? why?)

• Parallel systems: have more than one CPU (or ALU!) inside a system to

increase performance AND utilization of the rest of the system – symmetric vs. asymmetric (master-slave) multiprocessing

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 9

Types of OS’s, Now and Then: 2

• Distributed systems: systems made up computers which are not

necessarily co-located

• Real-time systems

– used where a response to an event should/must be completed by a certain time – (sub)types: soft real-time and hard real-time – soft: if response is not in time, the results are not catastrophic – airline reservation system (annoyed customers) – digital audio recording (drop-outs) – hard: Bad Things may happen if results are not performed in time – airliner auto-land system – self-defence systems on military platforms – medical devices (read safety-critical.html) – (some) robotic systems (e.g., surgery assistant robots) – hard real-time systems are usually not “general-purpose” systems

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 10

System Boot

• Operating system must be made available to hardware so hardware can

start it – a small piece of code, the bootstrap loader, locates the kernel, loads it into memory, and starts it – sometimes it is a two-step process, where the boot block, at some fixed location, has the code to load a bootstrap loader – when power is initialized on the system, execution starts at a fixed memory location – firmware is used to hold initial boot code

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 11

The OS as a Resource Manager

• For a single-program batch system, the OS had little to do

– load a program and start it – “talk” to I/O devices – clean up when a program finishes

• Time-sharing: much more complex

– divide the memory amongst competing programs – enforce protection: one program shouldn’t be able to clobber another (really the “traffic cop” duty) – share the resources fairly – allow all tasks to receive some CPU time, but. . . – give higher CPU priority to interactive tasks than to batch tasks – enforce limits on mass storage devices – provide facilities to allow multiple tasks to use devices which are inherently single-user at a time (e.g., printers) –

. . .

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 12

The OS as a Traffic Cop

• The computer system should prevent a rogue program from

– crashing the system or other programs, or – accessing resources it shouldn’t access

• How?

– the hardware prevents a program from accessing memory outside its address space

• r so we thought (meltdown, spectre)

– the hardware prevents ordinary programs from doing I/O

• But how?

– hardware protections + dual mode operation:

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 13

Programs and Processes: Terminology

• A program is a passive entity: data in memory or on a storage device
• A process is an active entity

– – resources (CPU, memory, I/O, . . . ) are being used – resources are released when the process terminates

• A single-threaded process has (only) one associated program counter

which points to the next instruction to execute

• A multi-threaded process has one program counter per thread
• A running system usually has many processes running at one time

–

• The OS runs processes concurrently by time slicing the CPU’s (or

CPUs’!) attention amongst runnable processes

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 14

Process Management Activities

• The operating system is responsible for the following activities in

connection with process management: – creating and deleting both user and system processes – scheduling processes and threads (q.v.) on the CPU(s) – – providing mechanisms for process communication – providing mechanisms for process synchronization

• Suspending and resuming (S2R or S2D):

– – useful on laptops and similar systems – the capability to suspend is becoming more common on desktop systems

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 15

Memory Management

• Main memory (RAM) sizes can vary from a few K bytes to many GB

– rapidly decreasing cost allows system designers to assume more and more memory – but power considerations affect some types of systems

• Unlike other devices, memory can be directly addressed and accessed

– compare this to disks, whose information must be loaded into memory before the CPU can access it

• To allow multiple processes to run concurrently, the main memory must

be shared – – facilities to allow programs to share memory regions may be desired – OS must keep track of which memory locations belong to which process(es) and which locations are unused

• The memory address as known to a process must be mapped to a

physical memory address –

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 16

PC Memory (and CPU Speed) Now and Then

• Acadia Advantage 2002 laptop (IBM A20m with Celeron 500):

(IIRC)

disk drive 6,000 MB (that is “marketing-speak” MB) RAM 64 MB CPU 0.5 GHz cache L1: 0.03125 MB, L2: 0.125 MB, L3: 0 MB

• Fujitsu T900 with Core i7 M 620, early 2010:

disk drive 476,940 MB (500 GB in marketing-speak) RAM 8,192 MB CPU 2.67 GHz cache L1: 0.125 MB (2×(32K I + 32K D)), L2: 2×0.25 MB, L3: 4 MB

• Macbook with Core i7-4980HQ, mid 2015 (CPU out in Sept. 2014): https://wikichip.org

flash memory 477,102 MB (also 500 GB in marketing-speak) RAM 16,384 MB CPU 2.80 GHz cache L1: 0.25 MB (4×(32K I + 32K D)), L2: 4×0.25 MB cache L3: 6 MB, L4: 0.125 MB (?!)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 17

Storage Management: 1

• An OS provides an abstract view to storage devices

– e.g., you open a file, and it doesn’t matter whether that is on a PATA disk, a SATA disk, a SCSI disk, a DVD, a USB stick, . . . –

• f course, the access speed changes for each of these, as does total

capacity, but still you just open the file –

• An OS provides file-system management:

– – access control – user ids, group ids, ACLs, . . . – functions to create, modify and delete files and directories – mapping of (logical) file to physical location on disk

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 18

Storage Management: 2

• Disks are used for “permanent” storage of programs and data

–

• Overall system speed is critically dependent on disk subsystem hdparm demo?
• The OS must take care of

– – allocating space – scheduling disk I/O

• nly for non-SSDs?

– wait, not necessarily: modern spinny disks have NCQ

• Not all mass storage need be fast

– the sluggishness of optical drives or the sloth of magnetic tape may be acceptable for some things – still, the OS must manage this

• Magnetic tape: usually seen as a linear data stream (no random access),

but some systems implemented file systems on magtape (“DECtape”)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 19

Storage Hierarchy

Level Name Typical size Implementation technology Access time (ns) Bandwidth (MB/sec) Managed by Backed by 1 registers < 1 KB custom memory with multiple ports CMOS 0.25 - 0.5 20,000 - 100,000 compiler cache 2 cache < 16MB

• n-chip or
• ff-chip

CMOS SRAM 0.5 - 25 5,000 - 10,000 hardware main memory 3 main memory < 64GB CMOS SRAM 80 - 250 1,000 - 5,000

• perating system

disk 4 solid state disk < 1 TB flash memory 25,000 - 50,000 500

• perating system

disk 5 magnetic disk < 10 TB magnetic disk 5,000,000 20 - 150

• perating system

disk or tape

• Data migration:

– but what about multiple copies? (distributed system, multiple caches in multi-CPU/core systems, . . . )

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 20

Protection and Security

• Following textbook terminology:

– protection: any mechanism for controlling access of processes or users to resources defined by the OS – security: defense of the system against internal and external attacks – a huge range, including denial-of-service, worms, viruses, identity theft, theft of service, iCloud boo-boos, . . .

• Systems generally first distinguish among users, to determine who can

do what – user identities (user IDs, security IDs) include name and associated number, one per user – user ID then associated with all files, processes of that user to determine access control – – privilege escalation: allows user to change to an “effective ID” with more rights

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 21

Mobile Computing

• Tablet computers and smartphones
• Initially, these were very much less capable than the personal computers
• f the day

–

• Recent increases in compute power have made these mobile devices

powerful enough for “everyday tasks” – smartphones with large screens (“phablets”) have closed the gap between tablets and phones

• Mobile devices can have useful features missing from regular personal

computers –

• There are OSes (or versions of OSes) specifically for mobile devices
• COMP 2903 topic: privacy is more and more a thing of the past

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 22

Distributed Computing Paradigms

• Client-server

– – OSes must support protocols for communications AND security

• Peer-to-peer

– – a given system might be client, server, or both – peers must have a facility for finding each other – central registry service or “discovery protocol”

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 23

Virtualization and Friends

• Virtual machine idea: allow an OS to run as an “ordinary” program

under another OS – –

• but. . . also useful to run multiple copies of the same OS on a given

piece of hardware – multiple servers listening on the same socket – divide users amongst different client OSes to keep them separate from each other – ensure that no process or user inside one VM can use more than a certain amount of the total CPU time or memory

• Emulation: execute a program designed for computer architecture A on

computer architecture B

• Interpretation: have a program which executes programs in a high-level

language (e.g., shell programs) or in an intermediate level (Java byte code)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 24

Virtual Machines

Non-virtual Virtual

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 1 25

Yet More Computing Paradigms

• Cloud computing: deliver services across a network

– – read section 1.11.7 in the text for (a few) more details

• (Real-time) embedded systems

– – they may run on general purpose computers and/or use a standard OS (e.g., Linux), with programs specific to the monitoring or control task at hand – they may also be running a specialty OS (or no actual OS at all) on special-purpose hardware

• Open Source (read textbook section 1.12)

– MIT gang and DEC User Society (DECUS) were early promotors – Linux, Darwin (core part of OS X), BSD and OpenSolaris are all

• pen source OSes

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2

Operating System Structures

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 26

Chapter 2 Outline

• Operating System Services
• User Operating System Interface
• System Calls
• Types of System Calls
• System Programs
• Operating System Design and Implementation
• Operating System Structure
• Operating System Debugging
• Operating System Generation
• System Boot

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 27

Operating System Services

• User interface: gooey, command-line, or both

– user must have some facility for interacting with the system – is this necessarily true? E.g., embedded system in parking meter

• Program execution:

– – execute it – clean up when it is done –

• I/O operations: files and I/O devices
• File system manipulation

– – list file “meta” information (perms, modification date/time, . . . ) – manage permissions

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 28

OS Service Overview

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 29

System Calls

• Programming interface to the services provided by the OS
• Typically written in a high-level language (C or C++)
• Textbook says “Most programmers never see this level of detail,
• however. Typically, application developers design programs according to

an application programming interface (API).” – – what if you write a C program which uses open() instead of

fopen(), read() and write() instead of the stdio functions (like scanf() and printf()), and so on?

Or is he talking about ioctl()s?

– Unix: “man 2 <something>” vs. “man 3 <something>”

• The three most common APIs are W32 API for Windows, POSIX API

for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and Java API for the Java virtual machine (JVM)

• Q: Why should you use APIs rather than system calls?

–

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 30

Sample System Call Use (Whether You Realize It or Not)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 31

System Call Implementation

• Typically, an index number is associated with each system call
• The system-call interface maintains a table indexed according to these

numbers

• The system call interface invokes the intended system call in the OS

kernel and returns the system call status and any return values

• The caller need know nothing about how the system call is implemented

– – most details of the OS interface are hidden from the programmer by the API – details are managed by run-time support library (set of functions built into libraries included with compiler)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 32

System Call — OS Relationship

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 33

API — System Call — OS Relationship

#include <stdio.h> int main() { ... |<----- printf("Blah blah blah\n"); | ... | } | |--------> C library (libc) write()

• ---->|

| user mode |

• ---------------------------------------------+------------

kernel mode | | | kernel write() implementation <--------|

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 34

Syscall Parameter Passing

• Often, more information is required than simply the identity of the

desired system call –

• Three general methods used to pass parameters to the OS

– – but there may be more parameters than registers – parameters are stored in a block (or table) in memory, and the address of the block is passed as a parameter in a register – – parameters are pushed onto the stack by the program and popped

• ff the stack by the operating system
• Note: the block and stack methods do not limit the number or length of

parameters being passed (within reason)

• Historically, you needed to write assembly language to do system calls

– since C (and maybe before) access to syscalls has been available in (some) high-level languages – but not Java, oh no!

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 35

Syscall Parameter Passing via Table

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 36

Types of System Calls

• Process control

–

• File management

– create, delete, open and close files

• Device management

– request, release and control devices

• Information maintenance

–

• Communications

– create pipes or other facilities for processes to communicate – send, receive messages

• Protection

–

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 37

Sample System Calls

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 38

System Programs: 1

• System programs provide a convenient environment for program

development and execution. They can be divided into: – – status information – file modification – – program loading and execution – communications – – system services (daemons, servers, . . . )

• Most users’ view of the operation system is defined by system programs,

not the actual system calls

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 39

System Programs: 2

• Provide a convenient environment for program development and

execution – some of them are simply user interfaces to system calls; others are considerably more complex

• File management: create, delete, copy, rename, print, dump, list, and

generally manipulate files and directories

• Status information

– some ask the system for info: date, time, amount of available memory, disk space, number of users –

• thers provide detailed performance, logging, and debugging

information – – some systems implement a registry: used to store and retrieve configuration information

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 40

System Programs: 3

• File modification

– – special commands to search contents of files or perform transformations of the text

• Programming-language support: compilers, assemblers, debuggers and

interpreters are sometimes provided

• Program loading and execution: absolute loaders, relocatable loaders,

linkage editors, and overlay-loaders, debugging systems for higher-level and machine language

• Communications: provide the mechanism for creating virtual

connections among processes, users, and computer systems – allow users to send messages to one another’s screens, browse web pages, send electronic-mail messages, log in remotely, transfer files from one machine to another, . . .

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 41

Operating System Design and Implementation: 1

• Design and implementation of OS not “solvable”

, but some approaches have proven successful

• The internal structure of different operating systems can vary widely
• Start by defining goals and specifications
• Affected by choice of hardware, type of system (somewhat)
• Must consider both user goals and system goals

– – system goals: operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient

• Easily upgradeable? Scalable?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 42

Operating System Design and Implementation: 2

• One important principle: separate

Policy: What will be done? from Mechanism: How to do it?

• Mechanisms determine how to do something, policies decide what will

be done – the separation of policy from mechanism is a very important principle; it allows maximum flexibility if policy decisions are to be changed later

• Q: is this any different than any other (large) program?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 43

Simple (Simplistic?) Structure: Messy-DOS

• Goal: provide the most functionality in the least space

– – interfaces and levels are not well separated – “user-land”programs can do I/O! –

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 44

Traditional Unix Structure

• Just two layers (sort of): if new h/w introduced, significant kernel

changes could be required

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 45

More Layers, Using the Sexy Round Diagram

• (Is this really any different than multiple layers drawn horizontally?)
• System is designed using top-down approach, with well-defined and

controlled interactions between the layers – – any given layer only uses features of lower layers – easier to initially develop and debug – – problem: hard to make this design efficient

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 46

Another Approach: Microkernels

• Idea: move as much as possible from the kernel into “user space”
• Communication takes place between user modules using message

passing

• Benefits:

– – easier to port the operating system to new architectures – (there is less code in the kernel which “knows” about h/w) – – more reliable (less code is running in kernel mode) – (but then system software has to be more secure and reliable!)

• Detriments:

– performance overhead of user space to kernel space communication

• Used (sort of kinda) in Mac OS X, ’Doze NT, some versions of Unix

(including, interestingly, the real-time system QNX)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 47

Modules

• Most modern operating systems implement kernel modules

Linux: lsmod

– – each core component is separate – each talks to the others over known interfaces –

• The kernel itself must contain some essential services (such as the

ability to load a module)

• Overall, (somewhat) similar to layers but more flexible
• If you ever compile your own Linux kernel, you will see that a huge

number of features can be implemented as modules, rather than permanently compiled into your kernel – kernels for “generic” hardware (such as those found on live CDs) would be too big if every last device driver and feature was compiled into the kernel – instead, a relatively minimal kernel starts running (on boot) and then loads required modules

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 2 48

Solaris Modular Approach

• Use lsmod command in Linux to see what modules you have loaded

– – but a kernel with every possible module compiled in would be huge

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3

Processes

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 49

Overview

• Process Concept
• Process Scheduling
• Operations on Processes
• Interprocess Communication
• Examples of IPC Systems
• Communication in Client-Server Systems

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 50

Process Concept

• An operating system executes a variety of programs:

– – time-shared systems — user programs or “tasks”

• The textbook uses the terms job and process almost interchangeably
• Process — a program in execution; process execution must progress in

a sequential fashion –

• A process includes:

– – stack – data section

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 51

Process Layout in Memory

• The word text refers to the

executable instructions in the process

• Note how the heap and stack grow

towards each other into the “free” address space

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 52

Process State

• As a process executes, it changes state

– – running: instructions are being executed – waiting: the process is waiting for some event to occur – – terminated: the process has finished execution

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 53

Process State Changes

• What about “ready” −

→ “terminated” ?

–

• Logically, can these happen?

– related Q: do zombies actually exist?

See the ps man page

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 54

Process Control Block (PCB)

• Information associated with each process:

– – program counter – CPU registers – – memory-management information – accounting information –

• This CPU register information must be stored somewhere other than

the CPU registers when some other process has the CPU

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 55

Process Control Block (PCB)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 56

Switching from one Process to Another

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 57

Process Scheduling Queues

• Job queue: set of all processes in the system
• Ready queue: set of all processes residing in main memory, ready and

waiting to execute

• Device queues: set of processes waiting for an I/O device
• Processes migrate among the various queues

– – is this an abuse of terminology (“queue”)?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 58

Ready and Device Queues

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 59

Process Scheduling

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 60

Scheduling Strategies

• One can take a short-term, medium-term, or long-term view to process

scheduling

• Long term (“job”) scheduler: which process(es) should be brought into

the ready queue – e.g., in a batch system some processes may wait minutes/hours on disk before they are considered for execution

• Short term (“CPU”) scheduler: which process (from the ready queue)

should be executed next – in a time-sharing system, interactive users are normally given high scheduling priority – a quick response is desired to hitting the “Enter” key –

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 61

Scheduler Criteria

• Short-term scheduler is invoked very frequently (milliseconds)

–

• Long-term scheduler is invoked very infrequently (seconds, minutes)

–

• The long-term scheduler controls the degree of multiprogramming
• Processes can be described as either:

– I/O-bound: spends more time doing I/O than computations, many short CPU “bursts” – CPU-bound: spends more time doing computations; long CPU bursts

• Short term scheduling:

– usually I/O-bound processes are chosen ahead of CPU-bound processes – an I/O-bound process won’t run for long, thus the CPU-bound process will soon gets its turn

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 62

Medium Term Scheduling

• It is possible that more processes have been started than can

simultaneously fit in main memory – – need to get them running at some point

• Add that idea in:

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 63

Context Switching

• When the CPU switches to another process, the system must save the

state of the old process and load the saved state for the new process via a context switch

• The context of a process is saved in the PCB
• Context-switch time is overhead; the system does no useful work while

switching

• The time required is (partially) dependent on hardware support

– e.g., if an architecture has multiple sets of CPU registers, it might be possible to leave a process’ registers alone and switch to another register set for the next process

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 64

Process Creation: 1

• Generally, processes are identified and managed via their process

identifier (pid) –

• A parent process creates children processes, which, in turn create other

processes, forming a tree of processes (try ps fax on Linux)

• Resource sharing possibilities:

– – children share a subset of parent’s resources – parent and child share no resources

• Execution possibilities:

– – parent waits until child(ren) terminate(s)

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 65

Process Creation: 2

• Address space possibilities

– – child has a program loaded into it

• UNIX examples

– – the child process’ memory image is almost identical to that of the parent –

exec() system call is used (usually after a fork()) to replace the

process’ memory space with another program

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 66

C Program ❢♦r❦✭✮ing A New Process

int main() /* #include’ s off the top of the screen */ { pid_t pid; /* fork another process */ pid = fork(); if (pid < 0) // Testing "< 0" is more robust than "== -1" { /* An error occurred */ fprintf(stderr, "fork() Failed\n"); exit(-1); } else if (pid == 0) { /* child process */ execlp("/bin/ls", "ls", NULL); /* Should NOT get here!! Print error message, ... */ } else { /* This is the parent process */ /* The parent will wait for the child to complete */ wait(NULL); printf("Child Complete\n"); } exit(0); }

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 67

Process Termination

• Process executes its last statement and asks the operating system to

delete it (exit()) – (Unix systems) send exit status from child to parent (via wait()) – the process’ resources are then deallocated by the operating system

• A parent may choose to terminate execution of child processes (abort)

– – task assigned to child is no longer required – if parent is exiting – some operating system do not allow child to continue if its parent terminates –

. . . all children terminated: cascading termination

• in Unix, a HUP signal sent to a process is also propagated to that

process’ descendants† –

† not the whole truth

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 68

Cooperating Processes

• An independent process cannot affect or be affected by the execution
• f another process

– – in reality: – OS bugs may allow one program to affect another –

• ne process could hog hardware resources (CPU, memory,

I/O bandwidth, and so on)

• A cooperating process can affect or be affected by the execution of

another process – that is, the actions of one process may affect the actions carried out by another process (and vice versa) –

• f course, by using the word “cooperating” we assume that the two

(or more) cooperating processes interact in such a way as to benefit the overall operation of some system

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 69

Interprocess Communication (IPC)

• As mentioned:

– – cooperating process can affect or be affected by other processes

• Reasons for using cooperating processes:

– – computation speedup – modularity –

• For processes to cooperate, they must be able to communicate

somehow

• There are two standard models of IPC:

– – message passing (each message requires system calls!) – but, depending on the architecture (e.g., multi-core machines; see text) message passing may be faster!

cache coherency issues!

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 70

IPC Models

Message Passing Shared memory

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 71

A Common Situation: The Producer-Consumer Problem

• A very well-known paradigm for cooperating processes:

– a producer process produces information that is consumed by a consumer process – examples?

• Two models:

– unbounded-buffer places no practical limit on the size of the buffer – sender will never block trying to send – bounded-buffer assumes that there is a fixed buffer size –

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 72

Bounded-Buffer/Shared-Memory Solution

• Consider the following data in a shared memory region

#define BUFFER_SIZE 10 typedef struct { . . . data declarations . . . } item_T; item_T buffer[BUFFER_SIZE]; int in = 0; int out = 0;

• Use this as a “circular” buffer:

– –

• ut points to next available data in buffer

– buffer full/empty rules: – –

(in + 1) % BUFFER_SIZE == out ⇒ buffer is full

• This empty/full specification is self-consistent, but only allows the use
• f BUFFER_SIZE - 1 elements

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 73

Bounded Buffer: Consumer Procedure

while (true) { while (in == out) ; /* Nothing to consume: spin while waiting */ /* Remove an item from the buffer */ new_item = buffer[out];

• ut = (out + 1) % BUFFER SIZE;

/* * Use "new_item" here somehow */ ... }

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 74

Bounded-Buffer: Producer Procedure

while (true) { /* * Produce a new item_T "new_item" somehow right here */ new_item = make_item(args); /* Ensure there is space in the buffer */ while ((in + 1) % BUFFER_SIZE == out) ; /* No free buffer: spin your wheels! */ /* There is now available space: insert the new item */ buffer[in] = new_item; in = (in + 1) % BUFFER_SIZE; }

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 75

Interprocess Communication: Message Passing

• Message passing is a mechanism for processes to communicate and to

synchronize their actions – processes communicate with each other without resorting to shared variables – note: these processes don’t have to be on the same computer

• An IPC facility provides two operations:

– –

receive(message)

• If P and Q wish to communicate, they need to:

– – exchange messages via send() and receive()

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 76

Implementation Questions

• How are links established?
• Can a link be associated with more than two processes?
• How many links can there be between every pair of communicating

processes?

• What is the capacity of a link?
• Is the size of a message that the link can accommodate fixed or

variable?

• Is a link unidirectional or bi-directional?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 77

Message Passing: Direct Communication

• Processes must name each other explicitly:

– –

receive(Q, message): receive a message from process Q

• Properties of communication link

– – a link is associated with exactly one pair of communicating processes – between each pair there exists exactly one link – the link may be unidirectional, but is usually bi-directional

• Variation: allow receive(&id, message)

– – the id argument is set to the id of the process from which the message was received

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 78

Message Passing: Indirect Communication

• Messages are directed and received from mailboxes (also referred to as

“ports”) – – processes can communicate only if they share a mailbox

• Properties of communication link

– a link is established only if processes share a common mailbox – a link may be associated with many processes – each pair of processes may share several communication links –

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 79

Indirect Communication: 2

• Operations

– – send and receive messages through a mailbox – destroy a mailbox

• Primitives are defined as:

– –

receive(A, message): receive a message from mailbox A

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 80

Indirect Communication: 3

• Mailbox sharing issue

– suppose P1, P2 and P3 share mailbox A – suppose then P1 sends; P2 and P3 receive (e.g., P1 could be a producer feeding consumers P2 and P3)

• Q: who gets the message?
• Solutions

– – allow only one process at a time to execute a receive() operation – allow the system to arbitrarily select the receiver; the sender is notified who the receiver was

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 81

Synchronization

• Message passing may be either blocking or non-blocking
• Blocking is considered to be synchronous

– blocking send: the sender blocks until the message is received – blocking receive: the receiver blocks until a message is available

• Non-blocking is considered to be asynchronous

– – non-blocking receive: the receiver receives a valid message or NULL

• Both of these techniques have their place

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 82

Buffering of Messages

• A queue of messages is attached to the link
• This can be implemented in one of three ways:

– Zero capacity: 0 messages can be in the queue

⇒ Sender must wait for receiver (“rendezvous”)

– Bounded capacity: finite length of n messages

⇒ Sender must wait if link is full

–

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 83

Examples of IPC Systems — POSIX

• POSIX shared memory operations
• First, a process creates (gets?) a shared memory segment:

shmid = shmget(IPC_PRIVATE, size, S_IRUSR | S_IWUSR);

• A process wanting access to that shared memory must attach to it:

shared_memory = (char *)shmat(shmid, NULL, 0);

• Now the process could write to the shared memory:

sprintf(shared_memory, "Writing to shared memory");

• When done, a process can detach the shared memory from its address

space:

shmdt(shared_memory);

• GEQ: how is orderly communication between the cooperating processes

managed in this case?

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 84

Pipes: 1

• A simple mechanism for processes on the same machine to communicate
• Two types: ordinary (unnamed) pipes and named pipes
• Ordinary pipes are unidirectional

– – if bidirectional communication is needed, use two pipes

• Sketch of some code for parent ⇒ child communication

int main() { int fd[2]; pid_t pid; if (pipe(fd) == -1) { /* handle this error */ } pid = fork(); if (pid > 0) /* parent */ { close(fd[0]); /* read end */ write(fd[1], ...); } if (pid == 0) /* child */ { close(fd[1]); /* write end */ read(fd[0], ...); } }

Jim Diamond, Jodrey School of Computer Science, Acadia University

Chapter 3 85

Pipes: 2

• Ordinary pipes “go away” when the processes using them terminate
• Named pipes (a.k.a. fifos in Unix-land):

– are persistent – have no parent-child relationship – – can (concurrently) be read from and written to by multiple processes

• In Unix, say something like

Process 1 Process 2 $ mkfifo /tmp/my-fifo $ ... $ cat < /tmp/my-fifo $ echo "A message" > /tmp/my-fifo $ ... A message $ ...

Jim Diamond, Jodrey School of Computer Science, Acadia University