CS 346 – Chapter 1 Operating system – definition Responsibilities What we find in computer systems Review of –Instruction execution –Compile – link – load.

CS 346 – Chapter 1

• Operating system – definition• Responsibilities• What we find in computer systems• Review of

– Instruction execution– Compile – link – load – execute

• Kernel versus user mode

Questions

• What is the purpose of a computer?

• What if all computers became fried or infected?

• How did Furman function before 1967 (the year we bought our first computer)?

• Why do people not like computers?

Definition

• How do you define something? Possible approaches:– What it consists of– What is does (a functional definition) – purpose– What if we didn’t have it– What else it’s similar to

• OS = set of software between user and HW– Provides “environment” for user to work– Convenience and efficiency– Manage the HW / resources– Ensure correct and appropriate operation of machine

• 2 Kinds of software: application and system– Distinction is blurry; no universal definition for “system”

Some responsibilities

• Can glean from table of contents – Book compares an OS to a government– Don’t worry about details for now

• Security: logins• Manage resources

– Correct and efficient use of CPU– Disk: “memory management”– network access

• File management• I/O, terminal, devices• Kernel vs. shell

Big picture

• Computer system has: CPU, main memory, disk, I/O devices

• Turn on computer:– Bootstrap program already in ROM comes to life– Tells where to find the OS on disk. Load the OS.– Transfer control to OS once loaded.

• From time to time, control is “interrupted”– Examples?

• Memory hierarchy– Several levels of memory in use from registers to tape– Closer to CPU: smaller, faster, more expensive– OS must decide who belongs where

Big picture (2)

• von Neumann program execution– Fetch, decode, execute, data access, write result

– OS usually not involved unless problem

• Compiling– 1 source file 1 object file

– 1 entire program 1 executable file

– “link” object files to produce executable

– Code may be optimized to please the OS

– When you invoke a program, OS calls a “loader” program that precedes execution

• I/O– Each device has a controller, a circuit containing registers and a memory

buffer

– Each controller is managed by a device driver (software)

2 modes

• When CPU executing instructions, nice to know if the instruction is on behalf of the OS

• OS should have the highest privileges kernel mode– Some operations only available to OS– Examples?

• Users should have some restriction user mode• A hardware bit can be set if program is running in kernel

mode

• Sometimes, the user needs OS to help out, so we perform a system call

Management topics

• What did we ask the OS to do during lab?

• File system• Program vs. process

– “job” and “task” are synonyms of process– Starting, destroying processes– Process communication– Make sure 2 processes don’t interfere with each other

• Multiprogramming– CPU should never be idle– Multitasking: give each job a short quantum of time to take turns– If a job needs I/O, give CPU to another job

More topics

• Scheduling: deciding the order to do the jobs– Detect system “load”– In a real-time system, jobs have deadlines. OS should know

worst-case execution time of jobs

• Memory hierarchy– Higher levels “bank” the lower levels– OS manages RAM/disk decision– Virtual memory: actual size of RAM is invisible to user. Allow

programmer to think memory is huge– Allocate and deallocate heap objects– Schedule disk ops and backups of data


• OS services– OS user interface– System calls– System programs

• How to make an OS– Implementation– Structure– Virtual machines

• Commitment – For next day, please finish chapter 2.

OS services

2 types• For the user’s convenience

– Shell– Running user programs– Doing I/O– File system– Detecting problems

• Internal/support– Allocating resources– System security– Accounting

• Infamous KGB spy ring uncovered due to discrepancy in billing of computer time at Berkeley lab

User interface

• Command line = shell program– Parses commands from user– Supports redirection of I/O (stdin, stdout, stderr)

• GUI– Pioneered by Xerox PARC, made famous by Mac– Utilizes additional input devices such as mouse– Icons or hotspots on screen

• Hybrid approach– GUI allowing several terminal windows– Window manager

System calls

• “an interface for accessing an OS service within a computer program”

• A little lower level than an API, but similar

• Looks like a function call

• Examples– Performing any I/O request, because these are not defined by the

programming language itself

e.g. read(file_ptr, str_buf_ptr, 80);– assembly languages typically have “syscall” instruction.

When is it used?

How?

• If many parameters, they may be put on runtime stack

Types of system calls

• Controlling a process

• File management

• Device management

• Information

• Communication between processes• What are some specific examples you’d expect to find?

System programs

• Also called system utilities• Distinction between “system call” and “system program”• Examples

– Shell commands like ls, lp, ps, top– Text editors, compilers– Communication: e-mail, talk, ftp– Miscellaneous: cal, fortune– What are your favorites?

• Higher level software includes:– Spreadsheets, text formatters, etc.– But, boundary between “application” and “utility” software is

blurry. A text formatter is a type of compiler!

OS design ideas

• An OS is a big program, so we should consider principles of systems analysis and software engineering

• In design phase, need to consider policies and mechanisms– Policy = What should we do; should we do X– Mechanism = how to do X

– Example: a way to schedule jobs (policy)

versus: what input needed to produce schedule, how schedule decision is specified (mechanism)

Implementation

• Originally in assembly

• Now usually in C (C++ if object-oriented)

• Still, some code needs to be in assembly– Some specific device driver routines– Saving/restoring registers

• We’d like to use HLL as much as possible – why?

• Today’s compilers produce very efficient code – what does this tell us?

• How to improve performance of OS:– More efficient data structure, algorithm– Exploit HW and memory hierarchy– Pay attention to CPU scheduling and memory management

Kernel structure

• Possible to implement minimal OS with a few thousand lines of code monolithic kernel– Modularize like any other large program– After about 10k loc, difficult to prove correctness

• Layered approach to managing the complexity– Layer 0 is the HW– Layer n is the user interface– Each layer makes use of routines and d.s. defined at lower

levels– # layers difficult to predict: many subtle dependencies– Many layers lots of internal system call overhead

Kernel structure (2)

kernel – Kernel = minimal support for processes and memory management– (The rest of the OS is at user level)– Adding OS services doesn’t require changing kernel, so easier to

modify OS– The kernel must manage communication between user program and

appropriate OS services (e.g. file system)– Microsoft gave up on kernel idea for Windows XP

• OO Module approach– Components isolated (OO information hiding)– Used by Linux, Solaris– Like a layered approach with just 2 layers, a core and everything

else

Virtual machine

• How to make 1 machine behave like many• Give users the illusion they have access to real HW,

distinct from other users• Figure 2.17 levels of abstraction:

– Processes / kernels / VM’s / VM implementations / host HW

As opposed to:– Processes / kernels / different machines

• Why do it?– To test multiple OS’s on the same HW platform– Host machine’s real HW protected from virus in a VM bubble

VM implementation

• It’s hard!– Need to painstakingly replicate every HW detail, to avoid giving away

the illusion– Need to keep track of what each guest OS is doing (whether it’s in

kernel or user mode)– Each VM must interpret its assembly code – why? Is this a problem?

• Very similar concept: simulation– Often, all we are interested in is changing the HW, not the OS; for

example, adding/eliminating the data cache– Write a program that simulates every HW feature, providing the OS with

the expected behavior


• What is a process

• Scheduling and life cycle

• Creation

• Termination

• Interprocess communication: purpose, how to do it

• Client-server: sockets, remote procedure call

• Commitment – Please read through section 3.4 by Wednesday and 3.6

by Friday.

Process

• Goal: to be able to run > 1 program concurrently– We don’t have to finish one before starting another– Concurrent doesn’t mean parallel– CPU often switches from one job to another

• Process = a program that has started but hasn’t yet finished

• States:– New, Ready, Running, Waiting, Terminated– What transitions exist between these states?

Contents

• A process consists of:– Code (“text” section)– Program Counter– Data section– Run-time stack – Heap allocated memory

• A process is represented in kernel by a Process Control Block, containing:– State– Program counter– Register values– Scheduling info (e.g. priority)– Memory info (e.g. bounds)– Accounting (e.g. time)– I/O info (e.g. which files open)

– What is not stored here?

Scheduling

• Typically many processes are ready, but only 1 can run at a time.– Need to choose who’s next from ready queue

– Can’t stay running for too long!

– At some point, process needs to be switched out temporarily back to the ready queue (Fig. 3.4)

• What happens to a process ? (Fig 3.7)– New process enters ready queue. At some point it can run.

– After running awhile, a few possibilities:

1. Time quantum expires. Go back to ready queue.

2. Need I/O. Go to I/O queue, do I/O, re-enter ready queue!

3. Interrupted. Handle interrupt, and go to ready queue.

– Context switch overhead

Creation

• Processes can spawn other processes.– Parent / child relationship– Tree– Book shows Solaris example:

In the beginning, there was sched, which spawned init (the ancestor of all user processes), the memory manager, and the file manager.

– Process ID’s are unique integers (up to some max e.g. 215)

• What should happen when process created?– OS policy on what resources for baby: system default, or copy

parent’s capabilities, or specify at its creation– What program does child run? Same as parent, or new one?– Does parent continue to execute, or does it wait (i.e. block)?

How to create

• Unix procedure is typical…• Parent calls fork( )

– This creates duplicate process.– fork( ) returns 0 for child; positive number for parent; negative

number if error. (How could we have error?)

• Next, we call exec( ) to tell child what program to run.– Do this immediately after fork– Do inside the if clause that corresponds to case that we are

inside the child!

• Parent can call wait( ) to go to sleep.– Not executing, not in ready queue

Termination

• Assembly programs end with a system call to exit( ).– An int value is returned to parent’s wait( ) function. This lets parent

know which child has just finished.

• Or, process can be killed prematurely– Why?– Only the parent (or ancestor) can kill another process – why this

restriction?

• When a process dies, 2 possible policies:– OS can kill all descendants (rare)– Allow descendants to continue, but set parent of dead process to init

IPC Examples

• Allowing concurrent access to information – Producer / consumer is a common paradigm

• Distributing work, as long as spare resources (e.g. CPU) are around

• A program may need result of another program– IPC more efficient than running serially and redirecting I/O– A compiler may need result of timing analysis in order to know

which optimizations to perform

• Note: ease of programming is based on what OS and programming language allow

2 techniques

• Shared memory– 2 processes have access to an overlapping area of memory– Conceptually easier to learn, but be careful!– OS overhead only at the beginning: get kernel permission to set

up shared region

• Message passing– Uses system calls, with kernel as middle man – easier to code

correctly– System call overhead for every message we’d want amount

of data to be small– Definitely better when processes on different machines

• Often, both approaches are possible on the system

Shared memory

• Usually forbidden to touch another process’ memory area

• Each program must be written so that the shared memory request is explicit (via system call)– An overlapping “buffer” can be set up. Range of addresses. But

there is no need for the buffer to be contiguous in memory with the existing processes.

– Then, the buffer can be treated like an array (of char)

• Making use of the buffer (p. 122)– Insert( ) function– Remove( ) function– Circular array… does the code make sense to you?

Shared memory (2)

• What could go wrong?... How to fix?

• Trying to insert into full buffer• Trying to remove from empty buffer• Sound familiar?

• Also: both trying to insert. Is this a problem?

Message passing

• Make continual use of system calls:– Send( )– Receive( )

• Direct or indirect communication?– Direct: send (process_num, the_message)

Hard coding the process we’re talking to– Indirect: send (mailbox_num, the_message)

Assuming we’ve set up a “mailbox” inside the kernel

• Flexibility: can have a communication link with more than 2 processes. e.g. 2 producers and 1 consumer

• Design issues in case we have multiple consumers– We could forbid it– Could be first-come-first-serve

Synchronization

• What should we do when we send/receive a message?• Block (or “wait”):

– Go to sleep until counterpart acts. – If you send, sleep until received by process or mailbox. – If you receive, block until a message available. How do we know?

• Don’t block– Just keep executing. If they drop the baton it’s their fault.– In case of receive( ), return null if there is no message (where do we

look?)

• We may need some queue of messages (set up in kernel) so we don’t lose messages!

Buffer messages

• The message passing may be direct (to another specific process) or indirect (to a mailbox – no process explicitly stated in the call).

• But either way, we don’t want to lose messages.

• Zero capacity: sender blocks until recipient gets message

• Bounded capacity (common choice): Sender blocks if the buffer is full.

• Unbounded capacity: Assume buffer is infinite. Never block when you send.

Socket

• Can be used as an “endpoint of communication”• Attach to a (software) port on a “host” computer

connected to the Internet– 156.143.143.132:1625 means port # 1625 on the machine

whose IP number is 156.143.143.132– Port numbers < 1024 are pre-assigned for “well known” tasks.

For example, port 80 is for a Web server.

• With a pair of sockets, you can communicate between them.

• Generally used for remote I/O

Implementation

• Syntax depends on language.• Server

– Create socket object on some local port.– Wait for client to call. Accept connection.– Set up output stream for client.– Write data to client.– Close client connection.– Go back to wait

• Client– Create socket object to connect to server– Read input analogous to file input or stdin– Close connection to server

Remote procedure call

• Useful application of inter-process communication (the message-passing version)

• Systematic way to make procedure call between processes on the network– Reduce implementation details for user

• Client wants to call foreign function with some parameters– Tell kernel server’s IP number and function name– 1st message: ask server which port corresponds with function– 2nd message: sending function call with “marshalled” parameters– Server daemon listens for function call request, and processes– Client receives return value

• OS should ensure function call successful (once)


• Threads– How they differ from processes– Definition, purpose

Threads of the same process share: code, data, open files– Types– Support by kernel and programming language– Issues such as signals– User thread implementation: C and Java

• Commitment – For next day, please read chapter 4

Thread intro

• Also called “lightweight process”• One process may have multiple threads of execution• Allows a process to do 2+ things concurrently

– Games– Simulations

• Even better: if you have 2+ CPU’s, you can execute in parallel

• Multicore architecture demand for multithreaded applications for speedup

• More efficient than using several concurrent processes

Threads

• A process contains:– Code, data, open files, registers, memory usage (stack + heap),

program counter

• Threads of the same process share– Code, data, open files

• What is unique to each thread?

• Can you think of example of a computational algorithm where threads would be a great idea?– Splitting up the code– Splitting up the data

• Any disadvantages?

2 types of threads

• User threads– Can be managed / controlled by user

– Need existing programming language API support:

POSIX threads in C

Java threads

• Kernel threads– Management done by the kernel

Possible scenarios– OS doesn’t support threading

– OS support threads, but only at kernel level – you have no direct control, except possibly by system call

– User can create thread objects and manipulate them. These objects map to “real” kernel threads.

Multithreading models

• Many-to-one: User can create several thread objects, but in reality the kernel only gives you one. Multithreading is an illusion

• One-to-one: Each user thread maps to 1 real kernel thread. Great but costly to OS. There may be a hard limit to # of live threads.

• Many-to-many: A happy compromise. We have multithreading, but the number of true threads may be less than # of thread objects we created.– A variant of this model “two-level” allows user to designate a thread as

being bound to one kernel thread.

Thread issues

• What should OS do if a thread calls fork( )?– Can duplicate just the calling thread– Can duplicate all threads in the process

• exec ( ) is designed to replace entire current process

• Cancellation– kill thread before it’s finished– “Asynchronous cancellation” = kill now. But it may be in the middle

of an update, or it may have acquired resources.

You may have noticed that Windows sometimes won’t let you delete a file because it thinks it’s still open.

– “Deferred cancellation”. Thread periodically checks to see if it’s time to quit. Graceful exit.

Signals

• Reminiscent of exception in Java• Occurs when OS needs to send message to a process

– Some defined event generates a signal– OS delivers signal– Recipient must handle the signal.

Kernel defines a default handler – e.g. kill the process.

Or, user can write specific handler.

• Types of signals– Synchronous: something in this program caused the event– Asynchronous: event was external to my program

Signals (2)

• But what if process has multiple threads? Who gets the signal? For a given signal, choose among 4 possibilities:– Deliver signal to the 1 appropriate thread– Deliver signal to all threads– Have the signal indicate which threads to contact– Designate a thread to receive all signals

• Rules of thumb…– Synchronous event just deliver to 1 thread– User hit ctrl-C kill all threads

Thread pool

• Like a motor pool• When process starts, can create a set of threads that sit

around and wait for work• Motivation

– overhead in creating/destroying– We can set a bound for total number of threads, and avoid

overloading system later

• How many threads?– User can specify– Kernel can base on available resources (memory and # CPU’s)– Can dynamically change if necessary

POSIX threads

• aka “Pthreads”• C language• Commonly seen in UNIX-style environments:

– Mac OS, Linux, Solaris

• POSIX is a set of standards for OS system calls– Thread support is just one aspect

• POSIX provides an API for thread creation and synchronization

• API specifies behavior of thread functionality, but not the low-level implementation

Pthread functions

• pthread_attr_init– Initialize thread attributes, such as– Schedule priority– Stack size– State

• pthread_create– Start new thread inside the process.– We specify what function to call when thread starts, along with

the necessary parameter– The thread is due to terminate when its function returns

• pthread_join– Allows us to wait for a child thread to finish

Example code

#include <pthread.h>

int sum;

main() {

pthread_t tid;

pthread_attr attr;

pthread_attr_init(&attr);

pthread_create(&tid,

&attr, fun, argv[1]);

pthread join(tid, NULL);

printf(“%d\n”, sum);

}

int fun(char *param) ...

void *fun(void *param)

{

// compute a sum:

// store in global

// variable

...

}

Java threads• Managed by the Java virtual machine• Two ways to create threads

1. Create a class that extends the Thread class– Put code inside public void run( )

2. Implement the Runnable interface– public void run( )

• Parent thread (e.g. in main() …)– Create thread object – just binds name of thread– Call start( ) – creates actual running thread, goes to run( )

See book example

Skeletons

class Worker extends Thread {

public void run() {

// do stuff

}

}

public class Driver

{

// in main method:

Worker w = new Worker();

w.start();

... Continue/join

}

class Worker2 implements Runnable {

public void run() {

// do stuff

}

}

Public class Driver2

{

// in main method:

Runnable w2=new Worker2();

Thread t = new Thread(w2);

t.start();

// ...Continue/join

}

Java thread states

• This will probably sound familiar!• New

– From here, go to “runnable” at call to start( )

• Runnable– Go to “blocked” if need I/O or going to sleep– Go to “dead” when we exit run( )– Go to “waiting” if we call join( ) for child thread

• Blocked– Go to “runnable” when I/O is serviced

• Waiting• Dead

CS 346 – Sect. 5.1-5.2

• Process synchronization– What is the problem?– Criteria for solution– Producer / consumer example

– General problems difficult because of subtleties

Problem

• It’s often desirable for processes/threads to share data– Can be a form of communication– One may need data being produced by the other

• Concurrent access possible data inconsistency• Need to “synchronize”…

– HW or SW techniques to ensure orderly execution

• Bartender & drinker– Bartender takes empty glass and fills it– Drinker takes full glass and drinks contents– What if drinker overeager and starts drinking too soon?– What if drinker not finished when bartender returns?– Must ensure we don’t spill on counter.

Key concepts

• Critical section = code containing access to shared data– Looking up a value or modifying it

• Race condition = situation where outcome of code depends on the order in which processes take turns– The correctness of the code should not depend on scheduling

• Simple example: producer / consumer code, p. 204– Producer adds data to buffer and executes ++count;– Consumer grabs data and executes --count;– Assume count initially 5.– Let’s see what could happen…

Machine code

Producer’s ++count becomes:1 r1 = count

2 r1 = r1 + 1

3 count = r1

Consumer’s --count becomes:4 r2 = count

5 r2 = r2 – 1

6 count = r2

Does this code work?

Yes, if we execute in order 1,2,3,4,5,6 or 4,5,6,1,2,3 -- see why?

Scheduler may have other ideas!

Alternate schedules

1 r1 = count

2 r1 = r1 + 1

4 r2 = count

5 r2 = r2 – 1

3 count = r1

6 count = r2

1 r1 = count

2 r1 = r1 + 1

4 r2 = count

5 r2 = r2 – 1

6 count = r2

3 count = r1

• What are the final values of count?

• How could these situations happen?

• If the updating of a single variable is nontrivial, you can imagine how critical the general problem is!

Solution criteria

• How do we know we have solved a synchronization problem? 3 criteria:

• Mutual exclusion – Only 1 process may be inside its critical section at any one time.– Note: For simplicity we’re assuming there is one zone of shared data,

so each process using it has 1 critical section.

• Progress – Don’t hesitate to enter your critical section if no one else is in theirs.– Avoid an overly conservative solution

• Bounded waiting – There is a limit on # of times you may access your critical section if another is still waiting to enter theirs.– Avoid starvation

Solution skeleton

while (true)

{

Seek permission to enter critical section

Do critical section

Announce done with critical section

Do non-critical code

}

• BTW, easy solution is to forbid preemption.– But this power can be abused.– Identifying critical section can avoid preemption for a shorter period

of time.

CS 346 – Sect. 5.3-5.7

• Process synchronization– A useful example is “producer-consumer” problem– Peterson’s solution– HW support– Semaphores– “Dining philosophers”

• Commitment – Compile and run semaphore code from os-book.com

Peterson’s solution

… to the 2-process producer/consumer problem. (p. 204)

while (true)

{

ready[ me ] = true

turn = other

while (ready[ other ] && turn == other) ;

Do critical section

ready[ me ] = false

Do non-critical code

}

// Don’t memorize but think: Why does this ensure mutual exclusion?

// What assumptions does this solution make?

HW support

• As we mentioned before, we can disable interrupts No one can preempt me.– Disadvantages

• The usual way to handle synchronization is by careful programming (SW)

• We require some atomic HW operations– A short sequence of assembly instructions guaranteed to be non-

interruptable– This keeps non-preemption duration to absolute minimum– Access to “lock” variables visible to all threads– e.g. swapping the values in 2 variables– e.g. get and set some value (aka “test and set”)

Semaphore

• Dijkstra’s solution to mutual exclusion problem

• Semaphore object– integer value attribute ( > 0 means resource is available)– acquire and release methods

• Semaphore variants: binary and counting– Binary semaphore aka “mutex” or “mutex lock”

acquire() release()

{ {

if (value <= 0) ++value

wait/sleep // wake sleeper

--value }

}

Deadlock / starvation

• After we solve a mutual exclusion problem, also need to avoid other problems– Another way of expressing our synchronization goals

• Deadlock: 2+ process waiting for an event that can only be performed by one of the waiting processes– the opposite of progress

• Starvation: being blocked for an indefinite or unbounded amount of time– e.g. Potentially stuck on a semaphore wait queue forever

Bounded-buffer problem

• aka “producer-consumer”. See figures 5.9 – 5.10

• Producer class– run( ) to be executed by a thread– Periodically call insert( )

• Consumer class– Also to be run by a thread– Periodically call remove( )

• BoundedBuffer class– Creates semaphores (mutex, empty, full): why 3?

Initial values: mutex = 1, empty = SIZE, full = 0– Implements insert( ) and remove( ).

These methods contain calls to semaphore operations acquire( ) and release( ).

Insert & delete

public void insert(E item)

{ empty.acquire(); mutex.acquire();

// add an item to the

// buffer...

mutex.release();

full.release();

}

public E remove()

{

full.acquire();

mutex.acquire();

// remove item ...

mutex.release();

empty.release();

}

• What are we doing with the semaphores?

Readers/writers problem

• More general than producer-consumer

• We may have multiple readers and writers of shared info

• Mutual exclusion requirement:

Must ensure that writers have exclusive access

• It’s okay to have multiple readers reading

See example solution, Fig. 5.10 – 5.12

• Reader and Writer threads periodically want to execute.– Operations guarded by semaphore operations

• Database class (analogous to BoundedBuffer earlier)– readerCount

– 2 semaphores: one to protect database, one to protect the updating of readerCount

Solution outline

Reader:

mutex.acquire();

++readerCount;

if(readerCount == 1)

db.acquire();

mutex.release();

// READ NOW

mutex.acquire();

--readerCount;

if(readerCount == 0)

db.release();

mutex.release();

Writer:

db.acquire();

// WRITE NOW

db.release();

Example outputwriter 0 wants to write.

writer 0 is writing.

writer 0 is done writing.

reader 2 wants to read.

writer 1 wants to write.



Reader 2 is reading. Reader count = 1



writer 0 wants to write.

Reader 1 is done reading. Reader count = 2



writer 1 is writing.


writer 1 is done writing.

CS 346 – Sect. 5.7-5.8

• Process synchronization– “Dining philosophers” (Dijkstra, 1965)– Monitors

Dining philosophers

• Classic OS problem– Many possible solutions depending on how foolproof you want solution to

be

• Simulates synchronization situation of several resources, and several potential consumers.

• What is the problem?• Model chopsticks with semaphores – available or not.

– Initialize each to be 1

• Achieve mutual exclusion:– acquire left and right chopsticks (numbered i and i+1)

– Eat– release left and right chopsticks

• What could go wrong?

DP (2)

• What can we say about this solution?

mutex.acquire();

Acquire 2 neighboring forks

Eat

Release the 2 forks

mutex.release();

• Other improvements:– Ability to see if either neighbor is eating

– May make more sense to associate semaphore with the philosophers, not the forks. A philosopher should block if cannot acquire both forks.

– When done eating, wake up either neighbor if necessary.

Monitor

• Higher level than semaphore– Semaphore coding can be buggy

• Programming language construct– Special kind of class / data type– Hides implementation detail

• Automatically ensures mutual exclusion– Only 1 thread may be “inside” monitor at any one time– Attributes of monitor are the shared variables– Methods in monitor deal with specific synchronization problem. This is

where you access shared variables.– Constructor can initialize shared variables

• Supported by a number of HLLs– Concurrent Pascal, Java, C#

Condition variables

• With a monitor, you get mutual exclusion• If you also want to ensure against deadlock or starvation,

you need condition variables• Special data type associated with monitors• Declared with other shared attributes of monitor• How to use them:

– No attribute value to manipulate. 2 functions only:– Wait: if you call this, you go to sleep. (Enter a queue)– Signal: means you release a resource, waking up a thread

waiting for it.– Each condition variable has its own queue of waiting

threads/processes.

Signal( )

• A subtle issue for signal…• In a monitor, only 1 thread may be running at a time.• Suppose P calls x.wait( ). It’s now asleep.• Later, Q calls x.signal( ) in order to yield resource to P.• What should happen? 3 design alternatives:

– “blocking signal” – Q immediately goes to sleep so that P can continue.

– “nonblocking signal” – P does not actually resume until Q has left the monitor

– Compromise – Q immediately exits the monitor.

• Whoever gets to continue running may have to go to sleep on another condition variable.

CS 346 – Sect. 5.9

• Process synchronization– “Dining philosophers” monitor solution– Java synchronization– atomic operations

Monitor for DP

• Figure 5.18 on page 228

• Shared variable attributes:– state for each philosopher

– “self” condition variable for each philosopher

• takeForks( )– Declare myself hungry

– See if I can get the forks. If not, go to sleep.

• returnForks( )– Why do we call test( )?

• test( )– If I’m hungry and my neighbors are not eating, then I will eat and

leave the monitor.

Synch in Java

• “thread safe” = data remain consistent even if we have concurrently running threads

• If waiting for a (semaphore) value to become positive– Busy waiting loop – Better: Java provides Thread.yield( ): “block me”

• But even “yielding” ourselves can cause livelock– Continually attempting an operation that fails– e.g. You wait for another process to run, but the scheduler

keeps scheduling you instead because you have higher priority

Synchronized

• Java’s answer to synchronization is the keyword synchronized – qualifier for method

as in public synchronized void funName(params) { …• When you call a synchronized method belonging to an

object, you obtain a “lock” on that object

e.g. sem.acquire();• Lock automatically released when you exit method.• If you try to call a synchronized method, & the object is

already locked by another thread, you are blocked and sent to the object’s entry set.– Not quite a queue. JVM may arbitrarily choose who gets in next

Avoid deadlock

• Producer/consumer example– Suppose buffer is full. Producer now running.– Producer calls insert( ). Successfully enters method has lock

on the buffer. Because buffer full, calls Thread.yield( ) so that consumer can eat some data.

– Consumer wakes up, but cannot enter remove( ) method because producer still has lock. we have deadlock.

• Solution is to use wait( ) and notify( ).– When you wait, you release the lock, go to sleep (blocked), and

enter the object’s wait set. Not to be confused with entry set.– When you notify, JVM picks a thread T from the wait set and

moves it to entry set. T now eligible to run, and continues from point after its call to wait().

notifyAll

• Put every waiting thread into the entry set.– Good idea if you think > 1 thread waiting.– Now, all these threads compete for next use of synchronized

object.

• Sometimes, just calling notify can lead to deadlock– Book’s doWork example ***– Threads are numbered– doWork has a shared variable turn. You can only do work here

if it’s your turn: if turn == your number.– Thread 3 is doing work, sets turn to 4, and then leaves. – But thread 4 is not in the wait set. All other threads will go to

sleep.

More Java support

See: java.util.concurrent

• Built-in ReentrantLock class– Create an object of this class; call its lock and unlock methods

to access your critical section (p. 282)

– Allows you to set priority to waiting threads

• Condition interface (condition variable)– Meant to be used with a lock. What is the goal?– await( ) and notify( )

• Semaphore class– acquire( ) and release( )

Atomic operations

• Behind the scenes, need to make sure instructions are performed in appropriate order

• “transaction” = 1 single logical function performed by a thread– In this case, involving shared memory– We want it to run atomically

• As we perform individual instructions, things might go smoothly or not– If all ok, then commit – If not, abort and “roll back” to earlier state of computation

• This is easier if we have fewer instructions in a row to do

Keeping the order

Transaction 1 Transaction 2

Read (A)

Write (A)

Read (B)

Write (B)

Read (A)

Write (A)

Read (B)

Write (B)

Transaction 1 Transaction 2

Read (A)

Write (A)

Read (A)

Write (A)

Read (B)

Write (B)

Read (B)

Write (B)

• Are these two schedules equivalent? Why?


• CPU scheduling– Characteristics of jobs– Scheduling criteria / goals– Scheduling algorithms – System load– Implementation issues– Real-time scheduling

Schedule issues

• Multi-programming is good! better CPU utilization• CPU burst concept

– Jobs typically alternate between work and wait– Fig. 6.2: Distribution has long tail on right.

General questions• How or when does a job enter the ready queue?• How much time can a job use the CPU?• Do we prioritize jobs?• Do we pre-empt jobs?• How do we measure overall performance?

Scheduler

• Makes short-term decisions– When? Whenever a job changes state (becomes ready, needs to

wait, finishes)

– Selects a job on the ready queue

– Dispatcher can then do the “context switch” to give CPU to new job

• Should we preempt?– Non-preemptive = Job continues to execute until it has to wait or

finishes

– Preemptive = Job may be removed from CPU while doing work!

– When you preempt: need to leave CPU “gracefully”. May be in the middle of a system call or modifying shared data. Often we let that operation complete.

Scheduling criteria

• CPU utilization = what % of time CPU is executing instructions

• Throughput = # or rate of jobs completed in some time period

• Turnaround time = (finish time) – (request time)• Waiting time = how long spent in ready state

– Confusing name!

• Response time = how long after request that a job begins to produce output

• Usually, we want to optimize the “average” of each measure. e.g. Reduce average turnaround time.

Some scheduling algorithms

• First-come, first-served• Round robin

– Like FCFS, but each job has a limited time quantum

• Shortest job next

• We use a Gantt chart to view and evaluate a schedule– e.g. compute average turnaround time

• Often, key question is – in what order do we execute jobs?

• Let’s compare FCFS and SJN…

Example 1

• First-come, first-served– Process 1 can execute from t=0 to t=20– Process 2 can execute from t=20 to t=50– Process 3 can execute from t=50 to t=90– Process 4 can execute from t=90 to t=100

• We can enter this info as extra columns in the table.• What is the average turnaround time?• What if we tried Shortest Job Next?

Process number Time of request Execution time needed

1 0 20

2 5 30

3 10 40

4 20 10

Example 2

Note that it’s possible to have idle time.

Process number Time of request Execution time needed

1 0 10

2 30 30

3 40 20

4 50 5

System load

• A measure of how “busy” the CPU is• At an instant: how many tasks are currently running or

ready.– If load > 1, the system is “overloaded”, and work is backing up.

• Typically reported as an average of the last 1, 5, or 15 minutes.

• Based on the schedule, can calculate average load as well as maximum (peak) load.

Example 1

• FCFS schedule can also be depicted this way:

• What can we say about the load?

Job # Request Exec Start Finish

1 0 20 0 20

2 5 30 20 50

3 10 40 50 90

4 20 10 90 100

X X X X

R R R X X X X X X

R R R R R R R R X X X X X X X X

R R R R R R R R R R R R R R X X

“Request time” aka “Arrival time”

Example 2

• SJN schedule can be depicted this way:

• Load?


1 0 10 0 10

2 30 30 30 60

3 40 20 65 85

4 50 5 60 65

X X

X X X X X X

R R R R R X X X X

R R X

Preemptive SJN

• If a new job arrives with a shorter execution time (CPU burst length) than currently running process, preempt!

• Could also call it “shortest remaining job next”• Let’s redo previous example allowing preemption

– Job #1 is unaffected.– Job #2 would have run from 30 to 60, but …

– Does preemption reduce average turnaround time? Load?


1 0 10 0 10

2 30 30

3 40 20

4 50 5

Estimating time

• Some scheduling algorithms like SJN need a job’s expected CPU time

• We’re interested in scheduling bursts of CPU time, not literally the entire job.

• OS doesn’t really know in advance how much of a “burst” will be needed. Instead, we estimate.

• Exponential averaging method. We predict the next CPU burst will take this long:

pn+1 = a tn + (1 – a)pn

tn = actual time of the nth burst

• Formula allows us to weight recent vs. long-term history.– What if a = 0 or 1?

Estimating time (2)

• pn+1 = a tn + (1 – a)pn

• Why is it called “exponential”? Becomes clearer if we substitute all the way back to the first burst.

• p1 = a t0 + (1 – a)p0

• p2 = a t1 + (1 – a)p1

= a t1 + (1 – a) [a t0 + (1 – a)p0 ]

= a t1 + (1 – a) a t0 + (1 – a)2 p0

• A general formula for pn+1 will eventually contain terms of the form (1 – a) raised to various powers.– In practice, we just look at previous actual vs. previous prediction

• Book’s example Figure 6.3: Prediction eventually converges to correct recent behavior.

Priority scheduling

• SJN is a special case of a whole class of scheduling algorithms that assign priorities to jobs.

• Each job has a priority value:– Convention: low number = “high” priority

• SJN: priority = next predicted burst time

• Starvation: Some “low priority” jobs may never execute– How could this happen?

• Aging: modify SJN so that while a job waits, it gradually “increases” its priority so it won’t starve.

Round robin

• Each job takes a short turn at the CPU

• Commonly used, easy for OS to handle

• Time quantum typically 10-100 ms – it’s constant

• Choice of time quantum has a minor impact on turnaround time (Figure 6.5)– Can re-work an earlier example

• Questions to think about:

• If there are N jobs, what is the maximum wait time before you can start executing?

• What happens if the time quantum is very large?

• What happens if the time quantum is very short?

Implementation issues

• Multi-level ready queue

• Threads

• Multi-processor scheduling

Multi-level queue

• We can assign jobs to different queues based on their purpose or priority

• Foreground / interactive jobs may deserve high priority to please the user– Also: real-time tasks

• Background / routine tasks can be given lower priority

• Each queue can have its own scheduling regime, e.g. round robin instead of SJN– Interactive jobs may have unpredictable burst times

• Key issue: need to schedule among the queues themselves. How?

Scheduling among queues

• Classify jobs according to purpose priority• Priority based queue scheduling

– Can’t run any Priority 2 job until all Priority 1 jobs done.– While running Priority 2 job, can preempt if a Priority 1 job arrives.– Starvation

• Round robin with different time quantum for each queue• Time share for each queue

– Decreasing % of time for lower priorities

• Or… Multi-level feedback queue (pp. 275-277)– All jobs enter at Priority 0. Given short time quantum.– If not done, enter queue for Priority 1 jobs. Longer quantum next

time.

Thread scheduling

• The OS schedules “actual” kernel-level threads

• The thread library must handle user threads– One-to-one model – easy, each user thread is already a kernel thread.

Direct system call

– Many-to-many or many-to-one models• Thread library has 1 or a small number of kernel threads available.• Thread library must decide when user thread should run on a true

kernel thread.• Programmer can set a priority for thread library to consider.

In other words, threads of the same process are competing among themselves.

Multi-processing

• More issues to address, more complex overall• Homogeneous system = identical processors, job can run on

any of them• Asymmetric approach = allocate 1 processor for the OS, all

others for user tasks– This “master server” makes decisions about what jobs run on the other

processors

• Symmetric approach (SMP) = 1 scheduler for each processor, usually separate ready queue for each (but could have a common queue for all)

• Load balancing: periodically see if we should “pull” or “push” jobs

Affinity

• When switched out, a job may want to return next time to the same processor as before– Why desirable?– An affinity policy may be “soft” or “hard”.– Soft = OS will try but not guarantee.

Why might an OS prefer to migrate a process to a different processor?

• Generalized concept: processor set– For each process, maintain a list of processors it may be run on

• Memory system can exploit affinity, allocating more memory that is closer to the favorite CPU. (Fig. 6.9)

Multicore processor

• Conceptually similar to multiprocessors– Place multiple “processor cores” on same chip– Faster, consume less power– OS treats each core like a unique CPU

• However, the cores often share cache memory– Leads to more “cache misses” Jobs spend more time stalled

waiting for instructions or data to arrive– OS can allocate 2 threads to the same core, to increase

processor utilization– Fig. 6.11 shows idealized situation. What happens in general?

Real-time Scheduling

• Real-time scheduling– Earliest Deadline First– Rate Monotonic

• What is this about?– Primary goal is avoid missing deadlines. Other goals may

include having response times that are low and consistent.– We’re assuming jobs are periodic, and the deadline of a job is

the end of a period

Real-time systems

• Specialized operating system• All jobs potentially have a deadline

– Correctness of operation depends on meeting deadlines, in addition to correct algorithm

– Often, jobs are periodic; some may be aperiodic/sporadic

• Hard real-time = missing a deadline is not acceptable• Soft real-time = deadline miss not end of world, but try to

minimize– Number of acceptable deadline misses is a design parameter– We try to measure Quality of Service (QoS)– Examples?

• Used in defense, factories, communications, multimedia; embedded in appliances

Features

• A real-time system may be used to control specific device– Opening bomb bay door– When to release chocolate into vat

• Host device typically very small and lacks features of PC, greatly simplifying OS design– Single user or no user– Little or no memory hierarchy– Simple instruction set (or not!)– No disk drive, monitor– Cheap to manufacture, mass produce

Scheduling

• Most important issue in real-time systems is CPU scheduling• System needs to know WCET of jobs • Jobs are given priority based on their timing/deadline needs• Jobs may be pre-empted• Kernel jobs (implemented system calls) contain many

possible preemption points at which they may be safely suspended

• Want to minimize latency– System needs to respond quickly to external event, such as change

in temperature– Interrupt must have minimum overhead – how to measure it?

EDF

• Given a set of jobs– Need to know period and execution time of each

– Each job contributes to the CPU’s utilization: execution time divided by the period

– If the total utilization of all jobs > 1, no schedule possible!

• At each scheduling checkpoint, choose the job with the earliest deadline.– A scheduling checkpoint occurs at t = 0, when a job begins period or is

finished, or when a new job arrives into the system

– If no new jobs enter the system, EDF is non-preemptive

– Sometimes the CPU is idle

• Need to compute schedule one dynamic job at a time until you reach the LCM of the job periods– Can predict deadline miss, if any

EDF example

• Suppose we have 2 jobs, A and B, with periods 10 and 15, and execution times 5 and 6.

• At t = 0, we schedule A because its deadline is earlier (10 < 15).

• At t = 5, A is finished. We can now schedule B.• At t = 11, B is finished. A has already started a new

period, we can schedule it immediately.• At t = 16, A is finished. B already started a new period,

so schedule it.• At t = 22, B is finished. Schedule A.• At t = 27, A is finished, and CPU is idle until t = 30.

EDF: be careful

• At certain scheduling checkpoints, you need to schedule the job with the earliest deadline.– As long as that job has started its period.– Do each cycle iteratively until the LCM of the job periods.

• Checkpoints include– t = 0– Whenever a job is finished executing– Whenever a job begins its period

(This condition is important when we have maximum utilization.)

• Example with 2 jobs– Job A has period 6 and execution time 3.– Job B has period 14 and execution time 7.– U = 1. We should be able to schedule these jobs with EDF.

Example: EDF

• Wrong way: ignoring beginning of job periods– At t = 0, we see jobs A (period 0-6) and B (period 0-14)

Since A has sooner deadline, schedule A for its 3 cycles.

– At t = 3, we see jobs A (period 6-12) and B (period 0-14)

Since A hasn’t started its period, our only choice is B, for its 7 cycles.

– At t = 10, we have job A (period 6-12) and B (period 14-28)

A has sooner deadline. Schedule A for its 3 cycles.

– At t = 13, A is finished but it missed its deadline. We don’t want this to happen!

continued• Job A = (per 6, exec 3) Job B = (per 14, exec 7)• Correct EDF schedule that takes into account the start of a job

period as another scheduling checkpoint

• Notice:– At t = 12 and t = 24, we don’t preempt job B, because B’s deadline is

sooner. In the other cases when A’s period begins, A takes the higher priority.

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

A A A B B B A A A B B B B A A A B B A A A

2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

B B B B B A A A B A A A B B B A A A B B B

RM

• Most often used because it’s easy• Inherently preemptive• Assign each job a fixed priority based on its period

– The shorter the period, the more often this job must execute, the more deadlines it has the higher the priority

• Determine in advance the schedule of the highest priority job– Continue for other jobs in descending order of priority– Be sure not to “schedule” a job before its period begins

• Less tedious than EDF to compute entire schedule– For highest priority job, you know exactly when it will execute– Other jobs may be preempted by higher priority jobs that were scheduled

first

RM (2)• Sometimes not possible to find a schedule

– Our ability to schedule is more limited than EDF.

• There is a simple mathematical check to see if a RM schedule is possible:– We can schedule if the total utilization is n (21/n – 1)

Proved by Liu and Layland in 1973.– If n (21/n – 1) < U 1, the test is inconclusive. Must compute

the schedule to find out.– Ex. If n = 2, we are guaranteed to find a RM schedule if U <

82%, but for 90% it gets risky.– Large experiments using random job parameters show that RM

is reliable up to about 88% utilization.

n 1 2 3 4 5 6 7 8

P(RM) 1.000 0.828 0.780 0.757 0.743 0.735 0.729 0.724 0.693

RM Example

• Suppose we have 2 jobs, C and D, with periods of 2 and 3, both with execution time 1.

• U = 1/2 + 1/3 > 82%, so RM is risky. Let’s try it…

• Schedule the more frequent job first.

• Then schedule job D.

• Looks okay!

C C C C C

C D C D C C D C D

RM Example 2

• Let’s look at earlier set of tasks, A and B, with periods of 10 and 15, and execution times of 5 and 6.

• U = 5/10 + 6/15 = 0.9, also risky.• Schedule task A first.

• Schedule task B into available spaces.

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

A A A A A A A A A A A A A A A

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

A A A A A B B B B B A A A A A B A A A A A

Comparison

• Consider this set of jobs

• What is the total utilization ratio? Are EDF and RM schedules feasible?

• Handout

Job # Period Execution time

1 10 3

2 12 4

3 15 5

RM vs. EDF

• EDF– Job’s priority is dynamic, hard to predict in advance– Too democratic / egalitarian? Maybe we are trying to execute

too many jobs.

• RM– Fixed priority is often desirable– Higher priority job will have better response times overall, not

bothered by a lower priority job that luckily has an upcoming deadline.

– RM cannot handle utilization up to 1 unless periods are in sync, as in 1 : n1 : n1n2 : n1n2n3 : …

(Analogy: Telling time is easy until you get to months/years.)

RM example

• Let’s return to previous example, this time using RM.– Job A = (per 6, exec 3) Job B = (per 14, exec 7)– Hyperperiod is 42– First, we must schedule job A, because it has shorter period.

– Next, schedule job B.

– Uh-oh! During B’s period 0-14, it is only able to execute for 6 cycles. Deadline miss This job set cannot be scheduled. But it could if either job’s execution time were less reduce U.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 …

A A A A A A A A A

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 …

A A A B B B A A A B B B A A A B

RM Utilization bound

• Liu and Layland (1973): “Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment”– They first looked at the case of 2 jobs. What is the maximum CPU

utilization that RM will always work? Express U as a function of 1 of the job’s execution time, assuming the other job will fully utilize the CPU during its period.

• We have 2 jobs– Job j1 has period T1 = 8 Job j2 has period T2 = 12– Let’s see what execution times C1 and C2 we can have, and what

effect this has on the CPU utilization.– During one of j2’s periods, how many times will j1 start?

In general: ceil(T2/T1). In our case, ceil(12/8) = 2.– They derive formulas to determine C2 and U, once we decide on a

value of C1.

continued

• We have job j1 (T1 = 8) and job j2 (T2 = 12)

• Suppose C1 = 2.– C2 = T2 – C1 * (number of times j1 starts)

= T2 – C1 * ceil (T2 / T1)

= 12 – 2 ceil (12 / 8) = 8.– We can compute U = 2/8 + 8/12 = 11/12.

• Suppose C1 = 4– C2 = 4– U = 4/8 + 4/12 = 5/6– The CPU utilization is actually lower as we increase the execution time

of j1.

• … If the last execution of j1 spills over into the next period of j2, the opposite trend occurs.

Formula

• Eventually, Liu and Layland derive this general formula for maximum utilization for 2 jobs:

U = 1 – x(1 – x)/(W + x)

where W = floor(T2/T1)

and x = T2/T1 – floor(T2/T1)

• We want to minimize U: to find at what level we can guarantee schedulability. In this case W = 1, so

U = 1 – x(1 – x) / (1 + x)• Setting the derivative equal to 0, we get x = √2 – 1, and

U(√2 – 1) = 2(√2 – 1) = about 0.83• Result can be generalized to n jobs: U = n(2^(1/n) – 1)


• Deadlock– Properties– Analysis: directed graph

• Handle– Prevent– Avoid

• Safe states and the Banker’s algorithm

– Detect– Recover

Origins of deadlock

• System contains resources• Process compete for resources:

– request, acquire / use, release

• Deadlock occurs on a set of processes when each one is waiting for some event (e.g. the release of a resource) that can only be triggered by another deadlocked process.– e.g. P1 possesses the keyboard, and P2 has the printer. P1

requests the printer and goes to sleep waiting. P2 requests the keyboard and goes to sleep waiting.

– Sometimes hard to detect because it may depend on the order in which resources are requested/allocated

Necessary conditions

4 conditions to detect for deadlock:• Mutual exclusion – when a resource is held, the process has

exclusive access to it• Hold and wait – processes each hold 1+ resource while

seeking more• No preemption – a process will not release a resource unless

it’s finished using it• Circular wait

• The first 3 conditions are routine, so it’s the circular wait that is usually the big problem.– Model using a directed graph, and look for cycle

Directed graph

• A resource allocation graph is a formal way to show we have deadlock

• Vertices include processes and resources• Directed edges

– (P R) means that process requests a resource– (R P) means that resource is allocated to process

• If a resource has multiple instances– Multiple processes may request or be allocated the resource– Intuitive, but make sure you don’t over-allocate– e.g. Figure 7.2: Resource R2 has 2 instances which are both

allocated. But process P3 also wants some of R2. The “out” degree of R2 is 2 and “in” degree is 1.

Examples

• R2 has 2 instances.– We can have these edges: P1 R2, P2 R2, P3 R2.

– What does this situation mean? What should happen next?

• Suppose R1 and R2 have 1 instance each.– Edges: R1 P1, R2 P2, P1 R2

– Describe this situation.

– Now, add this edge: P2 R1

– Deadlock?

• Fortunately, not all cycles imply a deadlock. – There may be sufficient instances to honor request

– Fig 7.3 shows a cycle. P1 waits for R1 and P3 waits for R2. But either of these 2 resources can be released by processes that are not in the cycle…. as long as they don’t run forever.

How OS handles• Ostrich method – pretend it will never happen. Ignore the

issue. Let the programmer worry about it.– Good idea if deadlock is rare.

• Dynamically prevent deadlock from ever occurring– Allow up to 3 of the 4 necessary conditions to occur.– Prevent certain requests from being made.

• A priori avoidance– Require advance warning about requests, so that deadlock can be

avoided.– Some requests are delayed

• Detection– Allow conditions that create deadlock, and deal with it as it occurs.– Must be able to detect!

Prevention

• “An ounce of prevention is worth a pound of cure”: Benjamin Franklin

• Take a look at each of the 4 necessary conditions. Don’t allow it to be the 4th nail in the coffin.

1. Mutual exclusion– Not much we can do here. Some resources must be exclusive.– Which resources are sharable?

2. Hold & wait– Could require a process to make all its requests at the beginning

of its execution.– How does this help?– Resource utilization; and starvation?

Prevention (2)3. No resource preemption

– Well, we do want to allow some preemption– If you make a resource request that can’t be fulfilled at the moment,

OS can require you to release everything you have.

(release = preempting the resource)– If you make a resource request, and its held by a sleeping process,

OS can let you steal it for a while.

4. Circular wait– System ensures the request doesn’t complete a cycle– Total ordering technique: Assign a whole number to each resource.

Process must request resources in numerical order, or at least not request a lowered # resource when it holds a higher one.

– Fig. 7.2: P3 has resource #3 but also requests #2. OS could reject this request.

Avoidance

• We need a priori information to avoid future deadlock.

• What information? We could require processes to declare up front the maximum # of resources of each type it will ever need.

• During execution: let’s define a resource-allocation state, telling us:– # of resources available (static)– Maximum needs of each process (static)– # allocated to each process (dynamic)

Safe state

• To be in a safe state, there must exist a safe sequence.• A safe sequence is a list of processes [ P1, P2, … Pn ]

– for each P_i, we can satisfy P_i’s requests given whatever resources are currently available or currently held by the processes numbered lower than i (i.e. Pj where j < i) by letting them finish.

– For example, all of P2’s possible requests can be met by either what is currently available or by what is held by P1.

– If P3 needs a resource held by P2, can wait until P2 done, etc.

• Safe state = a safe sequence including all processes.– Deadlock occurs only in an unsafe state.

• The system needs to examine each request and ensure that if the allocation will preserve the safe state.

Example

• Suppose we have 12 instances of some resource.• 3 processes have these a priori known needs

• We need to find some safe sequence of all 3 processes• At present, 12 – (5 + 2 + 2) = 3 instances available.• Is [ 1, 2, 3 ] a safe sequence?

Process # Max needs Current use

1 10 5

2 4 2

3 9 2

Banker’s algorithm

• General enough to handle multiple instances• Principles

– No customer can borrow more money than is in the bank– All customers given maximum credit limit at outset– Can’t go over your limit!– Sum of all loans never exceeds bank’s capital.

• Good news: customers’ aggregate credit limit may be higher than bank’s assets

• Safe state: Bank has enough “money” to service request of 1 customer.

• Algorithm: satisfy a request only if you stay safe– Identify which job has smallest remaining requests, and make sure we

always have enough dough

Example

• Consider 10 devices of the same type• Processes 1-3 need up to 4, 5, 8 of these devices,

respectively• Are these states safe?

Job # allocated Max needed

1 0 4

2 2 5

3 4 8

Job # allocated Max needed

1 2 4

2 3 5

3 4 8

Handling deadlock

• Continually employ a detection algorithm– Search for cycle– Can do it occasionally

• When deadlock detected, perform recovery• Recover by killing

– Kill 1 process at a time until deadlock cycle gone– Kill which process? Consider: priority, how many resources it

has, how close it is to completion.

• Recover by resource preemption– Need to restart that job in near future.– Possibility for starvation if the same process is selected over and

over.

Detection algorithm

• Start with allocation graph, and “reduce it”

While no changes do:• Find a process using a resource & not waiting for one.

Remove edge: process will eventually finish.• Can now re-allocate this resource to another process, if

needed.• Also can perform other resource allocations for

resources not fully allocated.

• If there are any edges left, we have deadlock.

Example

• 3 processes & 3 resources• Edges:

– (R1 P1)– (P1 R2)– (R2 P2)– (P2 R3)– (R3 P3)

• Can this graph be reduced to the point that it has no edges?


• Main memory– Addressing– Swapping– Allocation and fragmentation– Paging– Segmentation

• Commitment – Please finish chapter 8

Addresses

• CPU/instructions can only access registers and main memory locations– Stuff on disk must be loaded into main memory

• Each process given range of legal memory addresses– Base and limit registers– Accessible only to OS– Every address request compared against these limits

• When is address of an object determined?– Compile time: hard-coded by programmer– Load time: compiler generates a relative address– Execute time: if address may vary during execution because the

process moves. (most flexible)

Addresses (2)

• Logical vs. physical address– Logical (aka virtual): The address as known to the CPU and

source code– Physical = the real location in RAM– How could logical and physical address differ? In case of

execution-time binding. i.e. if the process location could move during execution

• Relocation register– Specifies what constant offset to add to logical address to obtain

physical address– CPU / program never needs to worry about the “real” address, or

that addresses of things may change. It can pretend its address start at 0.

Swapping

• A process may need to go back to disk before finishing.– Why?

• Consequence of scheduling (context switch)• Maintain a queue of processes waiting to be loaded from

disk• Actual transfer time is relatively huge

– When loading a program initially, we might not want to load the whole thing

• Another question – what to do if we’re swapped out while waiting for I/O.– Don’t swap if waiting for input; or– Put input into buffer. Empty buffer next time process back in memory.

Allocation

• Simplest technique is to define fixed-size partitions

• Some partitions dedicated to OS; rest for user processes

• Variable-size partitions also possible, but must maintain starting address of each

• Holes to fill

• How to dynamically fill hole with a process:– First fit: find the first hole big enough for process – Best fit: find smallest one big enough – Worst fit: fit into largest hole, in order to create largest possible

remaining hole

• Internal & external fragmentation

Paging

• Allows for noncontiguous process memory space • Physical memory consists of “frames”• Logical memory consists of “pages”

– Page size = frame size

• Every address referenced by CPU can be resolved:– Page number– Offset– how to do it? Turns out page/frame size is power of 2.

Determines # bits in address.

• Look up page number in the page table to find correct frame

Example

• Suppose RAM = 256 MB, page/frame size is 4 KB, and our logical addresses are 32 bits.– How many bits for the page offset?– How many bits for the logical/virtual page number?– How many bits for the physical page number?– Note that the page offsets (logical & physical) will match.

• A program’s data begins at 0x1001 0000, and text begins at 0x0040 0000. If they are each 1 page, what is the highest logical address of each page?

• What physical page do they map to?• How large is the page table?

Page table

• HW representation– Several registers– Store in RAM, with pointer as a register– TLB (“translation look-aside buffer”)

Functions as a “page table cache”: Should store info about most commonly occurring pages.

• How does a memory access work?– First, inspect address to see if datum should be in cache.– If not, inspect address to see if TLB knows physical address– If no TLB tag match, look up logical/virtual page number in the

page table (thus requiring another memory access)– Finally, in the worst case, we have to go out to disk.

Protection, etc.

• HW must ensure that accesses to TLB or page table are legitimate– No one should be able to access frame belonging to another process

• Valid bit: does the process have permission to access this frame?– e.g. might no longer belong to this process

• Protection bit: is this physical page frame read-only?

• Paging supports shared memory. Example?• Paging can cause internal fragmentation. How?• Sometimes we can make page table more concise by

storing just the bounds of the pages instead of each one.

Page table design

• How to deal with huge number of pages• Hierarchical or 2-level page table

– In other words, we “page” the page table.– Split up the address into 3 parts. “outer page”, “inner page” and then the

offset.– The outer page number tells you where to find the appropriate part of the

(inner) page table. See Figure 8.15.– Not practical for 64-bit addressing! Why not?

• Hashed page table– Look up virtual page number in a hash table. – The contents of the cell might be a linked list: search for match.

• Inverted page table– A table that stores only the physical pages, and then tells you which

logical page map to each. Any disadvantage?

Segmentation

• Alternative to paging• More intuitive way to lay out main memory…

– Segments do not have to be contiguous in memory– Process has segment table: For each segment, stores the base

address and size

• As before, a process has a “logical address space”– But now: it consists of segments, each having a name and size.– How does a program(mer) specify an address in a segmented

scheme?– What kinds of segments might we want to create for a program?

• HW may support both paging and segmentation– So, OS may exploit either or both addressing techniques.– To ignore segmentation, just use 1 segment for entire process.

Pentium example

• To convert logical to physical address– Handle the segmentation first…– Segmentation unit takes the logical address, and converts this to a

linear address (why?)– Paging unit takes the linear address and converts this to a physical

address (somewhat familiar process)

• A segment may be up to 4 GB, so offset is 32 bits– Logical address has 2 parts: segment number plus offset– Look up segment number into “descriptor table”. Entries in this table

give the upper bits of the 32-bit linear address.

• Pentium uses 2-level paging– Outer and inner page numbers are 10 bits each. What information

does this tell you?

CS 346 – Section 9.1-9.4

• Virtual memory– (continues similar themes from main memory chapter)– What it is– Demand paging– Page faults– Copy on write– Page replacement strategies

Virtual memory

• Recall: main memory management seeks to support multiprogramming

• VM principles– Allow process to run even if only some of it is in main memory– Allow process to have a logical address space larger than all physical

memory– Allow programmer to be oblivious of memory management details,

except in extreme cases.

• Motivation– Some code is never executed. Some data never used.– Programmer may over-allocate an array.– Even if we need to load entire program, we don’t need it all at once.– We’ll use less RAM, and swap fewer pages.

Using VM

• The programmer (or compiler) can refer to addresses throughout entire (32-bit) address space. – In practice, may be restricted, because you may want to have

virtual addresses for outside stuff; but still a huge fraction– All addresses will be virtual/logical, and will be translated to

actual physical address by OS and HW– We can allocate a huge amount of VM for stack and heap, which

may grow during execution.– Stack and heap will be unlikely to bump into each other.

• Supports sharing of code (libraries) and data– Virtual addresses will point to the same physical address

Demand paging

• Typical way to implement VM

• Only bring a page in from disk as it is requested.– What is benefit? Why not load all pages at once?

– “lazy pager” more accurate term than “lazy swapper”

• Pager initially guesses which pages to initially load– “pure demand paging” skips this step

• Valid bit: is this page resident in RAM?

• If not: page fault– The page we want is not in physical memory (i.e. it’s in the “swap

space” on disk)

– How often does this happen?

– Temporal and spatial locality help us out

Page fault

Steps to handle:• OS verifies the problem is not more severe• Find free space in RAM into which to load proper page• Disk operation to load page• Update page table• Continue execution of process

• Cost of page fault ~ 40,000x normal memory access– Probability should be minuscule

Copy-on-write

• A memory optimization• Can be used when we fork, but not exec• No real need to duplicate the address space

– Two processes running the same code, accessing same data

• Until… one of the processes wants to write.– In this case, we create a 2nd copy of the page containing the written-to

area.– So, we only copy some pages. Compare Figures 9.7 and 9.8

• If you want to exec immediately after fork, you would not need to copy-on-write.– vfork( ) system call: child shares same pages as parent. Child should

not alter anything here because of the exec. But if child did, changes would be seen by parent.

Page fault

• Demand paging to implement virtual memory √• What is a page fault?• How to handle

– … Find a free frame and load the new page into it …– But what if no frame is free? Aha!

• Extreme approaches– Terminate process if no free frame available– Swap out a process and free all its pages being used

• Alternative: replace (i.e. evict) one of the resident pages– Need to amend the procedure for handling page fault:– Copy victim to disk if necessary; replace frame with new page– Let process continue

Issues

• Frame allocation– How many frames should we give to each process?– If more than enough, never need to evict a page. (Too good…)– More about this later (section 9.5)

• Page replacement algorithm– Need a way to pick a victim– Many such algorithms exist– Goal: reduce total # of page faults (or the rate), since costly!

• To simplify analysis of page behavior, use “reference string”: list of referenced pages, rather than complete addresses. (p. 412)– Given # frames, replacement algorithm and reference string, should

be able to determine # of page faults.

Clairvoyant

• The clairvoyant page replacement algorithm is optimal.– In other words, the minimum possible number of page faults

• Replace the page that will not be used for the longest period of time in the future.

• Not realistic to know such detailed info about the future, so it’s not a real algorithm

• Useful as a benchmark.– If your algorithm is better, check your arithmetic.

FIFO

• “First in, first out” – queue philosophy• Evict the page that has been resident the longest.• Example with 3 frames:

– 7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1– 15 page faults, compared to 9 with clairvoyant

• Does this policy make sense?– Being “old” has nothing to do with being useful or not in the future.– Startup routines may no longer be needed. Ok.– Does a grocery store get rid of bread to make way for green tea?

• Belady’s anomaly– Undesirable feature: it’s possible to increase # frames and see an

increase in # of page faults. (p. 414)

LRU

• “Least recently used”

• Attempts to be more sensible than FIFO– More akin to a stack, rather than a queue

• Example with 3 frames– 7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1

Has 12 page faults

• Problem: how to represent the LRU information– Stack of page numbers:

Reference a page bring it to the top

Evict the lowest page # in the stack– Associate a counter or timestamp for each page. Search for min.– HW might not support these expensive ops: require significant

overhead, e.g. update for each reference.

Almost LRU• We want to perform fewer HW steps

– It’s reasonable to test/set a bit during a memory reference. Not much more than this.

– Gives rise to reference bit(s) associated with each page.

• Second chance FIFO– When a page is referenced, set its reference bit.– When time to find victim, scan the frames. If ref bit = 1, clear it. If ref bit

already 0, we have our victim. Next time need to search for victim, continue from here (circular/“clock” arrangement).

• Multiple reference bits– Periodically shift left the ref value. Evict page that has all 0’s.

• Use reference count (MFU or LFU)– When a page is referenced, increment its reference value.– Policy may be to evict either least or most frequently referenced.

CS 346 – Sections 9.5-9.7

• Paging issues– How big should a page be?– Frame allocation– Thrashing– Memory-mapped files & devices

• Commitment – Please finish chapter 9

Page size

• HW may have a default (small) page size– OS can opt for somewhat larger sizes– If we want 4K pages, but the default is 1K, then tell HW to always group

its pages in fours

• Small or large?– On average, ½ of final page will be blank (internal fragmentation)– But, small pages larger page table

• Let’s measure overhead– s = average process size; p = page size; e = size of page table entry– We’ll need about s/p pages, occupying se/p bytes for page table.– Last-page waste = p/2– Total overhead = se/p + p/2. See the trade-off?– Optimum result p = sqrt(2se) ~ sqrt(2 * 1MB * 8) = 4 KB

Frame allocation

• A process needs a certain minimum number of frames.• Some instructions may require 2 memory references

(unusual), plus the instruction itself.– All 3 memory locations may be in different pages– To execute this single instruction, we would need 3 frames.– Also, a memory reference could straddle a page boundary. Not a

good HW design.– Book mentions example of inst requiring up to 8 frames.

• Equal allocation among processes• Proportional allocation (to total process size)• Priority bonus• Allocation needs to be dynamic: changes in # processes

Allocation (2)

• Global or local page replacement?– Local = you can only evict your own pages

With this policy: the number of frames allocated to a process never changes.

– Global = you can evict someone else’s page

You are at the mercy of other processes. # of page faults depends on the environment.

But if you need extra space, you can take it from someone who isn’t using theirs.

More responsive to actual memory needs throughput.

• Non-uniform memory– With multiple CPUs and memories, we desire frames that are

“closer” to the CPU we are running on.

Thrashing

• Spending more time paging than doing useful work.

• How does it occur?– If CPU utilization low, OS may schedule more jobs.– Each job requires more frames for its pages. It takes frames away from

other jobs. More page faults ensue.– When more and more jobs wait to page in/out, CPU utilization goes

down. OS tries to schedule more jobs.– Fig 9.18 – don’t have too many jobs running at once!

• To avoid the need for stealing too many frames from other jobs, should have enough to start with.– Locality principle: At any point in the program, we need some, but not all

of our pages. And we’ll use these pages for a while. Loops inside different functions.

• Or: swap out a job and be less generous in future.

Working set model

• A way to measure locality by Peter Denning, 1968.• Begin by setting a window

– How far back in time are you interested?– Let = the number of memory references in the recent past– What if is too big or too small?

• Working set = set of pages accessed during window– Another number: Working set size (WSS) :

How many pages accessed during the window– For example, we could have = 10,000 and WSS = 5.

• OS can compute WSS for each job.– If extra frames still available, can safely start a new job.

• Practical consideration: how often to recalculate WSS?

Memory mapping

• Often we read a file sequential from start to finish.– Seems a shame to make so many system calls and disk accesses

for something so routine (e.g. read a single character or line of text).

– Instead, pages in memory get allocated to file on disk.

• When writing data to file, disk contents not immediately updated.– RAM acts as buffer

– periodic checks: if something written, write to disk

– Final writes when job is done.

• For read-only file, multiple jobs can share this memory• Other I/O devices also mapped to pages (screen, printer,

modem)

CS 346 – rest of Ch. 9

• Allocating memory for kernel• Making paging work better

– prepaging– TLB reach– Memory-aware coding– Locking pages

Kernel memory

• Some memory is reserved for kernel• To minimize overhead

– (fragmentation): we don’t allocate entire pages at a time– (efficiency / direct memory access): OS would like to allocate a

contiguous block of memory of arbitrary size

• Simple approach: “buddy system”:• Memory manager maintains list of free blocks of size 1, 2, 4, 8,

… bytes up to some maximum e.g. 1 MB.• Initially, we have just 1 free block: the entire 1 MB.

– Over time this may get split up into smaller pieces (buddies).

• When kernel needs some memory, we round it up to the next power of 2.

• If no such size available, split up something larger.

Example1024

Request A = 70K

A 128 256 512

Request B = 35K

A B 64 256 512

Request C = 80K

A B 64 C 128 512

Return A 128 B 64 C 128 512

Request D = 60K

128 B D C 128 512

Return B 128 64 D C 128 512

Return D 256 C 128 512

Return C 1024

When a block of size 2k is freed, memory manager only has to search other 2k blocks to see if a merge is possible.

Slab

• Relatively new technique• Kernel objects are grouped by type in effect, grouped by

size– e.g. semaphores, file descriptors, etc.

• OS allocates a “cache” to hold objects of the same type.– Large enough to hold several such objects. Some are unused, i.e.

“free”

• How many objects are in a cache?– 1 page (4 K) is usually not enough. So we may want several

contiguous pages – this is called a slab.

– So, we achieve contiguous memory allocation, even though the objects might not be resident contiguously themselves. See figure 9.27

Prepaging

• In order to avoid initial number of page faults, OS can bring in all needed pages at once.

• Can also do this when restarting a job that was swapped out. Need to “remember” the working set of that job.

• But: will the job need “all” of its pages?

• Is the cost of prepaging < cost of servicing all future individual page faults?

TLB reach

• For paging to work well, we want more TLB hits too• TLB reach = how much memory is referred to by TLB

entries– Memory-intensive process more TLB misses

• Approaches to improve TLB hit rate– Larger TLB

But sometimes, to achieve acceptable hit rate, need unreasonably large table!

– Allow for larger page size

For simplicity, can offer 2 sizes (regular and super)

OS must manage the TLB, so it can change page size as needed. Any disadvantage?

Memory-aware code

• Page faults do happen. Keep working set small if you can.

• Let’s initialize array elements. Does it matter if we proceed row or column major?

• Data structures: stack, queue, hash table

• BFS vs. DFS – which is better with respect to memory?

• array versus ArrayList

Locking pages

• Sometimes we want to make sure some pages don’t get replaced (evicted)

• Each frame has a lock bit• I/O

– Actual transfer of data performed by specialized processor, not the CPU

– When you request I/O, you go to sleep while the transfer takes place.

– You don’t want the I/O buffer pages to be swapped out!

• Kernel pages should be locked• Can lock a page until it has been used a little

– To avoid situation where we replace a page we just brought in


• Mass storage– Advantages?– Disk features– Disk scheduling– Disk formatting– Managing swap space– RAID

Disks

• Anatomy (Figure 10.1)– Sector, track, cylinder, platter

– Read/write head attached to arm, attached to arm assembly

– Head quickly reads binary data as: orientation of iron ions or reflectiveness of surface

• Example: CD– About 25,000 tracks, 50 sectors per track 1 bit occupies about 1

square m

– Entire CD can be read in about 7 minutes on a 12x speed drive

• But usually we don’t read entire disks2 aspects dominate access time:

– Seek time: proportional to square root of seek distance

– Rotational latency

Some specs

Floppy disk Hard drive (2001) Hard drive (2011)

Cylinders 40 10 601 310 101

Tracks/cylinder 2 12 16

Sectors/track 9 281 (average) 63

Sectors/disk 720 35 742 000 312 500 000

Bytes/sector 512 512 512

Capacity 360 KB 18 GB 160 GB

Seek adjacent track 6 ms 0.8 ms

Seek (average) 77 ms 6.9 ms 9.5 ms

Rotation 200 ms 8.3 ms 8.3 ms

Transfer 1 sector 22 ms 17 s 1.7 s

Disk scheduling

• Common problem is a backup of disk requests• Disk queue• When disk is ready, in what order should it do the disk

requests? Similar to problem of scheduling CPU• Pending jobs are classified by which track/cylinder they want to

access• Ex. 4, 7, 16, 2, 9, 1, 9, 5, 6• Several disk scheduling algorithms exist

– Simple approach: first-come, first-served– Total head movement = ?– Want to reduce total seeking time or head movement: avoid “wild

swings”.– Would be nice not to finish at extreme sector number.

Scheduling (2)• Shortest seek first

– For 4, 7, 16, 2, 9, 1, 9, 5, 6: After serving track 4, where do we go next? Total head movement = ?

– Very good but not optimal

• Elevator algorithm (“scan” method)– Pick a direction and go all the way to end, then come back and handle all

other requests.– Better than Shortest Seek in our example?

• Circular scan– Same as elevator algorithm BUT: when you reach the end you

immediately go to the other end without stopping for requests. In other words, you only do work as head is moving in 1 direction.

• Look scheduling: modify elevator & circular scan so you only go as far as highest/lowest request

Disk mgmt

• Low-level (physical) formatting– Dividing disk medium into sectors – Besides data, sector contains error-correcting code– Later, disk controller will manipulate individual sectors

• High-level (logical) formatting– Record a data structure for file system on disk– Partition groups of cylinders if desired– Associate adjacent blocks into logical clusters to support file I/O

• “Sector sparing”: compensate for bad blocks!– Maintain list of bad blocks; replace each with a spare one

• Boot from disk: boot blocks in predefined locations contain system code to load “boot partition” of drive

Swap space

• Recall: used in virtual memory to store pages evicted from RAM– Faster to return to RAM than loading from file from scratch– In effect: disk space is now being used as extension of main

memory, the very essence of VM

• Logically a separate partition of the disk from the file system• When process started, it’s given some swap space• Swap map: kernel data structure to track usage

– Associate an counter value with each page in swap area– 0 means that page is available to swap into– Positive number: number of processes using that swapped-out data

(> 1 means it’s shared data)

RAID

• Increasingly practical to have several disks on a system– But increases probability & mean time to failure

• RAID = “redundant array of independent disks”– Redundancy: fault tolerance technique

• Six “levels” or strategies of RAID: use various combinations of fault tolerant techniques

• Typical RAID techniques in use– Striping a group of disks: split bits of each byte across disks

Or block-level striping: split blocks of a file…– Mirroring another disk– Store parity (error-correcting) bits on another disk– Leaving some disks empty until needed to replace failed disk

RAID levels

Various combinations of techniques… For example:• RAID 0 – block striping; no mirroring or parity bits• RAID 1 – add mirrored disks• RAID 2, 3, 4 – extra disks store parity bits

– If 1 disk fails, remaining bits of each byte and error-correction bit can be used to construct lot bit of each byte.

– RAID 3 – bit-interleaved parity– RAID 4 – block-interleaved parity

• RAID 0+1 – a set of disks is striped, and then the stripe is mirrored to another disk

• RAID 1+0 – disks are mirrored into a pair of disks. This pair is then striped.

RAID extensions

• RAID is designed just to detect & handle disk failure• Does not prevent/detect data corruption, etc.

– Could be pointing to wrong file, wrong block

• Checksum for data and metadata on disk– Ex. For each disk block, how many bits are set?– Store with pointer to object (See Figure 10.13)– Detect whether it has changed. Grab correct data from the

mirror.

• RAID also somewhat inflexible because its techniques require a certain number of disks. What to do?


• File system– Files– Access– Directories– Mounting– Sharing– Protection

Files

• What is a file?• Attributes

– Name, internal ID, type, location on device, size, permissions, modification/creation time

• Operations– Create, read, write, reposition file pointer (seek), delete, truncate (i.e.

to zero)– Less essential: append, rename, copy– The first time we refer to a file, need to search for it: “open”

• Active file tables. What is stored in each?– Table per process– System-wide table

• The “open count” for a file

Type and structure

• Policy question – should OS be aware of file types?• How file type determined

– filename extension– Keep track of which application created file– Magic number

• File type determines its structure– At a minimum: bits and bytes– e.g. OS expects executable file to have certain format– Text file: recognize meaning of certain ASCII codes

• Files stored in “blocks” on a device– Each I/O operation can grab one block (~ 1KB <= page size)– Can start a new file on a new block, or do some “packing”

Accessing data

• Sequential access– Read, write, rewind operations– We almost always utilize files this way

• Direct access– More complex system calls: Allow arbitrary access to any byte

in file on demand– What kind of application needs this functionality?– Read/write operations may specify a relative or absolute block

number

• Indexed access– Another file stores pointers to appropriate blocks in some large

file

Directories

• File system resides on some “volume”– A volume may be a device, part of a device, multiple devices:– So, can have multiple file systems on the same device (partition)– A file system can use multiple devices, but this adds complexity

• Can have specialized “file systems” to allow certain devices to be treated as files, with file I/O commands

• Volume must keep around info about all files– Confusingly called a directory

• Directory operations on files:– Search, create, delete, list, rename, traverse

File organization

• How are files logically organized in the directory?

• Single-level directory: one flat list– File names must be unique

– Excellent if everyone is sharing files

• Two-level directory– Each user has a separate directory: Figure 11.9

– System maintains a master file directory: pointers to each user’s file directory

– Allows user’s work to be isolated

– Can specify file by absolute or relative path name

– Special “system user” for system files. Why necessary?

– Search path: sequence of directories to use when searching for a file. Look here, look in system folder, etc.

File org (2)

• Tree-based directory: Files can be arbitrarily deep• Allows user to impose local structure on files• Each process has a current working directory

– To access file, need to specify path name or change the current directory

• Policy on deleting an entire directory• Acyclic directory: support links to existing files

– In effect, the same file has multiple path names– Same file exists in multiple directories– But there is just 1 file, not a copy– When traversing, need to ignore the links– What happens when we delete file? Links now point to …– Can count the # of references to file (like garbage collection)

Mounting

• Mount = make volume/device available to file system.• Assign a name to its root so that all files will have a specific

path name.

• Mount point = position in existing file system in which we insert the new volume.– Think of inserting a subtree at a new child of an existing node.– E.g. You plug in a USB drive, and immediately it acquires the name E:

so you can access its files– In UNIX, a new “volume” may appear under /

• Unused volumes may be temporarily unmounted if file system desires

File sharing

• In multi-user system, desirable to have some files accessible by multiple users!

• File system must have more info– Owner of each file– Assign unique ID numbers for users and groups of users– When you access file, we check your IDs first

• Remote file system access– Manually transfer files via FTP– Distributed file system: see a file system on another computer

on the network– Anonymous browsing on the Web

Remote file system

• We’d like to mount a remote file system on our machine.– In other words, be able to give (path) names to remote files to

manipulate them.

• Client-server relationship: a file server accepts requests for remote machines to mount – E.g. You are logged into ultrax2, but ultrax1 is the file server.– NFS is a standard UNIX file sharing protocol– OS file system calls are translated into remote calls

• One challenge – to authenticate the client.– Typically the client & server share same set of user IDs. When you

get a computer account, your user ID is good everywhere.– Or, provide your password the first time you access server.

• What is role of distributed naming service, e.g. DNS ?

Consistency

• Policy decisions concerning how we handle multiple users accessing the same file– Reminiscent of synchronization

• When do changes made by one user become observable to others?– Immediately, or not until you reopen the file?

• Should we allow 2 users to read/write concurrently?– As in a database access

• System may define immutable shared file– Like a CD-R– Cannot be modified, name cannot be resused.– No constraints on reading

Protection

• Owner/creator of file should set capabilities for– What can by done– By whom

• Types of access– Read– Write– Execute

Could also distinguish other access capabilities: – Delete– List

Specifying permissions

• Establish classes of users, each with a possibly distinct set of permissions– Classes can be: owner, group, rest of world

• For each level of users:– ‘r’ = Can I read the file?– ‘w’ = Can I write to (or delete) the file?– ‘x’ = Can I execute the file?

• Examples– rw-rw-r-- (664)– rwxr-xr-- (754)– rw-r----- (640)

• If no groups, can set group permission = rest of world.• Use chmod command


• File systems

– Structure

– Information to maintain

– How to access a file

– Directory implementation

– Disk allocation methods efficient use, quick access

– Managing free space

– Efficiency, performance

– Recovery

Structure

• File system is usually built on top of disks– Medium can be rewritten in place– Relatively easy to move to another place on disk

• Purpose of file system– Provide a user interface to access files– Define a mapping between logical files and space on a secondary

storage device

• FS have several levels/layers of abstraction & functionality, e.g. 4– Logical file system– File organization module– Basic file system– I/O control

Layers• Logical file system

– Maintain file’s metadata: inside a “file control block” aka “inode”– Directory data structure

• File-organization module– Translates between logical and physical data blocks of a file. In other words

it knows everybody’s real address.– e.g. logical block numbers might always start 0

• Basic file system– Manipulate specific sectors on disk.– Maintain buffers for file I/O

• I/O control– Device drivers give machine-language commands to device to accomplish

the file I/O.– (Different file systems can use the same device drivers.)

FS information

On disk:• Boot (control) block = first

block on a volume. Give inst on how to load the OS.

• Volume control block = “superblock”– Statistics about the volume:

# of blocks, their size, how many are free and which ones

• Directory data structure: point to each file

• File control block (inode) for each file (contains what info?)

In memory:• Which volumes are currently

mounted• Cache of recently accessed

directories (faster access)• Which files are currently open

– Per process– System-wide

• Buffers holding currently processing file I/O

Opening file

• open( ) system call passes file name to logical FS

• See if anyone else already has this file opened. – How?– What if it is?

• If not already open, search the directory

• If found, – copy file control block (inode) to system-wide open file table– Set pointer in process’ open file table (Why not the inode?)– Also in process’ table: dynamic stuff like initialize current location

within file, whether opened for read or write, etc. Should we copy this to inode also?

• open( ) returns file descriptor (i.e. pointer to per-process table entry). Use this for future I/O on this file.

Multiple file systems

• We generally don’t have 1 file system in charge of the entire disk

• Disks usually have partitions…• Raw partition

– Where you don’t want/need to have files– Ex. Swap space; information related to backups

• Boot partition – should be treated special / separate– Contains program to ask user which OS to boot– Multiple OS can give rise to different FS

• Use “virtual file system” to manage multiple FS– Hide from user the fact > 1 FS

Virtual FS

• See Figure 12.4• Purpose: act as an interface between the logical FS the

user interacts with, and the actual local/remote file system• Defines essential object types, for example

– File metadata, e.g. inode– Info about an open file– Superblock: info about an entire file system– Directory entries

• For each type of object, set of operations defined, to be implemented by individual FS– Ex. For a file: open, read, write, …

Directory rep’n

• A question of which data structure to use

• Linear list?– Essentially an array of pointers (we point to the data blocks)– Advantage / Disadvantage?

• Other data structures are possible: any good?– Sorted list– Binary search tree; B-tree– Hash table

1. Contiguous allocation

• Advantage – few seeks needed on disk– Ex. We would like a file to reside entirely in one track if possible

• If you know disk address of first block, and length of file, you know where entire file is.

• Problems– Where to put a new file: dynamic storage allocation: best fit, worst fit,

first fit– External fragmentation– Can’t predict a file deletion that would give you a better fit– Don’t know size of brand new file– Preallocating extra space: internal fragmentation

• Can compact (defragment) files. Tedious operation.• File “extents”: a modification to contiguous scheme

2. Linked allocation

• File is linked list of disk blocks (Figure 11.6)• File’s directory entry points to first & last blocks (in

addition to maintaining other file attributes)• Avoids disadvantages of contiguous allocation

– No fragmentation, don’t need to know size in advance, …

• Criticism– Linked list inefficient to access data “directly” as opposed to

sequentially. Ex. Editor requests to go to 3 millionth line.– What if 1 of the pointers becomes damaged?– Minor overhead from the pointer in each block. Can define

“clusters” of the file to be contiguous blocks, but this suffers some fragmentation.

File allocation table

• Located at start of disk• Table has an entry for each disk block

– Has fixed size and is indexed by disk number– Purpose of these table entries is to point to next block in a file,

like emulating a linked list with an array

• File’s directory entry contains the starting block number.– See Figure 11.7

• Performance problem:– Need to do 2 seek operations every time you go to a new block

in the file. Why?

• Direct access with FAT is faster than pure linked allocation. Why?

3. Indexed allocation

• The file on disk begins with an index block• Index block contains pointers to the various disk blocks

containing the actual data of the file.

• When file first created, all pointers set to null. One by one, they get initialized as file grows.

• File’s directory entry contains block number of the index block. See Figure 11.8

• If all blocks on disk are exactly 1KB in size, how big of a file can we support using this scheme?

Bigger files

• Linked indexed allocation: Can continue pointers in another index block. In general, can have a linked list of index blocks.– How big a file can we have with 2 linked index blocks?

• Multilevel indexed allocation– Begin with a first-level index block. Entries contain addresses of

second-level index blocks.

– Each second-level index block has pointers to actual file data.

– How big a file can we have?

• Direct & indirect indexed allocation– File’s directory entry can hold several block numbers itself.

– Followed by: single indirect block, double indirect block, triple indirect block. See figure 11.9

Free space

• As long as volume is mounted, system maintains free-space “list” of unused blocks. Question is how to represent this info.

• Bit vector: how much space? Keep it in memory?• Collect all free blocks into linked list.

– We don’t typically traverse this list. Just grab/insert one.

• Grouping technique– First “free” block used to store addresses of n – 1 actual free

blocks. Last address stores location of another indirect block of free addresses.

• Counting: store address along with number of contiguous free blocks

Efficiency

• Where should inodes be on the disk? All in one place or scattered about?

• Using linked allocation (treating data blocks as a linked list on disk)– How to keep a lid on the number of nodes in a list?

– How to reduce internal fragmentation?

• File metadata may include the last time file accessed– How expensive is this operation? Response/alternative?

• Size of pointers (locations holding address)

• Should the system’s global tables (process, open files) be fixed or variable length?

Performance

Some techniques to optimize disk usage

• Disk controller: store contents of a whole track – Why? What is necessary to accomplish this?

• Buffer cache and page cache– “Cache” a file’s data blocks / physical pages of virtual memory

• Caching the pages may be more efficient:– Pages can be individually larger than individual data blocks– Fewer computational steps to do virtual memory access than

interfacing with the file system.

• Not too efficient to employ both kinds of caches– “Double caching problem” with memory-mapped I/O: data first arrives

into a page cache because the device is paged… and then copied to/from buffer cache

Performance (2)

• Do you want writes to be synchronous or asynchronous?– Pass a parameter to open( ) system call to specify which you

want.– Which is better typically?– When one is preferred over the other?

• Page replacement: default policy like LRU may be bad in some situations– Consider sequential access to a file: Remove a page as soon

as the next one is in use. Request the next few pages in advance.

Recovery

• Need to protect from– Loss of data– Inconsistency (corruption) of data – resulting from what?

• Consistency checking– Scan file metadata, see if it all makes sense– See if data blocks match a file correctly: traverse all pointers– Check free block list– What if something is wrong?– Is some information more critical than others? What extra protection

to give?

• Log transactions: tell which operations are pending, not complete

• Full vs. incremental backups

Network file system

• Principles– Each machine has its own file system

– Client-server relationships may appear anywhere

– Sharing only affects the client

• To access remote directory, mount it– A remote directory is inserted in place of an existing (empty)

directory whose contents now becomes hidden.

– It will then look & behave like part of your local file system

– Supports user mobility: access your files anywhere in the network

• Protocol– Server has list of valid file systems that can be made available,

and access rights (for each possible client)


• I/O systems– Hardware components– Polling & interrupts– DMA: direct memory access– I/O & the kernel

• Commitment – Please read chapter 13.

I/O

• Challenge: so many different I/O devices

• Try to put a lid on complexity– Classify I/O by how they behave– All devices should have a common set of essential features

• Each device has a controller (hardware / circuitry) that is compatible to the host machine.– Process running on CPU needs to read/write values in registers

belonging to an I/O controller

• Corresponding device driver installed as part of the OS– Communicates with controller– I/O instructions ultimately “control” the devices

• Devices can have memory addresses allocated to them

Concepts

• Port – physical connection point between device and computer

• Bus – set of wires connecting 1+ devices– The bus itself is connected to the port, and devices are connected

to the bus– Figure 13.1: Notice controllers connected to bus– System enforces some protocol for communication among the

devices along this bus

• Daisy chain – another way to group devices– One device is connected directly to the computer– Each other device is connected to another device along the chain.

Think of it as a linked list of devices, with the first device directly connected.

Memory mapped I/O

• Some of RAM is reserved to allow processes to communicate with I/O controllers

• We read/write data to specific address– This address is assigned to a specific port identify device– Each device is given a specific range of addresses: Fig. 13.2– Address also signifies meaning of the value. E.g. Status of I/O

request, command to issue to controller, data in, data out

• An I/O instruction can immediately get/set a value in controller’s register

Polling & interrupts

• When working with an I/O device, we need to determine its state: is it ready/busy, did it encounter an error or complete successfully?

• Polling = busy-wait cycle to wait for answer from device. Periodically check status of operation

• Interrupt – let the I/O device inform me– Device sends signal along an interrupt-request line– CPU detects signal and jumps to predefined interrupt handling

routine. (Need to save state while away) Figure 13.3– Nature of signal allows us to choose appropriate handler– Some interrupts maskable: can ignore– What I/O interrupts do we encounter?

Direct memory access

• Used to large transfer of data– E.g. reading contents of a file into memory

• DMA controller does I/O between device and memory independent of and parallel with CPU execution

• Figure 13.5 example– Process in CPU sends command to DMA controller identifying

source and destination locations. – CPU goes about its business. DMA controller & device driver do

the rest, communicating with the disk controller.– DMA tells disk to transfer a chunk of data to memory location X.– Disk controller sends individual bytes to DMA controller– DMA controller keeps track of progress. When done, interrupt

CPU to announce completion.

Application I/O interface

• In order to help the OS define appropriate system calls, we need to know what devices can do for us

• Classify device personality. Such as:– Character-stream or block?– Sequential or random access desired?– Synchronous or asynchronous, i.e. predictable or unpredictable

response times?

• Example devices (Figure 13.7)– Terminal is character-stream oriented– Disk is block oriented, and can both read & write data– Keyboard is asynchronous– Graphics card is write-only

• Question for next time: what use can we make of clock?

• I/O systems, continued– …Features of I/O system calls– Kernel responsibilities– Buffer, cache, spool– Performance issues

System call behavior

• Clocks– Some I/O requests may be periodic, or set to occur at a specific time– Fine grain (cycle): look up the time– Coarse grain: HW clock generates timer interrupts approx. every 1/60

of a second. Why so seldom?

• Blocking vs. nonblocking I/O– Blocking: put yourself to sleep while waiting for completion. More

straightforward to code– Nonblocking: you want to keep going while waiting. Response time is

important. Example?• If it’s short and quick: have another thread get the data• Usually: use asynchronous system call, and wait for I/O interrupt or

“event” to take place

Kernel’s job

• I/O scheduling– Critical task since inherently slow– 2 goals: minimize average response time; fairness– Rearrange order of I/O requests as they enter “queue”– Ex. Using the elevator algorithm for disk access

• Error handling– Transient failures occur: prepare to retry I/O calls– I/O system calls can return an errno

• Protection– We don’t want users to directly access I/O instructions. – All I/O requests need to be checked by kernel– Memory-mapped memory areas should be off limits to direct user

intervention. (unnecessary and invites bugs)

Buffers

• Memory area between device and application temporarily holding data. Motivation…

• Different speeds of producer & consumer (Fig. 13.10)– Would be nice to do one disk operation; wait until a whole disk block

can be written to, not just 1 line of text.– Why do we use “double buffering”?

• Different size units– Not everything is the same size as a disk block, page frame, TCP

packet, etc.

• Spool = buffer where output cannot be interleaved from different sources: printing– Create temporary “file” for each print job print queue– Managed by dedicated daemon process

Preparing HW ops

• Many steps, common example is reading file from disk• Before we can communicate with disk controller, need to

locate file– File system identifies the device containing the file (how?)– Determine which disk blocks comprise the file (how?)

• Life cycle of I/O request begins! Note that:– A device has a wait queue (why?)– Use DMA if the amount of data is large– Small data can be kept in a buffer– Lots of signalling/interrupts going on– End result: I/O system call returns some value to user process.– Let’s go through the steps

Performance issues

• I/O incurs many interrupts• Each interrupt causes a context switch – we’d like to

minimize these• Ex. When logging in to a remote machine, don’t create a

network message for every keyboard interrupt• Don’t copy data too many times unnecessarily• Where to implement I/O: various levels:

– User space, kernel space, device driver– Microcode on device controller or in the makeup of device

• Trends to observe among the levels (Fig. 13.16)– Cost of mistake; efficiency; development cost; flexibility


• Protection (Ch. 14)– Users & processes want resources. Protection means

controlling their access.– More than just RWX.

• Security (Ch. 15)– Preserving integrity of system & its data

Background

• Protect from …– Malicious, unauthorized or incompetent users– Waste (e.g. accessing expensive equipment just because cheaper

resource is busy)

• Distinguish between: policy & mechanism

• Principle of least privilege– Minimum damage in case of error– Easier to identify who did what– Create user accounts, and tailor privileges accordingly

• Bipartite relationship– Processes vs. objects– Ex. What files does a process have access to?– More practical to organize privileges by user

Access control matrix

• Butler Lampson, 1969.• Express our policies: how subjects (users/processes)

can use each object– For each subject & each object, state the access rights– Can be unwieldy in general!

• Protection domain– Set of common access rights – Usually correspond to a user or class of users

Ex. Students, faculty, guests, system administrators– Process runs inside a domain determined by its owner– Domains may coincidentally overlap (Figure 14.1)

Domains• Representation as 2-D table

– Rows are the domains– Columns are objects– Entries in table specify access rights (Fig. 14.3)

• A user can only be in 1 protection domain at any given time.– Static: a user/process always operates in the same domain (simple

but inflexible)– Dynamic: a user/process can switch to another domain (complex but

flexible)

Can represent this way: domains are objects that a user in some domain can “switch” to. See Fig. 14.4.

• UNIX: some programs have setuid bit set to allow domain switching.

Example

• In addition to read/write/execute, special powers • Copy: you can “copy” an access right for this object to

another domain.• Owner: You can create/delete access rights for this object

Domain Resource 1 Resource 2 Resource 3

Admin Execute Write Execute

Students Execute Read Copy

Execute

Faculty OwnerExecute

Implementation

• In theory, access control matrix is a huge table– Logically it’s 3 dimensional (capability is 3rd dimension)

– Sparse: few rows, thousands of columns – Waste of virtual memory, I/O to look up this separate table

• Access list for objects– Each object (file or other resource) will have attribute identifying

what can be done by members of each domain

– Can define a default to save space

• Capability list for domains– List what I have access to, and what I can do with it

– We don’t want users to arbitrarily change their capabilities! Capability information must be protected. How?

Some questions

• What should we do about objects that have no access rights defined?

• How would we implement a policy limiting the number of times a resource is accessed?

• How would we implement a policy allowing access only during certain times of day?


• Security– Physical, human, program– Authentication– Dictionary attack– Cryptography– Defense policies

Areas of security

Attackers look for every opportunity to get in• Physical

– Restricting access: guards, locked doors– Sounds simple, but don’t neglect!

• Human factors– Naivete, laziness, dishonesty– Help users pick good passwords, other recommended practices– How to handle offenders or people with a history

• Program– Correct algorithm, installation of software– Used in the way originally intended– Proper behavior vs. malicious code

Coding errors

• Not checking validation correctly– A program to support a client remotely accessing the server

through commands

– Input command is scrutinized for safety: limited to “safe” commands.

– But if we parse the command incorrectly, we may actually perform unsafe operation unwittingly

• Synchronization problem– mkdir could be executed in 2 steps: kernel creates new empty

subdirectory and assigns it to root. Then, ownership is transferred to the user who executed mkdir.

– In between the 2 steps: If the system is busy, evil user can execute a command to replace the new directory with a link to some other existing file on the system.

Malicious code

• Trojan horse– 2 purposes: one obvious & benign; the other hidden and evil– Designed to appear like ordinary, beneficial program. “eat me”

• Root kit– Trojans that replace system utility files– Suppose you break into a system, and install programs that allow you

secret access. System admin can find evidence of your intrusion, look at system logs of your files and work. What can you do to cover your tracks?

• Trap door– Flaw in a program placed there by designer. Bypasses security

checks under some circumstances. May originally have been debugging mode.

– Ex. Special access code

Malicious (2)

• Virus– Fragment of code that spreads copies of itself to other programs– Requires a host program– Ex. May append/prepend its instructions to existing program– Every time program runs, virus code is executed, in order to

spread itself & perhaps do other “work”

• Virus scanning technique– Read program code for “signature” of known viruses. In other

words, look for substring of code that is unique to the virus.– But… virus may be polymorphic– New viruses keep appearing

Malicious (3)

• Worm– Like a virus, but it’s a stand-alone program that replicates itself

and spreads.– Also can contain code to do other “work”

Example: Robert Morris, 1988• Included a special module called the “grappling hook”

– Install itself on remote system– Make network connection back to original system– Transfer rest of worm to new victim– Execute worm on victim

• Worm designed to exploit weaknesses in existing UNIX utility programs

Morris exploits

• sendmail program– Debug option: allowed an e-mail message to specify a program as its

recipient. This program would run, using e-mail message body as its input.

– Worm created an e-mail message, containing grappling hook code…. Instructions to remove mail headers…. Resulting program passed to shell

• finger daemon– Exploited buffer overflow by “fingering” a very long name. When

procedure called, it overwrote correct return address with address of grappling hook code.

• 2 other exploits involved remote shell applications– Attempted to crack passwords

• What happened to Morris himself?

Dictionary attack

• We can use a hash function to encode passwords– No way to compute decoded value, so we don’t have to worry about

password table being compromised

• Attacker’s strategy– Get the password table. Administrator complacently left it

unprotected.– Compile a dictionary of thousands of common words; compute the

hash value of each.– Look for matches between dictionary and values in password table.

• Prepare for the threat– Ask people to pick strange passwords, or force them to use a

predefined one… that’s hard to remember.– Salt the password table

Salt

• A random string that is appended to a password before being hashed.

• When user logs in, password is concatenated with salt value, hashed, and checked against entry in password table.

• Attacker must now expand dictionary to contain every possible salt value with every possible password.

Cryptography

• Generally not feasible to build a totally secure network.• Goal: secure communication over unsecure medium

– Key = secret information used to encode/decode message– Recipient verifies the message it receives is from correct sender– Sender wants to ensure only the recipient will understand msg

• Encryption algorithm: how to secure messages– Encryption function: (plaintext, key) ciphertext– Decryption function: (ciphertext, key’) plaintext– Decryption secrecy is more critical than encryption.

• Types– Symmetric: Use same key; decrypt analogous to encrypt– Asymmetric: Different keys; breaking much more tedious

Examples

• Caesar cipher; substitution ciphers– There are 26! ways in which letters can be reassigned.

– What is the “key”? Is this method secure?

• One-time pad (e.g. JN-25)– Dictionary table: convert each word to a 5-digit number

– Additive table: add the next random number to each word

– Preface the message by indicating where in additive table you are starting the encoding

– Tables may be periodically changed.– Example: encryption code book.xlsx

• Data encryption standard– Manipulate 64-bit chunks at a time, using XOR and shift operators.

RSA

• Choose distinct 512-bit random primes p and q• Let N = pq, and let M = (p – 1)(q – 1)• Choose public encryption key e: a value less than and

relatively prime to M.– Message is x. Sender transmits: y = xe mod N

• Choose private decryption key d: where ed mod M = 1– e and N are public; outsider should have a tough time factoring N to

obtain p and q to determine d– Recipient converts: z = yd mod N which should equal x.

• Examplep = 31, q = 41 N = 1271, M = 1200, e = 7, d = 343

x = 12 y = 127 mod 1271 = 1047; z = 1047343 mod 1271 = 12

Note: exponentiation should not be iterative multiplications

Example

• Choose secret primes p,q• N = pq; M = (p – 1)(q – 1)• Choose e < & relatively

prime to M.• Message is x. Compute

and send y = xe mod N

• Pick private decrypt key d where ed mod M = 1

• z = yd mod N, which should equal x.

p = 31, q = 41

N = 1271, M = 1200

e = 7

x = 12

y = 127 mod 1271 = 1047

d = 343

z = 1047343 mod 1271 = 12

It works!

Diffie - Hellman

• Method for 2 people to establish a private key • Choose values p (prime) and q• Sender

– chooses secret value a, and computes A = qa mod p– Sends A, p, q– Eavesdropper cannot easily determine a

• Receiver– Chooses secret value b– Computes B = qb mod p and K = Ab mod p– Sends B back to sender, who can compute K = Ba mod p

• Both methods of computing secret K are equivalent– Ab mod p = (qa)b mod p– Ba mod p = (qb)a mod p

Digital signature

• Used to authenticate origin of message– Also useful if later sender denies ever sending the message

• Sender– Computes hash value of message 128/160 bit result

– Applies D function (using private key) “signature block”

– Appends signature block to the message to send

• Receiver– Applies E function (using sender’s public key) hash

– Computes hash value of message, see if there is a match.

• Efficient since E & D functions applied to small amount of data. The message body itself might not be confidential.

Doing security

• Defense in depth: don’t rely on just 1 catch-all method

• Some attackers know intimate details of your system and how you operate– Attackers may make some assumptions; surprises slow them down

• Penetration test. Look for:– Bad passwords– Programs that look or behave abnormally

• Using setuid when not necessary• In system directory when not necessary• Too many daemons

– Unusual file permissions, search paths, modification dates– Old versions of software

Intrusion detection

• What data do you want to collect? • When is a real-time response required?• What to scan:

– System calls, shell commands, network packets

• Possible responses– Kill process– Surreptitiously alerting admin– Have honeypots ready for attacker

• How to detect– Signature-based: look for specific string or behavior pattern

• Must know what to look for– Anomalies from normal operating specifications

• But, what is normal?

Anomaly detection

• Establish accurate benchmarks of normal operation– Ex. How often do we get pinged from China?

• False positive = false alarm: alert human, but no intrusion

• False negative = we missed an intrusion• Deciding whether to alert human is critical, or else people will

perceive a lot of false alarms exist• Example

– 20 out of 1,000,000 records show intrusion– System detects/alerts 80% of these intrusion events

• 16 records revealed, 4 ignored– System falsely identifies 0.01% of normal events as an intrusion

• 0.01% of 999,980 = ~ 100 false alarms– From human point of view, 100/116 = 86% alarms are false

CS 346 – Chapter 1 Operating system – definition Responsibilities What we find in computer systems Review of –Instruction execution –Compile – link – load.

Documents

os examples

result os

expensive os

system slide

user needs os

lower levels os

job slide

file system program